1950028 - Previous URL lost in tabs history after using tabs.update to update URL.

Status: NEW

(WebExtensions :: General, defect, P2)

Description

[anon]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:137.0) Gecko/20100101 Firefox/137.0

Steps to reproduce:

1. Click 'Inspect' on an extension in about:debugging to open its Console.

2. Run the following code in the console to create a new tab and get its id:

   browser.tabs.create({active: true}).then(t => console.log("tab id: " + t.id));

3. Load 'https://www.apple.com' in the tab that was just created.

4. After the tab has finished loading, load 'https://addons.mozilla.org' in the same tab.

5. Run the following code in the console, replacing 'id' with the id showing in the console:

   browser.tabs.update(id, {url: "https://duckduckgo.com"});

6. Right click on the back button to view the tabs history.

Actual results:

In this case, 'Add-ons for Firefox' did not appear in the tabs history.

Expected results:

The URL that was previously loaded should appear in a tabs history after using tabs.update to update the URL (when 'loadReplace' is not used).

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 2

[Alex Cornestean]

Hello,

I reproduced the issue on the latest Nightly (138.0a1/20250304213504), Beta (137.0b1/20250303103151) and Release (136.0/20250227124745) under Windows 11 and Ubuntu 24.04 LTS.

The issue occurs as described in Comment 0, “Add-ons for Firefox” not appearing in the tabs history.

Comment 3

[Tomislav Jovanovic :zombie]

Thanks Alex, I think Firefox had an intervention recently to deal with pages spamming history, and this might be a side-effect from that.

Can you please do a bisection for a regression range?

Comment 4

[Rob Wu [:robwu]]

There was recently a bug report on the absence of history entries when history.pushState is used in an extension popup, at bug 1935935, which in turn is caused by bug 1924861. Does setting browser.navigation.requireUserInteraction to false in about:config solve the issue?

I do expect tabs.update to add history entries though, independently of the pref.

Comment 5

[Alex Cornestean]

@Rob in Comment 4:
Setting browser.navigation.requireUserInteraction to false in about:config does solve the issue. As per the STR, with the pref set to false, I get “Add-ons for Firefox” showing in the tabs history.

@Tomislav in Comment 3:
Regression range:
Bug 1734181 - Part 5: Re-enable back button intervention in Nightly. r=peterv,dom-core

Differential Revision: https://phabricator.services.mozilla.com/D216829

Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4d5a61f391ae9db3ac0945e2bac54f85b1827df3&tochange=06b7049f2082464eb0e6337bca1c85d7bcad6826

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1734181

:avandolder, since you are the author of the regressor, bug 1734181, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 7

[Adam Vandolder [:avandolder]]

This behaviour does appear to be the back-button intervention working as intended.

(In reply to Rob Wu [:robwu] from comment #4)

I do expect tabs.update to add history entries though, independently of the pref.

Currently, there is no special handling for tabs.update, so while it adds history entries, the back-button intervention makes it so those entries are only available if they have been interacted with. It may be possible to add such functionality if that's what is needed.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:willdurand, could you have a look please?

For more information, please visit BugBot documentation.

Comment 9

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Adam Vandolder [:avandolder] from comment #7)

This behaviour does appear to be the back-button intervention working as intended.

(In reply to Rob Wu [:robwu] from comment #4)

I do expect tabs.update to add history entries though, independently of the pref.

Currently, there is no special handling for tabs.update, so while it adds history entries, the back-button intervention makes it so those entries are only available if they have been interacted with. It may be possible to add such functionality if that's what is needed.

The tabs.update method does explicitly provide a loadReplace option and so extensions may be actually expect that history entries are being created unless they passed loadReplace explicitly set to true.

would it be possible to still support that by special handling tabs.update? any concern in considering to do that?

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1734181

Comment 11

[Rob Wu [:robwu]]

The pref is now enabled by default since Firefox 136 (bug 1939691).

Comment 12

[Dianna Smith [:diannaS]]

:avandolder any update

Comment 13

[anon]

It looks like tabs.update with loadReplace is also not working correctly at times with the back button intervention.

Steps to reproduce:

1. Open an extensions Console in about:debugging.
2. Run the following code in the Console: browser.tabs.create({url: "about:blank"}).then((tab) => console.log("tab id: " + tab.id))
3. Load 'https://www.bing.com/' in the tab.
4. Load 'https://duckduckgo.com/' in the tab.
5. Load 'https://www.google.com/' in the tab.
6. Click the back button to view the DuckDuckGo page.
7. Run the following code in the extensions Console, first replacing 'id' with the new tabs id: browser.tabs.update(id, {url: "https://search.brave.com/", loadReplace: true})
8. Press the forward button to view the Google page.
9. Press the back button once (sometimes the Brave page will be missing and the Bing page will appear).
10. Repeat steps 2-9 until the Brave page is lost in the tabs history.

If browser.navigation.requireUserInteraction is set to false, then the Brave page will never be lost. Note that window.location.replace used instead of tabs.update (with loadReplace set to true) will also have the same issue. This is somewhat different than this bug where window.location.assign, window.location.href, etc... are still working correctly and tabs.update (without loadReplace) is not. Should I create a separate bug for this?