1481931 - Attempting to reload a tab to circumvent "Restart Required" loses current page

Status: NEW

(Firefox :: Session Restore, defect, P5)

Description

[Stephan Sokolow]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180726161819

Steps to reproduce:

1. Install the Auto Tab Discard extension
2. Middle-click a bunch of YouTube sidebar recommendations so I don't lose them
3. Do something in other tabs to allow the tabs to be discarded
4. Click through the suspended tabs in rapid succession to allow them to be loaded back into memory in parallel.
5. Feel my heart leap in my chest at the exclamation favicons that are turning up, sure that I'm experiencing the recurring connectivity outage that I thought I finally fixed with a DSL modem firmware update.
6. See the attempt to force a reboot on me and get mad because It's My D*mn Computer! (Especially when Firefox's form recovery is flaky at best, some of the sites I visit don't recover from reloads properly, and I'd JUST gotten off the phone with eBay about a bug where their forced re-login would discard the contents of an attempt to submit a review.)
7. Try reloading the page to attempt to circumvent the attempt to force me to reload


Actual results:

I was left with an about:blank tab with the Back and Forward buttons both greyed out.

I cursed, dove into my browser history to try to identify which entries corresponded to tabs I hadn't closed yet, and made a note to either learn how to turn off the attempt to force me to restart or turn off browser update checking entirely and write my own update checker, as I did when Ubuntu's update manager removed the option to disable daily "Restart to update your kernel" nags.


Expected results:

Firefox should not have assumed that what I was in the middle of could be safely interrupted and resumed. (eg. Un-resumable downloads, SPAs which don't persist all of their JavaScript state properly, sites which found ways to accidentally break Firefox's support for persisting un-submitted form contents, such as Reddit's reply field, etc.)

Beyond that, attempting to circumvent Firefox's attempt to force a browser restart should not have resulted in data loss. (My biggest reason for leaving Chrome back in the early days of it being available on Linux was that it had the potential to crash when I clicked the button to recover a crashed session.)

Comment 1

[Stephan Sokolow]

Wow. They're not in my browser history either.

Thank God that I had Session Boss storing a rolling window of about a dozen incremental backups because the restart nag is actually doing something analogous to applying history.replaceState with a URL that's excluded from the history.

Given that I still worry about an accidental (or bug-triggered) extension install nuking the storage that WebExtensions are constrained to, I guess I really do I have to finish that "Persist open tabs in an app external to Firefox using native messaging" extension before Firefox 52 drops off the ESR channel.

Comment 2

[Stephan Sokolow]

...and, now, when I'm pretty sure I didn't click any kind of "OK, Restart" button, it restarted without permission, killing the non-resumable downloads in progress.

Comment 3

[Hani Yacoub, Desktop QA]

I couldn't reproduce this issue on Firefox Nightly 63.0a1 and on Firefox 62.0b16 on Ubuntu 17.04 x64, Windows 10 x64 and on Mac OS X 10.12.
I'll set this bug to "Tabbed Browser" component.

Comment 4

[Alex Thayer [:alexical] (she/her)]

Stephan, are you running two different instances of Firefox on different profiles at the same time? I'm wondering if this is ultimately just a manifestation of bug 1112937, which unfortunately is wontfix'd. In either case, I don't think this belongs in Tabbed Browser. I am going to punt it to Application Update - hopefully that's closer to where it belongs.

Comment 5

[Stephan Sokolow]

At the time, I was... but not in the way you're probably thinking.

When I reported the bug, I was running ESR 52 on one monitor and Developer Edition on the other.

I had encountered various update-related bugs when two Developer Edition processes got started (eg. Ctrl+Shift+Alt+I), but nothing stemming from my habitual running of two completely different versions of Firefox in completely different profiles.

I've since reached a point where I've modified my about:config and my behaviour enough that I wouldn't know if any such bugs are still present because I've worked around all of them. (eg. I work around bug 1112937 by always using a version other than Developer Edition for clean-profile testing... usually Nightly.)

Comment 6

[Molly Howell (she/her) (no longer active)]

(In reply to Stephan Sokolow from comment #5)
> At the time, I was... but not in the way you're probably thinking.
> 
> When I reported the bug, I was running ESR 52 on one monitor and Developer
> Edition on the other.

Thanks for clarifying; since you were running two different copies, this doesn't seem related to bug 1112937, your workarounds for that situation should be effective.

I have another question; I'm a little unclear on the steps to reproduce, so I wonder if you can help me out with understanding them. At step 7, you were being shown a prompt asking you to restart the browser to apply an update? But you didn't want to do that yet and instead you reloaded one of the error pages, and that got you an about:blank tab with no history? Is that right? If not, can you clarify what I might have misunderstood?

One more question as well, and the answer to this is probably yes, but just to be sure: are you certain that the dev edition instance and the ESR instance were in fact running different profiles?

I'm also quite worried about what you said in comment 2; we do not have any code that is supposed to automatically restart the browser to apply an update without the user accepting a prompt, and certainly not without showing the dialog for downloads in progress. I wonder if maybe that was a crash?

Comment 7

[Stephan Sokolow]

(In reply to Matt Howell [:mhowell] from comment #6)
> I have another question; I'm a little unclear on the steps to reproduce, so
> I wonder if you can help me out with understanding them. At step 7, you were
> being shown a prompt asking you to restart the browser to apply an update?
> But you didn't want to do that yet and instead you reloaded one of the error
> pages, and that got you an about:blank tab with no history? Is that right?

That's correct.

My best guess is that, in displaying the restart page, the 
browser did something analogous to history.replaceState with the intent that
some other mechanism would restore the URL after a restart.

> One more question as well, and the answer to this is probably yes, but just
> to be sure: are you certain that the dev edition instance and the ESR
> instance were in fact running different profiles?

Yes. The ESR instance was running ~/.mozilla/firefox/3id6bfo5.default which I
created when the upgrade from Firefox 3 to Firefox 4 caused massive breakages.
(Prior to that, I think I'd been running the same profile since I switched from
Mozilla Suite to Firefox.)

The Dev Edition instance was running ~/.mozilla/firefox/hy198cz7.quantum
which I created so I could incrementally migrate my settings over and build
a new extension loadout. In the process, taking the opportunity to leave
behind any cruft that had built up in the profile over the years.

They ran very divergent extension loadouts due to the limits of the 
WebExtensions API and I wouldn't get them confused. (eg. 
ESR ran downThemAll and Classic Theme Restorer with a menu button in the
top-left corner, while Dev Edition has a Download Star toolbar button near
the hamburger and no Add-ons toolbar along the bottom.)

> 
> I'm also quite worried about what you said in comment 2; we do not have any
> code that is supposed to automatically restart the browser to apply an
> update without the user accepting a prompt, and certainly not without
> showing the dialog for downloads in progress. I wonder if maybe that was a
> crash?

It's entirely possible. Firefox crash reporting has never worked very well on
my system.

When using Ubuntu PPA builds, Ubuntu's "apport" crash reporter would peg the 
CPU for minutes after a Firefox crash (probably because of the multiple gigabytes
it'd take with my chosen tab and extension loadout), which led me to just killing
it. On the other hand, something in my extension loadout or user.js would cause
Firefox's built-in crash reporting dialog to always fail (without elaborating on
what actually went wrong) when trying to submit the report.

I've taken to letting the crash reports just build up until I open up a fresh
profile in Nightly to test a bug, at which point it offers to submit
all of the backlogged crash reports, and that succeeds.

It may just have been "Firefox crashed and the crash catcher failed to pop up."

Comment 8

[Molly Howell (she/her) (no longer active)]

Okay, I see. Thanks again for the info.

This is a bit complicated, but I don't see anything that makes me think there's an updater bug here, it sounds like some kind of issue with history and/or session management as relates to discarding tabs, so the update component isn't the right place for this bug either.

Comment 9

[Justin Dolske [:Dolske]]

This bug is wandering all over the map and is not very actionable.

As I understand this report, the core issue from comment 0 is that you had a bunch of YouTube tabs open, you restarted Firefox, and then those tabs are blank.

That would point to some bug in session restore. The most helpful step at this point would be a minimal series of steps to reproduce the issue.

Comment 10

[Stephan Sokolow]

I can certainly try. Is there a way to get Firefox Nightly believing it needs to display the "Restart Required" message without having to wait 24 hours between testing out each candidate for a set of steps to reproduce?

Comment 11

[Stephan Sokolow]

I still don't know how I'd go about meaningfully testing this if I don't know how to induce Firefox Nightly into a "Restart Required" state more often than once per day.

However, a potential factor in this just occurred to me. I use the Auto Tab Discard extension and I've noticed that, on rare occasions (which I don't know how to reproduce on command), Firefox will screw up when reloading a discarded tab and, instead, present a blank tab as if it's what I asked for.

I've encountered two symptoms which, if combined with "Restart Required", could lead to the observed behaviour:

1. Sometimes, reloading a discarded tab results in a blank page

2. Sometimes, that blank page is accompanied by a blank address bar, despite the tab title still being as expected.

If those two symptoms were to happen on a tab where I couldn't right-click the Back button and click the "current" page in the history menu, I'd lose the tab in the same way that I experienced with Reload here.

Comment 12

[Dale Harvey (:daleharvey)]

You can use 

$ Services.startup.quit(Ci.nsIAppStartup.eRestart | Ci.nsIAppStartup.eAttemptQuit);

run in the browser toolbox to perform the same restart (https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox to enable browser toolbox)

Comment 13

[Mike de Boer [:mikedeboer]]

(In reply to Stephan Sokolow from comment #11)

I've encountered two symptoms which, if combined with "Restart Required",
could lead to the observed behaviour:

1. Sometimes, reloading a discarded tab results in a blank page

2. Sometimes, that blank page is accompanied by a blank address bar, despite
   the tab title still being as expected.

These sound & look like potential bugs in the Tabbed Browser component, lazy tabs specifically. You might want to consider filing a bug there!