Bug 282506 – The page is resumed from the point at which fetch is aborted

• Status: NEW
• Component: Page Loading

[mizdra]

Created attachment 473117 [details]
Recording of bug reproduction

## Overview
The page is resumed from the point at which fetch was aborted when a page that transited during fetch is restored from bfcache.

## Steps to reproduce
1. `git clone https://github.com/mizdra/bfcache-and-page-transitions-during-fetching-test`
2. `npx serve .`
3. Open http://localhost:3000/1-basic on Safari
4. Click "Fetch resource and transit to another page" button
5. Click browser back button

## Actual Results
fetch is aborted and it throws a TypeError when the page is transited. http://localhost:3000/1-basic is restored from bfcache. The page is resumed from the point at which the TypeError was thrown.

## Expected Results
I think there are two expected behaviors.

The first is to abort fetch on page transitions and not save the page as a bfcache. This avoids restoring the page from the point where the TypeError was thrown.

Second, do not abort fetch on page transitions, but save the page as a bfcache, so that fetch continues in the background. This avoids restoring the page from the point at which the TypeError was thrown. Moreover, the page is restored from the bfcache. This is the approach used by Chrome.

## Build Date & Hardware
Release 206 (Safari 18.0, WebKit 20621.1.3.21.1) on macOS 15.1

## Additional Information
Many users do not expect the page to resume from the point at which fetch was aborted. Therefore, this behavior can break many pages. For more information, see the following.

- https://github.com/mizdra/bfcache-and-page-transitions-during-fetching-test?tab=readme-ov-file#additional-information

This issue has also been reported for Firefox.

- https://bugzilla.mozilla.org/show_bug.cgi?id=1928385

[Alexey Proskuryakov]

I think that only the first option is workable, as continuing a load in a disconnected frame can cause all kinds of issues, up to security ones.

[Anne van Kesteren]

This is why you'd use the Beacon API or Fetch keepalive (or "soon" fetchLater()).

Is there a reason you did not file this against Chrome?

[mizdra]

That is because I do not want to defer the fetching the resource. The example I provided in my first comment is a simplified version. A more realistic example would be...

1. A user visits an article page.
  - That article page has a comments section and a "read more" button to fetch additional comments
  - Also, the header of the page has a link to an external site
2. the user clicks on the "read more" button
  - Additional comments will be fetched
3. The user clicks on the link to the external site before fetching comments is complete

In this situation, the problem occurs. Fetching additional comments should begin immediately. Therefore, it is not appropriate to use the Beacon API or fetchLater.

Chrome does not resume the page from the point at which the error was thrown, even if the user returns to the page with a browser back. Also, I could not figure out if this behavior is against the spec or not. Therefore, I did not report it to Chrome.

If the behavior of browsers should be consistent, I think it would be better to report it. However, I don't know if there is a reason to do so. On the other hand, even if there is no clear reason, I think it would be a good idea to report it to the Chrome team so that they can think about this problem. What do you think?

[Radar WebKit Bug Importer]

<rdar://problem/139588201>