Images should NOT refetch upon insertion even if the document's base URL has changed

[domfarolino]

Consider the following:

const image = new Image();
image.src = "image.jpg";

const base = document.createElement('base');
base.href = '/resources/';
document.head.append(base);

// Some time later
document.body.append(image); // Does this refetch?

The answer to // Does this refetch? is:

• Chrome: Yes
• Firefox: Yes
• Safari: No
• Spec: No

Per spec the answer is no because general element insertion is not one of the img's relevant mutations. If we wanted to match Chrome and Firefox's behavior, we should make general insertion one of the relevant mutations -- but I think that's not enough. Neither Chrome nor Firefox always attempt to refetch upon insertion, they only do so if the last known snapshot of the document's base URL has changed. We should probably change the spec to account for this extra snapshot piece of information, but we should open this up for more discussion and opinions.

/cc @emilio

[annevk]

I think this is whatwg/dom#61.

[domfarolino]

I actually don't quite think it is. Perhaps this is kinda a subset of whatwg/dom#61, but the main question here seems to be: should an image element internally store a snapshot of the base URL that it encountered upon first invocation of #update-the-image-data, to compare with the document's live base URL when the next relevant mutation is experienced?

Chrome and Firefox do this, but the spec and Safari do not. Spec & Safari's behavior (no base URL snapshot) is the simplest, and I'm leaning towards making Chrome do the same in https://chromium-review.googlesource.com/c/chromium/src/+/3311225, which I'd like to land with a WPT. @emilio what do you think about this? If I can land that CL in Chromium, I'll close this issue, but in the meantime it would be good to hear from FF.

[emilio]

I'm confused. Gecko doesn't special case the base URI afaict, we just don't force-reload if the current source is already the same on insertion. Our model is more similar to "make insertion a relevant mutation": https://searchfox.org/mozilla-central/rev/861fb9abfcaff123aab45f6ac56a0106b116dc14/dom/html/HTMLImageElement.cpp#587

You kinda need to do that for picture / srcset to deal for when an image is moving from one document to another with different viewport sizes etc, right?

[emilio]

(or specify another point more specific to adoption perhaps)

[emilio]

Cc @EdgarChen

[emilio]

The note in https://html.spec.whatwg.org/multipage/images.html#img-environment-changes recommends running that algorithm with images get inserted into the document, which does run the source selection algorithm. That's basically what Gecko is doing, though I'd need to check how precisely we implement that algorithm, let me know if you'd need that.

[domfarolino]

You kinda need to do that for picture / srcset to deal for when an image is moving from one document to another with different viewport sizes etc, right?

Yes, and insertion is considered a "relevant mutation" when the img is a child of a picture element: https://html.spec.whatwg.org/#the-img-element:html-element-insertion-steps / https://html.spec.whatwg.org/#when-to-obtain-images:relevant-mutations.

---

Let me make sure I've got the scenario right. When I run the following script, akin to the code in the OP:

const image = new Image();
image.src = "image.jpg";

const base = document.createElement('base');
base.href = '/resources/';
document.head.append(base);

setTimeout(() => {
  document.body.append(image);
}, 2000);

... in Firefox DevTools I see two image requests:

• An immediate request for /image.jpg
• Another request 2 seconds later for /resources/image.jpg

Two things here surprise me:

• That FF's first request is not influenced by the base URL; per the #update-the-image-data algorithm, source selection takes place after the microtask, so any document state mutation that happens synchronously after image creation should impact the image request (that's basically the goal of that microtask)
• That Firefox fetches a second request. I don't think element element insertion in this case is considered a relevant mutation, so I'm not sure what is triggering the image to be refetched. Do you?

---

Overall here is the current state of affairs:

• Firefox's first request is wrong; its second request should not be made (but when made, is "correct")
• Safari's first request is wrong; it does not make a second request (which is "correct")
• Chrome's first request is right; nevertheless, it makes a second request when I think it should not, whose URL is also right (the second request is triggered by some bogus logic that I'm going planning on removing)

[emilio]

Yeah Firefox triggering the first load is a known long-standing bug.

[domfarolino]

Do you agree that per spec, the second request should not be made (the one after 2 seconds), since general (non-<picture>) insertion is not considered a relevant mutation for #update-the-image-data?

[emilio]

Yes, iff the first request does account for the base change. I'd expect two different requests if there's a microtask checkpoint after the src assignment but before the base change.

[domfarolino]

I'd expect two different requests if there's a microtask checkpoint after the src assignment but before the base change.

Why would changing a document's base URL after an image's microtask checkpoint has already been run somehow refetch that image, and re-resolve its URL?

1. Microtask checkpoint reached; image request is made
2. Document's base URL is manipulated
3. Image is inserted into DOM — I don't think this should cause a re-fetch due to the document base URL changing from the last time the image is fetched; refetching would mean counting insertion as a "relevant mutation" and keeping track of the old state of the base URL, I think

[emilio]

Ah, you're right. I thought https://html.spec.whatwg.org/multipage/images.html#img-environment-changes would run on insertion, and the source would be different and thus we'd load the new image. I guess that since that algorithm has a:

• If the img element does not use srcset or picture, its node document is not fully active, has image data whose resource type is multipart/x-mixed-replace, or the pending request is not null, then return.

We shouldn't really reload in the src case. For srcset / picture, I believe that per spec we also shouldn't reload, but that's a bit more subtle.

I guess the selected source that gets compared is the relative URI rather than the "resolved" URI against the document's base URI. Does that match what other browsers do? We compare the fully-resolved URI, though it seems Blink at least is following the spec (on this regard, but density doesn't seem to be checked, see #4646).

Having tests for all this would be great...

[domfarolino]

I guess the selected source that gets compared is the relative URI rather than the "resolved" URI against the document's base URI. Does that match what other browsers do? We compare the fully-resolved URI, though it seems Blink at least is following the spec

How do we know that Blink is following the spec here? Just so we're clear, you're now talking about something different than the original post here right, since we've established that there should only be a single question here, and therefore any steps after the following are not run:

If the img element does not use srcset or picture, its node document is not fully active, has image data whose resource type is multipart/x-mixed-replace, or the pending request is not null, then return.

---

Having tests for all this would be great...

Agreed. I found that we have the image-base-url.html WPT that I added in 2020 which covers the 3-step scenario I mentioned above in #7383 (comment), but I think we need another one to assert that not only the correct request is finally made, but that only a single request is made, and that spurious ones are not triggered due to the base URL changing in between microtask scheduling and execution. I'm adding that in https://crrev.com/c/3311225.

[domfarolino]

@emilio feel free to check out web-platform-tests/wpt#38275 where I modify the test I originally wrote for the OP of this issue and extend it to cover the "second fetching" case, where the base URL is modified after the image is fetched but before it is inserted.

Once that is landed, I'll file some browser bugs and close this issue.

[emilio]

I guess the selected source that gets compared is the relative URI rather than the "resolved" URI against the document's base URI. Does that match what other browsers do? We compare the fully-resolved URI, though it seems Blink at least is following the spec

How do we know that Blink is following the spec here?

Just by code inspection.

Just so we're clear, you're now talking about something different than the original post here right, since we've established that there should only be a single question here, and therefore any steps after the following are not run:

That's right. If you change src with srcset, then should it run? If we define the URL comparison on the parsed / resolved URI, then it should, but otherwise it should not.

Agreed. I found that we have the image-base-url.html WPT that I added in 2020 which covers the 3-step scenario I mentioned above in #7383 (comment), but I think we need another one to assert that not only the correct request is finally made, but that only a single request is made, and that spurious ones are not triggered due to the base URL changing in between microtask scheduling and execution. I'm adding that in https://crrev.com/c/3311225.

Thanks, that's great :)

[domfarolino]

That's right. If you change src with srcset, then should it run? If we define the URL comparison on the parsed / resolved URI, then it should, but otherwise it should not.

Yep that makes sense to me; if you changed src/srcset or if we defined the URL comparison (that takes place in step 5 of #reacting-to-environment-changes) to not be relative, then it seems the image would be refetched upon insertion if the Document's base URL has changed. Do you think there is any appetite to do this? Do browser disagree on this case currently?

If not, since my CL with the test has landed, I'm happy to file a couple browser bugs and close this issue.

[domfarolino]

Filed:

• https://bugs.webkit.org/show_bug.cgi?id=253261
• https://bugzilla.mozilla.org/show_bug.cgi?id=1820030

I'll go ahead and close this.