- From: Glenn Maynard <glenn@zewt.org>
- Date: Wed, 17 Apr 2013 08:25:17 -0500
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WebApps WG <public-webapps@w3.org>
- Message-ID: <CABirCh-8kawMbkmmDH=97KxZ5xDN0tdyo8G3h25xrXp-qDAjuQ@mail.gmail.com>
On Wed, Apr 17, 2013 at 4:58 AM, Anne van Kesteren <annevk@annevk.nl>wrote: > In https://www.w3.org/Bugs/Public/show_bug.cgi?id=19594 roc suggests > the default cannot be changed from no auto-revoking to auto-revoking. > (And that we'll have mediastream URLs too.) Given that, I kinda doubt > anyone will opt into setting autoRevoke to true... We could maybe > create a different API that does the "right thing" but then "right > thing" has not had much interest from implementers thus far (when it > comes to the details). > I hope we can change the default, but auto-revoke is important whether we can or not. And again, we need to solve the blob data capturing problem anyway, because it's a problem for manual blob URLs too (the problems are just not as pronounced). Currently the precise point where the fetch will no longer fail because of a revoked blob URL is badly underdefined. Even if you assume "dereferenced" happens some time during fetch, the result is bad interop, since it ends up depending on async task ordering, gets bit by the "loads image data on demand" issue, etc. For example, https://zewt.org/~glenn/test-blob-timing.html works consistently in both Firefox and Chrome, which isn't clear from the specs. https://zewt.org/~glenn/test-blob-xhr-timing.html work in Chrome, but fails in Firefox with a mysterious "not well-formed" log followed by some mojibake. On Wed, Apr 17, 2013 at 8:07 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > <div>.style.backgroundImage = "url(" + url + ")" > <img>.src = url > <img>.srcset = "1x" + url + ", 2x " + url2 > xhr.open("GET", url) > <style> body { background:url(url) } </style> > > "deferenced"? > Are you asking when it should happen, or when the specs say they do? No spec defines it today, which is what we're trying to fix. My proposal would do it synchronously on assignment. The CSS path is harder if its parse time isn't clearly defined, and if that can't be fixed then it may be impossible to support blob URLs with CSS interoperably, and we'll have to pick whether to live with the interop issues or to not support blob URLs in CSS at all (probably too late for that). Again, this is for all blob URLs, not just autorevoke ones. -- Glenn Maynard
Received on Wednesday, 17 April 2013 13:25:48 UTC