1935935 - Unable to go backward after pushState in extension page

Status: RESOLVED WONTFIX

(WebExtensions :: General, defect)

Description

[eight04]

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

Steps to reproduce:

1. Download, unpack, and side-load the extension: https://github.com/eight04/webextension-test/archive/refs/heads/extension-no-history.zip
2. Click the browser action to open the extension page.

Actual results:

The address bar shows /test and the backward button is disabled.

Expected results:

The backward button should be enabled. Going backward should go back to /popup.html.

Broken with FF135 on PC and android.
Working fine with FF133.

Comment 1

[Francesco Lodolo [:flod]]

Could you try running mozregression, since it works on 133?
https://mozilla.github.io/mozregression/quickstart.html

Comment 2

[Tomislav Jovanovic :zombie]

Alex, can you please try to reproduce and find a mozregression range?

Comment 3

[Alex Cornestean]

Hello,

I reproduced the issue only on the latest Nightly (135.0a1/20241208214455). Beta 134 and Release 133 are unaffected.

Mozregression results:

2024-12-09T16:39:26.717000: DEBUG : Found commit message:
Bug 1924861 - Only show the first history entry if it has user interaction. r=dom-core,omc-reviewers,sessionstore-reviewers,dao,peterv,tabbrowser-reviewers,mviar,sfoster,webdriver-reviewers

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

2024-12-09T16:39:26.717000: DEBUG : Did not find a branch, checking all integration branches
2024-12-09T16:39:26.718000: INFO : The bisection is done.
2024-12-09T16:39:26.719000: INFO : Stopped

Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9a8cc59e9dab76401127b07ca3f22a8cc7334b94&tochange=9642ea5c42d0916fc944ae44023c218d1b6c0fac

Comment 4

[Rob Wu [:robwu]]

This only affects Nightly because the feature is behind the browser.navigation.requireUserInteraction flag, which is only true by default on Nightly (bug 1929534).

Comment 5

[BugBot [:suhaib / :marco]]

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

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

For more information, please visit BugBot documentation.

Comment 6

[Adam Vandolder [:avandolder]]

As far as I can tell, this is the back-button intervention, which is currently behind the browser.navigation.requireUserInteraction pref, working as expected - if a page that has not been interacted with performs a navigation (as this extension does via history.pushState), then that page won't show up in user's history menu and won't be accessible from the back button.

Comment 7

[eight04]

I want to catch the back button to close the popup in my extension. What is the workaround for this issue?
Ref: https://bugzilla.mozilla.org/show_bug.cgi?id=1807067

Also, if there is a workaround, wouldn't sites abuse the workaround? How would you fix that?

I read several threads and it has been mentioned this behavior won't be compatible with extensions and popups/SPA:

https://github.com/WICG/interventions/issues/21#issuecomment-448331224

Using 'back' to close popups (like dialog and menus) on Android devices.
Listening for popstate in PWAs to intercept an app-close event.

https://bugzilla.mozilla.org/show_bug.cgi?id=1515073#c18

I'm not certain we want to break extensions this way

https://github.com/whatwg/html/issues/7832#issuecomment-1284055232

breaks back-button behaviour in our apps when page requests take a while to complete

Can we exclude this change for extensions? Like consider navigation made by extensions can be trusted.

IMO this change should only apply to some blacklisted sites, and should be implemented in an ad blocker. It doesn't worth losing such critical functionality just because of some ads.

Also it might be better to improve the backward button on mobile instead of killing history API e.g. make backward button navigate to the second last interacted page when clicked twice.

It's funny that it is so annoying someone even suggested making a permission for it.

Comment 8

[Rob Wu [:robwu]]

We've discussed this during today's bug triage, and the majority opinion is that we should follow the conventions of the web platform where possible, unless there are compelling reasons to deviate from it.

(In reply to eight04 from comment #7)

I want to catch the back button to close the popup in my extension. What is the workaround for this issue?

Your demo extension opens a new tab. If you put default_popup and/or call the browserAction.setPopup(), you'll get a popup with the expected semantics (back = close).

E.g. if I install uBlock Origin, click on its action button to open its popup and press Back, then the popup closes as expected. Tested with Firefox for Android: 133 release, 134 beta, 135 Nightly.

Comment 9

[BugBot [:suhaib / :marco]]

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

For more information, please visit BugBot documentation.

Comment 10

[Rob Wu [:robwu]]

See comment 8.

Comment 11

[eight04]

I'm porting another extension to Android and hit this bug again.

When browser action is clicked, the extension will:

1. Collect images on the pages.
2. If no images, display a notification and return.
3. Otherwise, open an extension tab and display images in the extension tab.

Ideally, the users will expect that the backward button should close the extension page and switch to the original tab. With this bug, I can't catch the backward button.

The workaround using popup doesn't work either.

• browserAction.openPopup() requires user interaction so it can't be used at step 3.
• If I use a default popup, the popup will be opened no matter there is an image or not.

Seems it's a dead end.

---

Now I think the main issue is that Android doesn't support openerTabId:
https://bugzilla.mozilla.org/show_bug.cgi?id=1817806

On a normal webpage, if you open a link in a new tab, the backward button will close the tab, switch back to the original tab.

I suspect a tab created with openerTabId will have the same behavior.