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

Steps to reproduce:

Everything is described on FireFox community forum: https://discourse.mozilla.org/t/new-firefox-broke-the-extension/90730

Actual results:

Everything is described on FireFox community forum: https://discourse.mozilla.org/t/new-firefox-broke-the-extension/90730

Expected results:

Everything is described on FireFox community forum: https://discourse.mozilla.org/t/new-firefox-broke-the-extension/90730

I followed the steps described in https://discourse.mozilla.org/t/new-firefox-broke-the-extension/90730 using FF95 on Ubuntu , but unfortunately I was not able to reproduce the issue.

Also I tried same scenarios on Windows 10x64 using FF96.0b9 , with same results. The extension was responsive all the time during testing session.

Please let me know if you have any special step which is not very clear from video and I can try to reproduce it again.

Thanks.
Victor

(In reply to vcarciu from comment #1)

I followed the steps described in https://discourse.mozilla.org/t/new-firefox-broke-the-extension/90730 using FF95 on Ubuntu , but unfortunately I was not able to reproduce the issue.

Also I tried same scenarios on Windows 10x64 using FF96.0b9 , with same results. The extension was responsive all the time during testing session.

Please let me know if you have any special step which is not very clear from video and I can try to reproduce it again.

Thanks.
Victor

Hello,

I really don't know how you can't reproduce this.
Everytime I install browser extension and click on Sign Up button (Change the page) it happens.

I'm now using Fedora 36 Beta and newly installed FireFox browser and I can still reproduce it.

Also everyone else that tries it gets the same problem.

I have just tested on newly installed Windows 10 in a VM and it also happens.

(In reply to ziga.zajc007 from comment #3)

I have just tested on newly installed Windows 10 in a VM and it also happens.

would you mind to try to bisect the regressing change (if any) using mozregression?
https://mozilla.github.io/mozregression/

Determining the regressing change would allow us to get a better picture of the underlying issue (and then try to determine what may be missing from the STR to be able to reproduce it consistently and investigate it in more detail).

https://i.imgur.com/1YFK5vx.png

Thanks a lot for running a bisect with mozregression.

The fact that mozregression pointed in the direction of the bug that enabled fission was a very helpful hint about where the underlying issue is:

• I have been able to trigger the issue and then confirm that using the same extension page (which navigates from index.html to register.html when the "Sign up" button is clicked):

  • in a sidebar, pageAction or tab the issue was not being triggered (the page was navigating to register.html and the new page was rendered as expected),
  • whereas in the browserAction popup the issue was being triggered consistently (besides the register.html not being rendered, the previous page was not receiving any DOM event anymore

• from the DevTools toolbox I inspected the browserAction popup that got stuck and I did notice that:

  • "window.location.href" was returning the register.html url as expected
  • but document.readyState was stuck on "loading"

The observed behaviors pointed clearly in the direction of the browserAction preloaded popup, because ExtensionPopups.jsm does explicitly block the parser to prevent the scripts included in the webpage from being executed (until we swap the invisible preloaded popup with a visible part of the popup window), and then to look into the changes we introduced in Bug 1646817.

With fission enabled (and the changes introduced from Bug 1646817), when the browserAction popup is navigated from "index.html" to "register.html":

• a new DidChangeBrowserRemoteness event is emitted and the ViewPopup class will be calling again initBrowser

• and so, if the this.blockParser is true (which is the case because a user would be hovering the mouse on the browserAction before clicking the button and we will be preloading the popup), we will be blocking the parser of the browserAction popup

• the popup parser will never get unblocked, because the call wasn't triggered by the preloaded browser element but the one that is already visible.

I've added as regressing changes both Bug 1732358 and Bug 1646817 because it seems that the issue has been technically introduced as part of the changes from Bug 1646817 but it wasn't reproducible without fission enabled (which is why mozregression bisect pointed to Bug 1732358).

I've just attached a patch with a proposed fix, plus a new test case to cover the issue explicitly as part of the automated tests.
Locally I explicitly verified that the new test gets consistently stuck and fails without the fix.

I pushed it to try to double-check if it may be intermittent while running on the build infrastructure:

• https://treeherder.mozilla.org/#/jobs?repo=try&revision=843c8dbc44e13c36e2b8e04ad0c3273a1b451a4b

As a side note for how an extension may be able to workaround the issue if necessary:

I haven't explicitly tried it locally but, given the actual underlying issue, an extension may be able to workaround the issue by keeping the top level browserAction popup page url unchanged and navigate a subframe instead.

Based on the observations and analysis, this sounds like a likely cause for bug 1758922. That other bug was closed because the scenario is unsupported, but I am still linking both bugs for visibility.

https://hg.mozilla.org/mozilla-central/rev/8fdf061ae321