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

Status: NEW

(WebExtensions :: General, defect)

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.