On Tue, Apr 14, 2015 at 9:03 AM, Justin Novosad <ju...@google.com> wrote:

> On Sun, Apr 12, 2015 at 5:41 PM, Robert O'Callahan <rob...@ocallahan.org>
> wrote:
> > On Sat, Apr 11, 2015 at 1:49 PM, Kenneth Russell <k...@google.com> wrote:
> >
> >>
> >> 3. Are onload and onerror events fired? This question applies both to
> >> the in-progress download and to the transferred-in ImageBitmap.
> >>
> >
> > No.
> >
> From the web developer's perspective wouldn't that lead to
> non-deterministic behavior?  What I mean is that if the onload listener was
> not yet called at the time an ImageBitmap is transferred in, the onload
> listener may still get called depending on whether the onload event was
> already dispatched when the ImageBitmap transfer occurred.  That's a race.
> This makes me wonder... is there a precedent for recalling dispatched
> events?

Yes. Media elements, for example, dispatch tasks to an element-specific
task source, which is emptied when a new load starts:

Having said that, the sort of races that you've identified are endemic to
the Web platform. For example the spec (and implementations) allow an <img>
"load" event to fire after a different image has already started loading in
the <img>. So I don't think there's a new problem here.

Having said that^2, I should probably amend my suggestion so that we
dispatch the "error" event per section 9.2, with the condition amended to
"if the element has a src attribute or a srcset attribute or a parent that
is a picture element *and the has-an-ImageBitmap flag was not already
set*", so dispatch of events for non-ImageBitmap-loads is not affected.

oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
otohoeo ofoioroeo ooofo ohoeololo.

Reply via email to