Use the keepalive flag when fetching images

[domenic]

https://fetch.spec.whatwg.org/#keepalive-flag indicates the flag should be set for images, but it is not.

Maybe wait until #1643 is done.

[zcorpan]

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4372
The image fetch is canceled in Chromium/Gecko/WebKit according to devtools.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4373
The image fetch appears to not be canceled in Chromium/Gecko/WebKit.

How this is implemented I'm not sure.

[domenic]

Wat :(

[zcorpan]

sigbjornf says this may be relevant

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/loader/ImageLoader.cpp?q=ImageLoader::updatedHasPendingEvent&sq=package:chromium&l=519&dr=CSs

[domenic]

For the record, this was originally https://www.w3.org/Bugs/Public/show_bug.cgi?id=24597, although there isn't too much more detail there.

[yoavweiss]

sigbjornf says this may be relevant

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/loader/ImageLoader.cpp?q=ImageLoader::updatedHasPendingEvent&sq=package:chromium&l=519&dr=CSs

That code is no longer relevant, but I suspect its current-day equivalent is here

It seems like images are getting set to be kept alive only when the element is updated during a page dismissal event. My guess is that it's something that was added before sendBeacon() and fetch keepalive flag as a way to achieve the same impact.

[yoavweiss]

Overall, this seems to me like something we should try to deprecate and remove, if we can.

[domenic]

I think deprecation and removal here is not likely to break pages, but is likely to cause many, many analytics providers or bespoke shutdown routines on sites to work incorrectly, and thus make page operators sad. It'd be cool if you want to try, though.

[yoavweiss]

Did some archeology and it seems like this was added to WebKit back in 2009 for IE compat. This was before sendBeacon and fetch() keepalive were used to provide the same functionality. (Relevant discussion)

Agree that any removal attempt will need to collect data on current usage and evaluate the level of sadness that will be caused by it. If we conclude that removal is not feasible, we probably need to specify that behavior and add tests for it.

[emmettbutler]

@yoavweiss please correct me if I'm wrong, but it sounds like setting img.src in a beforeunload handler is a valid way to track analytics events on page unload, though perhaps not the modern preferred method. See this SO question for more specificity in what I'm asking.

Within a beforeunload handler, are img.src and sendBeacon functionally equivalent?

[igrigorik]

Do we have WPT tests for this (img) behavior? I wouldn't be surprised to see this failing in a various browsers, and generally agree with Yoav that this is not something we should encourage and ideally deprecate.

[zcorpan]

I don't think there are wpt for this. There's live dom viewer demos in a comment above.

[zcorpan]

@ericlaw1979 said in https://twitter.com/ericlaw/status/1480594796267937795 that CSP is affected by at-unload image requests as well (in Chromium, at least?).

Did you know: <img> requests as the page unloads are converted to a beacon-like mode and are thus controlled by the |connect-src| CSP instead?

[yoavweiss]

Yup, relevant Chromium code

I'm less confident about this, but it seems like WebKit's code is loading the image similarly to other PING-type requests, so it's likely to impose the same CSP restrictions.