- From: Arun Ranganathan <aranganathan@mozilla.com>
- Date: Fri, 24 Feb 2012 11:49:26 -0800 (PST)
- To: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
- Cc: public-webapps@w3.org
> On 24.2.2012 20:12, Arun Ranganathan wrote: > > Bronislav, > > > > > >> I could also go with reverse approach, with createObjectURL being > >> oneTimeOnly by default > >> createObjectURL(Blob aBlob, boolean? isPermanent) > >> instead of current > >> createObjectURL(Blob aBlob, boolean? isOneTime) > >> the fact, that user would have to explicitly specify, that such > >> URL > >> is > >> permanent should limit cases of "I forgot to release something > >> somewhere"... and I thing could be easier to understant, that > >> explicit > >> request for pemranent = explicit release. Would break current > >> implementations, sure, but if we are considering changes.... > > > > So, having these URLs be "oneTimeOnly" by default itself has > > issues, as Glenn (and Darin) point out: > > > > http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0377.html > > > > The existing model makes that scenario false by default, trading > > off anything "racy" against culling strings. > We are back in an issue of someone using oneTimeOnly or permanent in > an > inappropriate case. Programmers should be aware of what they are > doing. > I actually have no problem with current specification (rermanent as > default, expicit release), I'm just trying to prevent changes like > assigning object to string attribute (e.g. src), returning innerHTML > with empty string attribute (e.g. src) My solution is that src should be modified to take both a string and a URL object, which makes innerHTML behavior easier; I'm less sure of it taking Blob directly. -- A*
Received on Friday, 24 February 2012 19:49:53 UTC