Background updater requesting restart blocks user workflow
Categories
(Toolkit :: Application Update, defect)
Tracking
()
People
(Reporter: zao, Unassigned)
References
Details
Attachments
(1 file)
|
117.16 KB,
image/png
|
Details |
restart-nightly.png
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0
Steps to reproduce:
Minding my own business opening a link from somewhere.
Actual results:
Instead of the new page I intended to open, a sad lizard appeared with an unconditional message that I need to Restart Nightly.
Expected results:
I expected the page to load, or some way to defer the restart until a point where I don't have active work in the browser and can actually restart.
For context, I run Nightly as my everyday browser at home and at work, and as such have adopted an update flow where I let it restart every few days or so, or at the end of day when I don't have any drafts or other ephemeral state going on.
There's probably some technical reason why it can't progress at this point, having partially updated the browser or something.
This forced interruption is a bit of an unwelcome surprise in the usability department as it completely interrupts work focus and makes me have to figure out if it's actually safe to restart and have to scramble to commit any pending state.
As a side note, after restarting the new page does not automatically load, you have to resubmit from the address bar in an empty tab window to navigate to it.
|
||
Comment 1•5 years ago
|
||
There is just no other way to block opening tabs/windows if the Firefox files got updated in the background.
The developers would not have added this special "restart required" page if there would be an easier way to solve this without interrupting the user.
|
Reporter | |
Comment 2•5 years ago
|
||
From the perspective of someone used to the previous behaviour, it's not clear that the update has actually already taken place and that there's technical limitations to why an user can't progress. I had to ask my tame Mozillian to find out that there was a new background updater that pre-updated the browser silently.
This bug is primarily filed to lift an interesting use case that might have been overseen when designing this functionality.
At this point, I would like to explore what kind of control there might be to minimize the impact this has on day-to-day use of the browser, as restarts are quite disruptive.
I'd hate to have to go for a release Firefox, as day-to-day use is a great way to find issues early.
|
||
Comment 3•5 years ago
|
||
There isn't a new background updater. This happens when one instance of Firefox updates while another instance is running. When multi-process Firefox was implemented this would cause a crash of newly launched processes so the message for newly launched tabs was added. There isn't a path to fix this for Firefox at this time.
I'd hate to have to go for a release Firefox, as day-to-day use is a great way to find issues early.
This isn't unique to nightly. It also happens on stable as well.
|
||
Comment 5•5 years ago
|
||
I'm a bit confused how we can get into this state, as the user insists they weren't running with --new-instance or similar, it's a Nightly so the package manager can't be involved, and Firefox by default would block independent instances from launching. So who exactly updated? Not this instance I assume as it's showing the update icon in the hamburger menu.
There isn't a new background updater.
The combination of the above and the message in the screenshot that "Nightly has just been updated in the background" must be the cause of confusion.
Without understanding the steps to get wedged like this I don't think there's much we can do though.
|
|
||
Comment 6•5 years ago
|
||
I believe the fork server work would allow us to handle this case, so linking to that bug.
|
||
Comment 7•5 years ago
|
||
I've seen this happen frequently lately, never seen it happen before.
|
|
||
Comment 8•5 years ago
|
||
I'm guessing it's fallout from: https://groups.google.com/forum/#!topic/mozilla.dev.platform/Vz-L_of5WZE
See also https://bugzilla.mozilla.org/show_bug.cgi?id=716110#c44
|
|
||
Comment 9•5 years ago
|
||
It looks like due to the flag changes people are unintentionally starting multiple instances that end up updating each other and thus getting wedged.
Or something.
|
|
||
Comment 10•5 years ago
|
||
Dave, could this be fallout from the changes you made? We don't understand the exact sequence of events, but I've now found at least 3 people hit by this.
|
||
Comment 11•5 years ago
|
||
I believe that this is bug 1534508 (or the bug it blocks).
Description
•