Closed Bug 1747813 Opened 11 months ago Closed 7 months ago

browserAction popup HTML parser mistakenly blocked when navigated to another extension page with Fission enabled

Categories

(WebExtensions :: General, defect, P1)

Firefox 95
defect

Tracking

(firefox-esr91 disabled, firefox99 wontfix, firefox100 wontfix, firefox101 fixed)

RESOLVED FIXED
101 Branch
Tracking Status
firefox-esr91 --- disabled
firefox99 --- wontfix
firefox100 --- wontfix
firefox101 --- fixed

People

(Reporter: ziga.zajc007, Assigned: rpl)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [addons-jira])

Attachments

(2 files)

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

Component: Untriaged → General
Product: Firefox → WebExtensions

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

Flags: needinfo?(ziga.zajc007)

(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.

Flags: needinfo?(ziga.zajc007)

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).

Flags: needinfo?(ziga.zajc007)
Attached file FireFox-Bug
(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #4)
> (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).

Here is the log file from Mozregression:
Flags: needinfo?(ziga.zajc007)

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":

Assignee: nobody → lgreco
Severity: -- → S2
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P1
Whiteboard: [addons-jira]

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).

Regressed by: 1732358, 1646817
Summary: browser extension froze → browserAction popup HTML parser mistakenly blocked when navigated to another extension page with Fission enabled

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:

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.

Blocks: 1758922
Pushed by luca.greco@alcacoop.it:
https://hg.mozilla.org/integration/autoland/rev/8fdf061ae321
ExtensionPopups ViewPopup class should not block the parser when a browserAction popup navigated between extension pages. r=zombie
Status: ASSIGNED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → 101 Branch
You need to log in before you can comment on or make changes to this bug.