2014527 - Back/forward entries disappear after replace navigation

Status: UNCONFIRMED

(Core :: DOM: Navigation, defect)

Description

[Alex]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:148.0) Gecko/20100101 Firefox/148.0

Steps to reproduce:

Currently I have the following bug on Firefox ESR. I also tested a regular one and it's present on the latest Firefox as well.
Reproduction steps:

1. In a new tab open example.com.
2. Then you transit to example.org using the address bar.
3. Go back (using the left arrow in the UI) to the example.com.
4. Focus on the address bar and press enter (this way you reload the current page).
5. Go forward (using the right arrow in the UI) again to example.org.
6. Right-click on the left or right arrow in the UI.
7. You observe that example.com transition disappeared from the tab history (the back-forward history).

Of course, it's not only reproducible on these websites, they are just for demonstration purposes.

It's even more reproducible with three entries, let's say [example.com, example.net, example.org]. If you're on the first or the second one and does the same Enter in the address bar, then after you transit to any other entry the "reloaded" entry disappears.

Some other things to note: it also happens using WebExtension's await browser.tabs.update({url: "<same or different url>", loadReplace: true /* can be omitted in case the same url is used */) or using e.g. window.location.replace("<different url>"). It doesn't happen when you just refresh the page using F5 or Ctrl+F5 or when you use window.location.replace with the same (current) url.

Actual results:

history items disappear

Expected results:

they must remain in tact

Comment 1

[Negritas Sergiu, Desktop QA]

Hello! I have tried to reproduce the issue with firefox 149.0a1(2026-02-02) on Ubuntu 22.04 , unfortunately I wasn't able to reproduce the issue.
Could you please answer the following questions in order to further investigate this issue

1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
2. Could you please provide a video with the issue?
3. Are you refering to the animation of the tab when loading the website?

Comment 2

[Alex]

Attachment: repro1.mp4

Comment 3

[Alex]

Attachment: repro2.mp4

Comment 4

[Alex]

(In reply to Negritas Sergiu, Desktop QA from comment #1)

1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles

Hi, yes, it happens on a fresh Firefox install. I was able to reproduce it on ESR 140, Release 147, and Nightly 149.0a1, both on Windows and Linux. I was also able to reproduce it on 147.0.2 for Android, though it is a bit different: entry does NOT disappear in the list which is displayed by long-press back button and you're able to navigate using this list, BUT in the menu the left and the right arrows are inactive.

2. Could you please provide a video with the issue?

I've recorded two videos for Firefox Nightly 149.0a1 on Windows 10. The first one reproduces a bug in a tab with two back-forward history entries and the second one in a tab with three entries.

3. Are you refering to the animation of the tab when loading the website?

I refer to the list of back-forward history entries of a tab.

Comment 5

[Alex]

Changing browser.navigation.requireUserInteraction to false prevents this issue from happening.

Comment 6

[Alex]

Similar bug which was fixed in the past: https://bugzilla.mozilla.org/show_bug.cgi?id=1644914.

Comment 7

[Alex]

https://bugzilla.mozilla.org/show_bug.cgi?id=1981019 is a subset of this general problem. It describes only the JS part of the bug that I also mentioned in the description but used window.location.replace instead of window.history.replaceState. I'd say this bug is more focused on the user-side whereas that bug is more focused on the JS-side, but what they have in common is: replace navigation (whether it is user-initiated or JS-initiated) should not mark the existing navigation entry as done without user interaction and then hide it.