Open Bug 1733390 Opened 3 years ago Updated 2 months ago

Previous session cannot be restored after Firefox crashes twice

Categories

(Firefox :: Session Restore, defect, P2)

Desktop
All
defect

Tracking

()

Tracking Status
firefox-esr78 --- wontfix
firefox-esr91 --- wontfix
firefox-esr102 --- wontfix
firefox92 --- wontfix
firefox93 --- wontfix
firefox94 --- wontfix
firefox95 --- wontfix
firefox104 --- wontfix
firefox105 --- wontfix
firefox106 --- fix-optional

People

(Reporter: gmoldovan, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Affected versions:

  • 78.15.0 ESR
  • 91.2.0 ESR
  • 93.0 (20210927210923)
  • 93.0b9 (20210923190449)
  • 94.0a1 (20210929155324)

Affected platforms:

  • Windows 10 x64
  • Ubuntu 20.04
  • macOS 10.14
  • macOS 11

Steps to reproduce:

  1. Launch Firefox with a clean profile.
  2. Open at least 15 different tabs containing different websites.
  3. Crash Firefox (type about:crashparent inside address bar).
  4. Crash Firefox again.

Expected result:
The Restore session button appears after the second crash.

Actual result:
The Restore session button does not appear after the second crash.

Regression range:
I will search for an old regression range if there is one. It doesn’t seem to be a recent regression since it is also reproducible on Firefox 92.0.1.

Additional notes
It needs 5-6 crashes in order for the Restore session button to appear, sometimes even more.

Has Regression Range: --- → no
Has STR: --- → yes
QA Whiteboard: [qa-regression-triage]

Looked for a regression manually way back to 62.0a1. This seems to have been introduced somewhere between 2018-05-18 and 2018-05-19, when about:crashparent was implemented.

I've ended up with the following regression range:

pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2018-05-18&enddate=2018-05-19
Potentially regressed by: Bug 1434252

On 2018-05-18 when about:crashparent was not yet implemented, I've crashed Firefox using the following steps and the issue did not reproduce:

  1. Go to about:config -> devtools.chrome.enabled (set it to true).

  2. Open Scratchpad with Shift + F4.

  3. Switch the Environment from Content to Browser.

  4. Execute the following Snippet in Browser Console (Ctrl+Shift+J) => Cu.import("resource://gre/modules/ctypes.jsm");let zero = new ctypes.intptr_t(8);let badptr = ctypes.cast(zero, ctypes.PointerType(ctypes.int32_t));badptr.contents;

On 2018-05-19, we reproduced the issue using about:crashparent, as weel as using the above snippet.

We have a test case that fails because of this bug. However we cannot link a bug marked as 'wontfix' to a test case. Is there a plan to prioritize this bug or should we remove the test case from the test suite?

Flags: needinfo?(dao+bmo)

:Giorgia do you mean Wontfix as in the status of the ticket or the status of the tracking release flag? Im asking because in this case the ticket is open with a status of NEW but is set to "wont fix" for fx95 release.

Flags: needinfo?(giorgia.moldovan)

Just wanted to know if there are any plans to fix this issue in the near future, because the issue is still reproducible on Firefox 104.0b1.

Flags: needinfo?(giorgia.moldovan)

(In reply to Giorgia Nichita, Release Desktop QA from comment #1)

Looked for a regression manually way back to 62.0a1. This seems to have been introduced somewhere between 2018-05-18 and 2018-05-19, when about:crashparent was implemented.

I've ended up with the following regression range:

pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2018-05-18&enddate=2018-05-19
Potentially regressed by: Bug 1434252

That patch basically added some try/catch to make code less fragile, so I'm doubtful that that's the cause. :(

Severity: S3 → S2
Flags: needinfo?(dao+bmo)
Priority: -- → P2

(In reply to Giorgia Nichita, Release Desktop QA from comment #1)

  1. Execute the following Snippet in Browser Console (Ctrl+Shift+J) => Cu.import("resource://gre/modules/ctypes.jsm");let zero = new ctypes.intptr_t(8);let badptr = ctypes.cast(zero, ctypes.PointerType(ctypes.int32_t));badptr.contents;

If I use this crash instead of about:crashparent, I get the "recover session" page immediately, even on current nightly. So it's not clear to me this is a "real" regression - I think it's just a consequence of how we treat about:crashparent crashes. Though tbf, I don't know why that would make a difference. Gabriele, as our resident crash reporter expert, can you help shed light on that?

So it seems the issue here is that we just restore the session rather than "Sorry. We’re having trouble getting your pages back." Either way I don't think that's S2.

Severity: S2 → S3

(In reply to :Gijs (he/him) from comment #6)

(In reply to Giorgia Nichita, Release Desktop QA from comment #1)

  1. Execute the following Snippet in Browser Console (Ctrl+Shift+J) => Cu.import("resource://gre/modules/ctypes.jsm");let zero = new ctypes.intptr_t(8);let badptr = ctypes.cast(zero, ctypes.PointerType(ctypes.int32_t));badptr.contents;

If I use this crash instead of about:crashparent, I get the "recover session" page immediately, even on current nightly. So it's not clear to me this is a "real" regression - I think it's just a consequence of how we treat about:crashparent crashes. Though tbf, I don't know why that would make a difference. Gabriele, as our resident crash reporter expert, can you help shed light on that?

So it seems the issue here is that we just restore the session rather than "Sorry. We’re having trouble getting your pages back." Either way I don't think that's S2.

It helps if I actually needinfo someone.

Flags: needinfo?(gsvelto)

IIUC this is not a crash reporting bug, but rather a session restore one. The session restore code has its own logic to detect if the previous session ended in a crash and will show the session restore window only if its logic says so, see here and the related code: https://searchfox.org/mozilla-central/rev/5644fae86d5122519a0e34ee03117c88c6ed9b47/browser/components/sessionstore/SessionStartup.jsm#405-406

Note that this works even if crash reporting is disabled, that's why this logic is separate from crash reporting. Either way I don't think this belongs in this component.

Flags: needinfo?(gsvelto)
See Also: → 1873249
You need to log in before you can comment on or make changes to this bug.