1830516 - [Linux] Tabs crash if accessed with middle click after deb Firefox is updated via terminal

Status: RESOLVED WORKSFORME

(Firefox :: Tabbed Browser, defect)

Description

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Found in

• Firefox 114.0a1

Affected versions

• Firefox 114.0a1

Tested platforms

• Affected platforms: Linux (all distros)

Steps to reproduce

1. Launch an older Firefox .deb build
2. Update the build via the linux terminal
3. After the update is done in the terminal, open any website in Firefox by middle clicking them

Expected result

• A page which requests the user to restart firefox in order to be able to use it is shown

Actual result

• The tab crash is shown

Additional notes

• The issue can be seen in the following attachment
• By accessing the links with left click in the same tab, the expected result is shown. This happens only when middle clicking them.

Comment 1

[Darkspirit]

Reproduced on KDE Wayland, Debian Testing.
Older builds:
2021-01-01 opened a crashed tab on middle click.
2018-01-01 did not open a new tab on middle click.

1. cd Downloads; mkdir mozreg; cd mozreg;
2. TMPDIR=~/Downloads/mozreg mozregression --persist ~/Downloads/mozreg --launch 2023-04-28
3. TMPDIR=~/Downloads/mozreg mozregression --persist ~/Downloads/mozreg --launch 2023-04-27
4. removed tmpycmg8dan, extracted 2023-04-28 nightly, renamed its folder to tmpycmg8dan
5. Went to about:newtab and opened websites by middle click: tabs crashed
6. TMPDIR=~/Downloads/mozreg MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --persist ~/Downloads/mozreg --launch 2021-01-01
7. removed tmpxz1z9887 folder, extracted 2023-04-28 nightly, renamed its folder to tmpxz1z9887
8. Went to about:newtab and opened websites by middle click: tab crash
9. TMPDIR=~/Downloads/mozreg MOZ_DISABLE_CONTENT_SANDBOX=1 mozregression --persist ~/Downloads/mozreg --launch 2018-01-01
10. removed tmpd2fwsouz folder, extracted 2023-04-28 nightly, renamed its folder to tmpd2fwsouz
11. middle clicked: no tab opened

Comment 3

[Nika Layzell [:nika] (ni? for response)]

Looking into this a bit more, I think this is actually an issue with how the frontend handles about:restartrequired errors for non-selected tabs. When a tab is not the active tab, we end up calling through onBackgroundBrowserCrash(browser, true) rather than onSelectedBrowserCrash(browser, true). While this does add the browser to restartRequiredBrowsers, it does not go through the normal browser crashed flow, and instead invokes SessionStore to try to recover from the background tab having crashed when it is next selected.

When the tab is then re-selected, we call into willShowCrashedTab, which decides whether to show the tab crashed page or attempt to recover by restoring the tab. In this case, we enter the first branch, and end up unconditionally showing the tab crashed page, even though the tab crashed due to a restartRequired condition: https://searchfox.org/mozilla-central/rev/5c922d8b93b43c18bf65539bfc72a30f84989003/browser/modules/ContentCrashHandlers.jsm#496-497,506.

We probably shouldn't be entering the sessionRestore case at all if the crash was a restartRequired crash, as this is not a recoverable situation, and we should never be choosing to attempt to restore the tab (we'd just crash again when trying to start a child process). If we swap out the code to always treat the crash like a selected browser crash, we won't run into this issue, and will eagerly load the restartrequired page, rather than doing it lazily.

This could also be changed by making the logic in willShowCrashedTab check for restartRequired earlier, but I think we'd want to unconditionally show the error page in that case, so I don't see the benefit of taking that approach.

Comment 4

[Nika Layzell [:nika] (ni? for response)]

You can somewhat simulate this sort of crash in a local build for testing by doing the following:

In one terminal, build and run firefox (make sure it's not an artifact build), but with preallocated processes disabled to avoid needing to exhaust them first:

$ ./mach build
$ ./mach run --setpref=dom.ipc.processPrelaunch.fission.number=0

Then, after firefox has started, in another tab, re-build firefox with a new forced-different buildid - this will clobber the build in the objdir with a new one with a different buildid.

$ MOZ_BUILD_DATE=20230101000000 ./mach build

After this build finishes, new attempts to start child processes should fail in the running instance in a similar manner to how they would after a .deb update.

Comment 5

[Catalin Sasca, Desktop Test Engineering [:csasca]]

This is still happening on 118.0a1. Alex left a comment in Bug 1836348 with the details.

Comment 6

[Catalin Sasca, Desktop Test Engineering [:csasca]]

We verified that the tab crashes are no longer reproducible after updating Firefox via terminal while it is running. Tests were performed on Ubuntu 22.10, Ubuntu 22.04, Lubuntu 20.03 LXQt, Kubuntu 22.04 KDE, Debian 11 Gnome and Linux Mint 21 Mate. Updates were made from 119.0a1 (2023-09-10) to the latest 119.0a1 (2023-09-14). This issue was fixed alongside Bug 1850026.