You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After talking with @zcorpan and @rwlbuis, it seems there is an issue in the current specification for images with loading=lazy specified.
The updating-the-image-data algorithm at step (7), queues a microtask to continue the rest of the steps. Interestingly, any number of "relevant mutations" can happen by the time this algorithm is resumed, and therefore any number of "extra" invocations of updating-the-image-data can be started. This is why step (8) exists, which effectively kills any "outdated" invocations of this algorithm, so only the latest takes effect.
When we introduced lazyloading for images, we added another stopping point in this algorithm, that allows the algorithm to be resumed later (i.e., when the image intersects the viewport). During this async stopping point, again any number of "relevant mutations" can take place, starting an arbitrary number of invocations of this algorithm. We didn't add another step after the potential resumption similar to (8), to kill outdated invocations of the algorithm though. So per spec, I believe it is possible that N number of updating-the-image-data-algorithms can be running for any given <img> which is not good. I think we should add a step similar to (8), after the lazyload resumption, and verify that all of our tests assert this behavior. Does this sound good?
After talking with @zcorpan and @rwlbuis, it seems there is an issue in the current specification for images with
loading=lazy
specified.The updating-the-image-data algorithm at step (7), queues a microtask to continue the rest of the steps. Interestingly, any number of "relevant mutations" can happen by the time this algorithm is resumed, and therefore any number of "extra" invocations of updating-the-image-data can be started. This is why step (8) exists, which effectively kills any "outdated" invocations of this algorithm, so only the latest takes effect.
When we introduced lazyloading for images, we added another stopping point in this algorithm, that allows the algorithm to be resumed later (i.e., when the image intersects the viewport). During this async stopping point, again any number of "relevant mutations" can take place, starting an arbitrary number of invocations of this algorithm. We didn't add another step after the potential resumption similar to (8), to kill outdated invocations of the algorithm though. So per spec, I believe it is possible that N number of updating-the-image-data-algorithms can be running for any given
<img>
which is not good. I think we should add a step similar to (8), after the lazyload resumption, and verify that all of our tests assert this behavior. Does this sound good?/cc @annevk @kinu
The text was updated successfully, but these errors were encountered: