- From: Marijn Kruisselbrink <notifications@github.com>
- Date: Mon, 13 Nov 2017 20:01:27 +0000 (UTC)
- To: w3c/FileAPI <FileAPI@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/FileAPI/issues/89/344040065@github.com>
Yeah, unfortunately the spec is a bit of a mess around the whole Blob URL Store concept (as you point out it sort of is per global, but then there are examples that show two different (same origin) windows "sharing" the same Blob URL Store). That said, there is more subtlety going on here, and I'm not sure your example is entirely correct. First of all I'm not sure how you're detecting "post GC"? I don't think we really spec when a document is garbage collected, just what should happen when it happens. And then another issue with your code is that you seem to (synchronously) create and insert the new iframe after removing the old iframe. This insertion then should (also synchronously) resolve the blob URL (as part of parsing the src attribute), which should resolve the blob URL, and thus loading should generally succeed, even if removing the iframe actually would revoke the URL (since that involves GC and thus almost certainly isn't done synchronously). So yes, lots of room for improvement with how the Blob URL Store is specified, and this is definitely something I hope to work on this quarter (since I'm also working on refactoring parts of the chrome implementation, and running into all kinds of edge cases that aren't clearly specified in the current spec). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/FileAPI/issues/89#issuecomment-344040065
Received on Monday, 13 November 2017 20:02:09 UTC