This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
(This bug may need to be reassigned to individual APIs, including XHR). Before Fetch is initiated, URL parsing needs to take a reference to the underlying resource referred to a blob: or a mediastream: URL. This reference is necessary to ensure that unpredictable behavior doesn't occur when revoking Blob URLs (amongst other things). Discussion of this matter took place over: http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0461.html Happy to reassign or duplicate against other APIs, but: 1. XHR is a prime use case. 2. The problem with using fetch seems to be what happens if there's the potential for fetching multiple sources. E.g. with <img srcset> or <video><source><source></video>. The solution has to be more about using URL parsing that stores a reference on the URL object you get out of that. And then you pass the URL object to fetch and in case of blob/mediastream it'll look on that object for a reference and act appropriately.
In fact, this should live in HTML. 1. APIs such as <img> that take URLs should check if the scheme is mediastream: or blob: and 2. Then take a reference to the underlying object. This could move to the URL spec. eventually, but a wrapper around the URL spec. defined by HTML is what this bug is about. When 'fetch' happens, the object could be fetched directly, as opposed to the URL.
How does this differ from bug 17765?
So actually, after conversations with Anne about this, I think this bug needs to be reassigned so that it can be taken care of in URL parse and fetch, modulo a change in File. None of these is ideal.
*** This bug has been marked as a duplicate of bug 17765 ***