- From: <bugzilla@jessica.w3.org>
- Date: Tue, 22 Apr 2014 19:01:53 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25081 --- Comment #22 from Jonas Sicking <jonas@sicking.cc> --- What we need here is an algorithm which does something like the following. Note that this algorithm would be started synchronously from any API which reads from Blobs. 1. Check the closed flag. If the closed flag is set to true then queue a task which returns a IO error from this algorithm. This step is always done asynchronously. 2. Create a clone of the Blob and call the new clone /clone/ 2. If the synchronous flag is true, then synchronously read the contents of /clone/. If an IO error occurs then return an IO error from this algorithm. If no IO error occurs then return the contents of the Blob. Either way abort this algorithm. 3. (The synchronous flag should at this point always be false). Queue a task to read the contents of /clone/. If reading the contents of /clone/ results in an IO error, then return an error. Otherwise return the contents of the blob. There's obviously a lot of handwaving here. But the important part is that we should always synchronously check the closed flag. For things like reading from a blob URL there is of course the question about when we invoke the algorithm. I.e. does setting img.src = myblobURL synchronously invoke the read algorithm, or does it happen at some later undefined asynchronous point in time. I think this is exactly the same question that we've been struggling with when it comes to revoked URLs. But all APIs that deal with Blob instances should synchronously invoke the above algorithm, and would thus synchronously check the closed flag. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Tuesday, 22 April 2014 19:01:58 UTC