Lazyload images cannot load immediately from the list of available im… #42780
Conversation
html/semantics/embedded-content/the-img-element/image-loading-lazy-different-crossorigin.html
Outdated
Show resolved
Hide resolved
html/semantics/embedded-content/the-img-element/image-loading-lazy-different-crossorigin.html
Outdated
Show resolved
Hide resolved
html/semantics/embedded-content/the-img-element/image-loading-lazy-different-crossorigin.html
Outdated
Show resolved
Hide resolved
html/semantics/embedded-content/the-img-element/image-loading-lazy-different-crossorigin.html
Outdated
Show resolved
Hide resolved
html/semantics/embedded-content/the-img-element/image-loading-lazy-different-crossorigin.html
Outdated
Show resolved
Hide resolved
html/semantics/embedded-content/the-img-element/image-loading-lazy-different-crossorigin.html
Show resolved
Hide resolved
…ages if they differ with 'crossorigin' In #updating-the-image-data [1], all images including lazyloaded ones are able to load immediately from the list of available images. Each image in list is identified by a tuple consisting of an absolute URL and CORS settings attribute mode (with origin if mode is NO-CORS). So if the crossorigin attribute of the lazyloaded image and the one from "list of available images" are different then lazyloaded one is not able to load immediately from the list of available images. This CL adds a test for the case when eagerly loaded image does not contain 'crossorigin' attribute and the lazyloaded one (out-of-viewport) contains crossorigin="anonymous". In this case lazyloaded one is not loaded immediately from the list of available images. [1] https://html.spec.whatwg.org/multipage/images.html#updating-the-image-data [2] https://html.spec.whatwg.org/multipage/urls-and-fetching.html#cors-settings-attribute
pgorszkowski-igalia
force-pushed
the
pgorszkowski/image_loading_lazy_different_crossorigin
branch
from
84504bf
to
9d4a7e7
Compare
|
One more thing: my test covers only the case when eagerly loaded image does not have |
I actually think we don't need to be 100% exhaustive in testing all possible combinations. Using what you have here as a fair representation of non-matching "list of available image" cache keys seems fine to me. |
|
It seems that every browser currently passes this test (https://wpt.fyi/results/?label=pr_head&max-count=1&pr=42780), is that your understanding too? That is, all browsers are interoperable in this case? |
yes, that is expected. I tested it also with FireFox , Chrome and WebKitGTK. I would say that if browser passes both tests: it means that browser support using list of available images by lazy loaded img. In case when browser does not support correctly using of list of available images by lazy loaded img, browser can pass |
…ages if they differ with 'crossorigin'
In #updating-the-image-data [1], all images including lazyloaded ones are able to load immediately from the list of available images. Each image in list is identified by a tuple consisting of an absolute URL and CORS settings attribute mode (with origin if mode is NO-CORS). So if the crossorigin attribute of the lazyloaded image and the one from "list of available images" are different then lazyloaded one is not able to load immediately from the list of available images.
This CL adds a test for the case when eagerly loaded image does not contain 'crossorigin' attribute and the lazyloaded one (out-of-viewport) contains crossorigin="anonymous". In this case lazyloaded one is not loaded immediately from the list of available images.
[1] https://html.spec.whatwg.org/multipage/images.html#updating-the-image-data
[2] https://html.spec.whatwg.org/multipage/urls-and-fetching.html#cors-settings-attribute