Open Bug 1613277 Opened 4 years ago Updated 2 years ago

Make loading/lazyload/original-{base-url,crossorigin,refererrer-policy}-applied-tentative.sub.html pass

Categories

(Core :: DOM: Core & HTML, defect, P3)

defect

Tracking

()

People

(Reporter: hiro, Unassigned)

References

Details

This will be a follow up bug for lazy-loading (bug 1542784).

These tests are supposed to expect that changing base url doesn't affect lazy-load images once after its target url was resolved. That's true as per the spec.

As per the "updating-the-image-data", the step for resolving URL is done in the step 11;

  1. Parse selected source, relative to the element's node document, and let
    urlString be the resulting URL string. If that is not successful

Then in the step 22;

  1. If the will lazy load image steps given the img return true, then run
    these steps:

So after the step 11, the resolved URL will never be changed even if it's for
lazy-load images.

Basically, these tests expect that relevant steps are done asynchronously, but we don't yet do it (bug 1076583).

Emilio suggested to use QueueImageLoadTask (which is for asynchronous) for lazy-loading in a review comment, but I'd think we should fix bug 1076583 first.

Edgar, any insights on this?

Flags: needinfo?(echen)

I would think we could just use QueueImageLoadTask unconditionally for lazyload given that lazyload is a new feature, it would be good to follow the spec if possible in order to not introduce new compatibility problem. If we encounter any issue while using QueueImageLoadTask, then we should fix it. Does this make sense?

Flags: needinfo?(echen)

That sounds weird. For example, loading="lazy" image elements in view behave as normal image, so it's possible to cause exactly same issues which preventing bug 1076583. If those issues can be acceptable, which means we can just ship bug 1076583 I think.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.