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

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

Received on Friday, 23 December 2016 10:04:14 UTC