[Bug 24576] Calling URL.createObjectURL() on a closed Blob

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24576

Simon Pieters <simonp@opera.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #21 from Simon Pieters <simonp@opera.com> ---
So you have changed your mind about createObjectURL?

(In reply to Arun from comment #19)
> So, after chatting with Jonas on IRC, I think Comment 11 is right about not
> throwing for URL.createObjectURL and URL.createFor,

Comment 11 is about close().

> since this might put the
> burden of try/catch on a developer just trying to coin a URL.

Yeah.

> But this does mean that some methods will throw, and some won't.  I think
> FileReader.readAsxxx throwing is fine; I think close() itself throwing if
> closing an already closed Blob is fine. Any of those failing differently
> seems confusing.

So the benefit you see with close() throwing is that it's consistent with
readAs*? I think that's not so convincing. I think similar reasoning for
createObjectURL() applies to close() -- throwing puts the burden of try/catch
on a developer just trying to close a Blob. (Reopening for
reconsideration/clarification about close().)

> Based on Comment 11, it seems your suggestion is to have the behavior be
> when called on a closed blob, URL.create* will return a URL which when
> Parse/Fetch'd will return a network error. OK.

s/11/14/ ?

I think that's OK, yes.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 27 March 2014 13:39:44 UTC