Re: Bug in Acid3 test #72 (race condition when images decode asynchronously)

I believe this is non-conforming. data: URLs are defined to be fetched
synchronously and image decoding to obtain dimensions is defined to happen
instantaneously (for non-data: URLs, this is black-box indistinguishable
from it being rolled into the network delay, of course).

Specifically, see step 14 of "update the image data", noting that
everything up to step 13 happens synchronously from the parser, then the
fetching happens as per the fetch spec in one task (because it's a data:
URL, it's not asynchronous), and that triggers step 14 which requires the
image to be decoded and the size determined synchronously in a single task.

-- 
Ian Hickson

On Fri, Dec 23, 2016 at 2:03 AM Daniel Holbert <dholbert@mozilla.com> wrote:

> On 12/23/2016 12:06 AM, Ian Hickson wrote:
> > The image in question is a data: URL. There's a ten millisecond gap
> > between the last test and this test. That guarantees that there's at
> > least one opportunity to handle the microtask in which the data: URL
> > gets loaded. As far as I can tell this means that by the time the height
> > property accessor is read, it's guaranteed that the image is loaded.
>
> Nah, it's actually not guaranteed to be loaded -- hence the bug that was
> filed for Firefox failing this subtest. :)
>
> In current Firefox versions, image-decoding actually happens on a
> *helper-thread* -- not in a main-thread microtask. So, depending on
> thread-switching / signalling overhead, the image very well might not
> have been decoded (& had its results reported back) when the 10
> millisecond timeout expires. Hence, it may very well be in the
> spec-defined "unavailable" state at that point, when the test reads the
> <img> size.
>
> You might think that this is silly and we should redesign this to decode
> image sizes faster, and you'd perhaps be right.
>
> But whether we redesign it or not, our current behavior *is* compliant
> with the HTML spec.  And I don't see why the Acid3 test should
> arbitrarily mandate a decode-in-10ms behavior.
>
> I linked to a patch in my initial post, which simply makes the test
> check whether the image is ready before reading the size (& retry if
> not).  Given the above explanation (and the spec discussion in my
> initial post), does my suggested change seem reasonable?
>
> Thanks,
> ~Daniel
>
-- 

-- 
Ian Hickson

😸