Re: [whatwg] ProgressEvents for Images
On Thu, Jan 3, 2013 at 9:57 PM, Ian Hickson wrote: > > The particular case above should be fixed, at least in the most common > > cases, by auto-revoking blobs, since you'll no longer need to carefully > > call revokeObjectURL. (I've come to the conclusion that > > URL.revokeObjectURL was a very badly flawed idea, since it introduces > > manual resource management in a platform not designed for it.) > > I'm not exactly clear on what exact words are needed here. If you could > file a bug cc'ing the relevant people with a description of how to make > this work, that'd be great. (I don't think this should be special-cased > for ; there are dozens of other places in the spec where a URL may or > may not be fetched for various reasons.) > I don't think any changes are needed here, aside from the autoRevoke feature moving forward. On Sat, Jan 5, 2013 at 8:06 PM, Garrett Smith wrote: > MSDN mentions a 'onetimeonly' property, and there was an 'isReusable' > property proposal on some list before. > > Having recently had to patch a hot mess of code using that, I agree. It is > ugly. > The IE "onetimeonly" feature has very serious issues, but it was an important step towards the autoRevoke idea. -- Glenn Maynard
Re: [whatwg] ProgressEvents for Images
On Thu, 3 Jan 2013, Glenn Maynard wrote: > > It might make sense to fire onerror if the image doesn't get loaded > because images are disabled. Guaranteeing (or coming closer to > guaranteeing, at least) that onload or onerror will always be fired > would reduce the differences in event flow when images are disabled. When images are disabled, the image will typically be loaded when the user requests that they be loaded, which is when onload should fire. I think it'd be really confusing to have fired onerror first. > The particular case above should be fixed, at least in the most common > cases, by auto-revoking blobs, since you'll no longer need to carefully > call revokeObjectURL. (I've come to the conclusion that > URL.revokeObjectURL was a very badly flawed idea, since it introduces > manual resource management in a platform not designed for it.) I'm not exactly clear on what exact words are needed here. If you could file a bug cc'ing the relevant people with a description of how to make this work, that'd be great. (I don't think this should be special-cased for ; there are dozens of other places in the spec where a URL may or may not be fetched for various reasons.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] ProgressEvents for Images
On Thu, Jan 3, 2013 at 6:49 PM, Ian Hickson wrote:
> > As an aside, it's odd that if images are unsupported or disabled, no
> > event is fired at all ("update the image data", step 4). That means
> > that if you do this:
> >
> > var url = URL.createObjectURL(blob);
> > img.src = url;
> > img.onload = img.onerror = function(e) { URL.revokeObjectURL(url); }
> >
> > the blob will leak a reference if images are disabled. This seems like
> > a very easy mistake to make, with no clean workaround...
>
> It'd be pretty sad to use up all that bandwidth for no reason...
>
Loading the image and discarding the data isn't an option, of course--the
very reason some people disable images is to save bandwidth.
It might make sense to fire onerror if the image doesn't get loaded because
images are disabled. Guaranteeing (or coming closer to guaranteeing, at
least) that onload or onerror will always be fired would reduce the
differences in event flow when images are disabled.
The particular case above should be fixed, at least in the most common
cases, by auto-revoking blobs, since you'll no longer need to carefully
call revokeObjectURL. (I've come to the conclusion that
URL.revokeObjectURL was a very badly flawed idea, since it introduces
manual resource management in a platform not designed for it.)
--
Glenn Maynard
Re: [whatwg] ProgressEvents for Images
On Thu, 12 Jan 2012, Hans Muller wrote:
>
> A group of us at Adobe has been looking into adding support for
> ProgressEvents to images. The overall goal is to simplify image
> download progress reporting by supporting roughly the same progress
> events as XHR and the File API for image elements. For example one
> could connect an image to a progress element like this:
>
> onloadstart="showProgressBar()"
> onprogress="updateProgressBar(event)"
> onloadend="hideProgressBar()"/>
>
> Developers have taken various tacks to enable progress reporting, for
> example in some cases XHR can be used to download image files. Max
> Vujovic just published a blog about the practicalities of doing so:
> http://blogs.adobe.com/openweb/2012/01/13/html5-image-progress-events/.
> We think it would be preferable to provide support for image progress
> events directly.
>
> We're working on a prototype implementation for WebKit and have filed a
> bug that explains what we're up to in a little more detail:
> https://bugs.webkit.org/show_bug.cgi?id=76102).
>
> It's probably worth pointing out that the beforeload event, which is
> currently under discussion, addresses a different use case. Our
> proposal is intended to enable applications to give the user feedback
> about image download progress, it's not intended to enable security or
> efficiency by preemptively blocking or transforming image downloads.
I've added progress events (loadstart, progress, and loadend) to
processing.
On Mon, 23 Jan 2012, Jonas Sicking wrote:
>
> For cross-site images this would leak the compressed size in bytes of
> the loaded image (except when the crossorigin attribute is set). This
> would very unfortunately in many cases leak sensitive information.
>
> But if we restrict these events to only fire for same-origin loads, as
> well as loads where the crossorigin attribute is in effect, then this
> sounds like an awesome idea.
I've restricted the events in this way. ('loadstart' always fires;
'progress' only fires if it's CORS-same-origin, and 'load', 'error', and
'loadend' fire as simple rather than progress events if it's not
CORS-same-origin).
On Mon, 23 Jan 2012, Hans Muller wrote:
>
> A normalized image ProgressEvent would still reveal a little bit about
> the server, even dispatching ProgressEvents with lengthComputable=false
> would do so. As you pointed out, we could avoid this issue altogether
> by not dispatching progress events at all in the unauthorized cross-site
> case, although doing so diminishes the utility of dispatching the
> events.
If you want the events, just use CORS.
On Thu, 23 Feb 2012, Hans Muller wrote:
>
> Ian Hickson and I have been debating the merits of adding support for
> the loadend event to images on
> https://bugs.webkit.org/show_bug.cgi?id=76102. Dirk Schulze requested
> that the discussion be relocated here, since it's about a feature and
> not the details of an implementation change.
>
> Here's a recap, if you don't want to wade through the bug comments:
>
> Hans - You're saying that the [image] loadend event is useless?
>
> Ian - Yes. It only saves typing a few characters, img.onloadend =
> function () { }; vs: img.onload = img.onerror = function () { };
>
> Hans - It's useful if you want your listener to run after all of the
> load listeners have run, and code that you haven't written adds its own
> load listeners.
>
> Ian - That seems like a rather obscure edge case, and you can work
> around it using setTimeout() (in the load/error event handler) anyway.
>
> Before carrying on, I should point out that the proposal to add
> loadstart, progress, and loadend events to Image was modeled on XHR and
> based on the ProgressEvent spec http:// www.w3.org/TR/progress-events/.
Note that progress events are now specced in http://xhr.spec.whatwg.org/.
> It may be that supporting the complete set of ProgressEvents for images
> doesn't add enough utility to be warranted. We proposed supporting all
> of the ProgressEvents (even loadend) for the sake of consistency. And
> we're aware of the CORS issues.
I did add them all for consistency (well, almost all, I didn't add
'stalled' and 'timeout'), but loadend is still basically useless. :-)
On Fri, 24 Feb 2012, Glenn Maynard wrote:
>
> It seems odd that loadend is considered useful enough to be recommended
> by Progress Events, but not useful enough to be used here.
I don't think it's useful in other uses of Progress Events either.
> As an aside, it's odd that if images are unsupported or disabled, no
> event is fired at all ("update the image data", step 4). That means
> that if you do this:
>
> var url = URL.createObjectURL(blob);
> img.src = url;
> img.onload = img.onerror = function(e) { URL.revokeObjectURL(url); }
>
> the blob will leak a reference if images are disabled. This seems like
> a very easy mistake to make, with no clean workaround...
It'd be pretty sad
Re: [whatwg] ProgressEvents for Images
It seems odd that loadend is considered useful enough to be recommended by
Progress Events, but not useful enough to be used here.
As an aside, it's odd that if images are unsupported or disabled, no event
is fired at all ("update the image data", step 4). That means that if you
do this:
var url = URL.createObjectURL(blob);
img.src = url;
img.onload = img.onerror = function(e) { URL.revokeObjectURL(url); }
the blob will leak a reference if images are disabled. This seems like a
very easy mistake to make, with no clean workaround...
--
Glenn Maynard
Re: [whatwg] ProgressEvents for Images
On 2/24/12 12:36 PM, Hans Muller wrote: Good point, although this approach seems to lead to the very same dystopia you were just warning about. If everyone tries to schedule their image listener last with setTimeout()... Sure. There's no way to fix that problem technologically. Just saying that the option to try the "works if only I do it" solution is already there without loadend. -Boris
Re: [whatwg] ProgressEvents for Images
On 2/23/12 5:23 PM, "Boris Zbarsky" wrote:
>On 2/23/12 7:38 PM, Hans Muller wrote:
>>Hans - It's useful if you want your listener to run after all of the
>>load listeners have run, and code that you haven't written adds its own
>>load listeners.
>
>I strongly urge you to read
>http://blogs.msdn.com/b/oldnewthing/archive/2005/06/07/426294.aspx
>
>Or put another way, what will you do a year after this is standardized,
>when the code that you haven't written is adding loadend listeners?
If loadend listeners were used as intended and not as a proxy for "code to
run last,
after everything else", then years from now I'll carry on using them to
run code
after the load and error listeners have run. That said, I understand your
point.
To use loadend in the scenario I posed, you have to know that the function
you're
calling is doing something with load/error listeners that you'd like to
follow
with your own listener.
>
>>The problem with using setTimeout() to schedule a listener to run after
>>all of image's load listeners has run is that you've got to guess how
>>long
>>loading the image (or failing to load the image) and running its
>>listeners
>>will take.
>
>No, you don't. You simply do:
>
> function delayedLoadStuff() {
> setTimeout(doTheThingIWant, 0);
> }
> img.addEventListener("load", delayedLoadStuff, false);
> img.addEventListener("error", delayedLoadStuff, false);
Good point, although this approach seems to lead to the very same dystopia
you
were just warning about. If everyone tries to schedule their image
listener last
with setTimeout()...
- Hans
Re: [whatwg] ProgressEvents for Images
On 2/23/12 7:38 PM, Hans Muller wrote:
Hans - It's useful if you want your listener to run after all of the
load listeners have run, and code that you haven't written adds its own
load listeners.
I strongly urge you to read
http://blogs.msdn.com/b/oldnewthing/archive/2005/06/07/426294.aspx
Or put another way, what will you do a year after this is standardized,
when the code that you haven't written is adding loadend listeners?
The problem with using setTimeout() to schedule a listener to run after
all of image's load listeners has run is that you've got to guess how long
loading the image (or failing to load the image) and running its listeners
will take.
No, you don't. You simply do:
function delayedLoadStuff() {
setTimeout(doTheThingIWant, 0);
}
img.addEventListener("load", delayedLoadStuff, false);
img.addEventListener("error", delayedLoadStuff, false);
If applications where multiple image load listeners are added by different
modules really are a rarity (I wouldn't know) then I'll be happy to
concede that loadend isn't needed.
And they are aren't, then it doesn't help, except in the very short term
until those modules start using loadend themselves
-Boris
Re: [whatwg] ProgressEvents for Images
Ian Hickson and I have been debating the merits of adding support for the
loadend event to images on https://bugs.webkit.org/show_bug.cgi?id=76102.
Dirk Schulze requested that the discussion be relocated here, since it's
about a feature and not the details of an implementation change.
Here's a recap, if you don't want to wade through the bug comments:
Hans - You're saying that the [image] loadend event is useless?
Ian - Yes. It only saves typing a few characters, img.onloadend =
function () { }; vs: img.onload = img.onerror = function () { };
Hans - It's useful if you want your listener to run after all of the
load listeners have run, and code that you haven't written adds its own
load listeners.
Ian - That seems like a rather obscure edge case, and you can work
around it using setTimeout() (in the load/error event handler) anyway.
Before carrying on, I should point out that the proposal to add loadstart,
progress, and loadend events to Image was modeled on XHR and based on the
ProgressEvent spec http:// www.w3.org/TR/progress-events/. It may be that
supporting the complete set of ProgressEvents for images doesn't add
enough utility to be warranted. We proposed supporting all of the
ProgressEvents (even loadend) for the sake of consistency. And we're
aware of the CORS issues.
That said, here is the example I'd made, to demo the utility of a loadend
listener:
function notMyShowImageFunction(image, url)
{
image.onload = doSomethingAtLoadTime;
image.src = url;
}
image.onloadend = doThisAfterAllLoadListenersHaveRun;
notMyShowImageFunction(image, "...");
The problem with using setTimeout() to schedule a listener to run after
all of image's load listeners has run is that you've got to guess how long
loading the image (or failing to load the image) and running its listeners
will take.
If applications where multiple image load listeners are added by different
modules really are a rarity (I wouldn't know) then I'll be happy to
concede that loadend isn't needed. If they are not, as I assume similar
XHR applications are not, then I don't think it's fair to characterize the
loadend event as useless.
- Hans
Re: [whatwg] ProgressEvents for Images
On Mon, Jan 23, 2012 at 8:44 AM, Hans Muller wrote: > Thanks for the encouraging words. > > For cross-site images for which crossOrigin is not set, we'd proposed > "normalizing" the loaded and size ProgressEvent attributes: > > https://bugs.webkit.org/show_bug.cgi?id=76102 > ProgressEvents for cross-origin images should not reveal the actual > resource size per > http://www.w3.org/TR/progress-events/#security-considerations. This could > be avoided by dispatching ProgressEvents with lengthComputable=false (and > loaded=0, total=0) for cross-origin images. Alternatively we could > dispatch a subclass of ProgressEvent with normalized total and loaded > attributes. A normalized image ProgressEvent wouldn't expose the actual > size of the resource being downloaded but it would still enable developers > to observe relative progress. Normalization would set total to a constant > like 1000, and loaded to a relatively correct value. > > A normalized image ProgressEvent would still reveal a little bit about the > server, even dispatching ProgressEvents with lengthComputable=false would > do so. As you pointed out, we could avoid this issue altogether by not > dispatching progress events at all in the unauthorized cross-site case, > although doing so diminishes the utility of dispatching the events. I don't know if this would still leak some information. For example, are packet sizes reliable enough that you can estimate the downloaded size by simply counting the number of ProgressEvents? I don't have a strong opinion as I don't feel that I know enough. / Jonas
Re: [whatwg] ProgressEvents for Images
Thanks for the encouraging words. For cross-site images for which crossOrigin is not set, we'd proposed "normalizing" the loaded and size ProgressEvent attributes: https://bugs.webkit.org/show_bug.cgi?id=76102 ProgressEvents for cross-origin images should not reveal the actual resource size per http://www.w3.org/TR/progress-events/#security-considerations. This could be avoided by dispatching ProgressEvents with lengthComputable=false (and loaded=0, total=0) for cross-origin images. Alternatively we could dispatch a subclass of ProgressEvent with normalized total and loaded attributes. A normalized image ProgressEvent wouldn't expose the actual size of the resource being downloaded but it would still enable developers to observe relative progress. Normalization would set total to a constant like 1000, and loaded to a relatively correct value. A normalized image ProgressEvent would still reveal a little bit about the server, even dispatching ProgressEvents with lengthComputable=false would do so. As you pointed out, we could avoid this issue altogether by not dispatching progress events at all in the unauthorized cross-site case, although doing so diminishes the utility of dispatching the events. - Hans On 1/23/12 4:58 AM, "Jonas Sicking" wrote: >On Thu, Jan 12, 2012 at 4:19 PM, Hans Muller wrote: >> A group of us at Adobe has been looking into adding support for >>ProgressEvents to images. The overall goal is to simplify image >>download progress reporting by supporting roughly the same progress >>events as XHR and the File API for image elements. For example one >>could connect an image to a progress element like this: >> >> >onloadstart="showProgressBar()" >>onprogress="updateProgressBar(event)" >>onloadend="hideProgressBar()"/> >> >> Developers have taken various tacks to enable progress reporting, for >>example in some cases XHR can be used to download image files. Max >>Vujovic just published a blog about the practicalities of doing so: >>http://blogs.adobe.com/openweb/2012/01/13/html5-image-progress-events/. >>We think it would be preferable to provide support for image progress >>events directly. >> >> We're working on a prototype implementation for WebKit and have filed a >>bug that explains what we're up to in a little more detail: >>https://bugs.webkit.org/show_bug.cgi?id=76102). >> >> It's probably worth pointing out that the beforeload event, which is >>currently under discussion, addresses a different use case. Our >>proposal is intended to enable applications to give the user feedback >>about image download progress, it's not intended to enable security or >>efficiency by preemptively blocking or transforming image downloads. >> >> We'd appreciate feedback on this proposal. > >For cross-site images this would leak the compressed size in bytes of >the loaded image (except when the crossorigin attribute is set). This >would very unfortunately in many cases leak sensitive information. > >But if we restrict these events to only fire for same-origin loads, as >well as loads where the crossorigin attribute is in effect, then this >sounds like an awesome idea. > >/ Jonas
Re: [whatwg] ProgressEvents for Images
On Thu, Jan 12, 2012 at 4:19 PM, Hans Muller wrote: > A group of us at Adobe has been looking into adding support for > ProgressEvents to images. The overall goal is to simplify image download > progress reporting by supporting roughly the same progress events as XHR and > the File API for image elements. For example one could connect an image to > a progress element like this: > > onloadstart="showProgressBar()" > onprogress="updateProgressBar(event)" > onloadend="hideProgressBar()"/> > > Developers have taken various tacks to enable progress reporting, for example > in some cases XHR can be used to download image files. Max Vujovic just > published a blog about the practicalities of doing so: > http://blogs.adobe.com/openweb/2012/01/13/html5-image-progress-events/. We > think it would be preferable to provide support for image progress events > directly. > > We're working on a prototype implementation for WebKit and have filed a bug > that explains what we're up to in a little more detail: > https://bugs.webkit.org/show_bug.cgi?id=76102). > > It's probably worth pointing out that the beforeload event, which is > currently under discussion, addresses a different use case. Our proposal is > intended to enable applications to give the user feedback about image > download progress, it's not intended to enable security or efficiency by > preemptively blocking or transforming image downloads. > > We'd appreciate feedback on this proposal. For cross-site images this would leak the compressed size in bytes of the loaded image (except when the crossorigin attribute is set). This would very unfortunately in many cases leak sensitive information. But if we restrict these events to only fire for same-origin loads, as well as loads where the crossorigin attribute is in effect, then this sounds like an awesome idea. / Jonas
Re: [whatwg] ProgressEvents for Images
I've wanted this before. It would be useful for more granular loading progress indicators for eg. WebGL apps, for example, and anything else that loads images without displaying them as they load. On Jan 12, 2012 4:20 PM, "Hans Muller" wrote: > A group of us at Adobe has been looking into adding support for > ProgressEvents to images. The overall goal is to simplify image download > progress reporting by supporting roughly the same progress events as XHR > and the File API for image elements. For example one could connect an > image to a progress element like this: > > onloadstart="showProgressBar()" >onprogress="updateProgressBar(event)" >onloadend="hideProgressBar()"/> > > Developers have taken various tacks to enable progress reporting, for > example in some cases XHR can be used to download image files. Max Vujovic > just published a blog about the practicalities of doing so: > http://blogs.adobe.com/openweb/2012/01/13/html5-image-progress-events/. > We think it would be preferable to provide support for image progress > events directly. > > We're working on a prototype implementation for WebKit and have filed a > bug that explains what we're up to in a little more detail: > https://bugs.webkit.org/show_bug.cgi?id=76102). > > It's probably worth pointing out that the beforeload event, which is > currently under discussion, addresses a different use case. Our proposal > is intended to enable applications to give the user feedback about image > download progress, it's not intended to enable security or efficiency by > preemptively blocking or transforming image downloads. > > We'd appreciate feedback on this proposal. > >
