User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36

Steps to reproduce:

Go to https://webglfundamentals.org/webgl/lessons/webgl-3d-orthographic.html
and wait for a few seconds. Then click the back button

Actual results:

you have to click back 7 times before the page goes back

Expected results:

It should have gone back immediately

Works in Safari and Chrome. The page is not calling any history API functions

Oh, well, so the page is launching 7 iframes. Each iframe has an instance of monaco (the VSCode editor) running. That code might use the history API but given they are all in iframes, they shouldn't be able to affect the back button for the main page.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Navigation' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

steps

1. unzip
2. serve (I'd use npx servez)
3. open top.html
4. click and hold the back button, notice there are 7 entries instead of 1

Ok, narrowed it down. If the iframe does a fetch then that fetch ends up in the history for the page!

attached repo above

So interestingly, it seems to be some interaction between there being both a fetch, and a iframe's src being set in middle.html

I tried several things

1. I tried using XHR instead of fetch. Same issue
2. I tried posting a message to top.html, having it do the fetch and sending a message back. Same issue
3. I tried having the parent only do fetch + set iframe.src. No issue
4. I tried using response.arrayBuffer() instead of response.text() Same issue
5. I tried fetching a binary file (so the Content-Type: header received is not text/html). Same issue

So, if it's not clear. the repo is

In an iframe. 1. Do a fetch (you can discard the results), 2 set an iframe.src to something (local page, blob, ...)

FWIW, the page in comment #0 doesn't reproduce the bug for me (anymore?), however following the instructions, this glitch project does (Firefox Nightly 114.0a1 (2023-04-16) (64-bit) on macOS).
I ran a bisect and this doesn't seem to be a regression, I went back as far as M87 and it was already reproducible.

To be clear, the mere presence of the call to fetch() triggers the issue. Here is a link to the same glitch but avoiding this call to fetch(). This one doesn't add the many entries to the history.

It's not clear which is the expected behavior though, but certainly this call shouldn't be a condition for the history entries.

Might be worth to note that even blocking the actual network request through the use of a ServiceWorker, the bug still reproduces, so the trigger is probably early on the fetch() road.

Yea, sorry. the link doesn't repo (found a workaround). The attached file at the top should repo

The workaround was to reach into the iframe and call location replace vs settings iframe.src

 iframe.src = url;  // triggers the bug
 iframe.contentWindow.location.replace(url);   // does not trigger the bug

It does still seem like a bug.

This isn't really due to fetch, replacing the wait for the fetch with waiting for a Promise for a setTimeout shows the same behaviour.