1910115 - "open in a new tab" while a restart after an update is required leads to `about:tabcrashed` pages, which are restored as `about:blank`

Status: NEW

(Firefox :: Session Restore, defect, P3)

Description

[Max Christian Pohle [:/dev/max]]

Attachment: "Gah. Your tab just crashed" instead of Restart required message

Hi!

The about:restartrequired page can be triggered like that:

• download an update, but do not close Firefox
• start Firefox a second time with firefox --ProfileManager
• and let this second instance run with a different profile
• After starting this second session click on a link in the first instance of Firefox

and you get to see the message (from the page above): Restart to Keep Using Firefox.

Here comes the problem: When you right click on the link and open it in a new window (or use the middle mouse button to do the same) you get to see an about:tabcrashed instead (note that I better had used the right click menu for better visibility in the attached video).

After that if you restart Firefox, it will not restore the crashed tab with the Url on which you clicked, but an about:blank page with no title and sometimes and (i) icon, sometimes not.

Comment 1

[Max Christian Pohle [:/dev/max]]

Attachment: after the restart: `about:blank` pages are shown

Comment 2

[Sarah Clements [:sclements]]

Mossop, does this ring a bell with any of the multiple profile work you've done? What should be the expectation in this scenario (probably not the crash screen but it seems like its intersecting with a few different areas of code).

Comment 3

[Dave Townsend [:mossop]]

I suspect it's not particularly relevant to multiple profile usage (other than that causing the update being applied in the background).

Max can you get the crash report from about:crashes so we can see the stack?

Comment 4

[Max Christian Pohle [:/dev/max]]

Hi! I do not see a crash report directly related to the crash, neither under about:crashes, nor in one of the crash report folders. The last crash I had was caused 10 minutes earlier and caused by me running out of working memory. So I took measures to free up RAM and deactivated all my plugins (to make sure neither of these causes the issue) before I triggered the bug again.

After the 'restart required' page appeared (again after I re-triggered after yesterdays update) I opened about:support and middle-clicked the "support website" link in the top to reproduce the tab crash, which instead correctly got me onto the restart required page. But double-clicking the link caused a tab to crash and seems to lead into some race condition. Clicking 5 times like that shows the tab crash for most tabs.

The only log messages I see which could be related, but which are not always triggered by the crashing tabs and also not imminently appear after switching to a tab are these:

TypeError: requestedBrowser.currentURI is nullAsyncTabSwitcher.sys.mjs:380:26
    updateDisplay resource:///modules/AsyncTabSwitcher.sys.mjs:380
    postActions resource:///modules/AsyncTabSwitcher.sys.mjs:674
    handleEvent resource:///modules/AsyncTabSwitcher.sys.mjs:1144
    (Async: EventListener.handleEvent)
    AsyncTabSwitcher resource:///modules/AsyncTabSwitcher.sys.mjs:163
    _getSwitcher chrome://browser/content/tabbrowser/tabbrowser.js:5735
    updateCurrentBrowser chrome://browser/content/tabbrowser/tabbrowser.js:1221
    _setupEventListeners chrome://browser/content/tabbrowser/tabbrowser.js:6186
    set selectedIndex chrome://global/content/elements/tabbox.js:236
    set selectedPanel chrome://global/content/elements/tabbox.js:246
    set selectedIndex chrome://global/content/elements/tabbox.js:599
    set selectedItem chrome://global/content/elements/tabbox.js:617
    _selectNewTab chrome://global/content/elements/tabbox.js:784
    _selectNewTab chrome://browser/content/tabbrowser/tabs.js:1142
    advanceSelectedTab chrome://global/content/elements/tabbox.js:831
    handleEvent chrome://global/content/elements/tabbox.js:137

and a few seconds later:

 Given tab is not restoring. SessionStore.sys.mjs:6655:15
    _resetLocalTabRestoringState resource:///modules/sessionstore/SessionStore.sys.mjs:6655
    _restoreTabContentComplete resource:///modules/sessionstore/SessionStore.sys.mjs:7115
    _restoreTabContent resource:///modules/sessionstore/SessionStore.sys.mjs:6993

Is there anything else I could attempt to get more information on what causes a crash when the program is already running (e.g. further log messages)?

Comment 5

[Dave Townsend [:mossop]]

This makes me wonder if the difference between a regular tab crash and a tab crash due to build id mismatch (they're both crashes) isn't correctly communicated to a newly opened tab so the tab crashes but we don't submit a crash report but the frontend just displays the regular tab crash page. What OS are you testing on, I can't reproduce this on macOS.

Comment 6

[Max Christian Pohle [:/dev/max]]

I am on the latest version of Windows 11, I can still reproduce the bug, but was still not able to get a crash report or new log message from it (even though I have adjusted some of the loglevels).

Is there anything else I could do to make the crashed tab tell me what caused the crash (e.g. get a backtrace)?

Comment 7

[Sam Foster [:sfoster] (he/him)]

This is possibly a duplicate of an existing bug. I think there's an issue here where when a tab doesnt complete loading for whatever reason (in this case the browser has updated in the background and we're failing to load remote content in the new tab and crashing) instead of capturing that URL and attempting to load it on the next startup, we're just opening a empty tab.

Comment 8

[Max Christian Pohle [:/dev/max]]

Update: I am using Firefox Beta and had Nightly installed simultaneously. Ever since I uninstalled Nightly, I have not seen this issue again.