1475873 - When restarting multiple times for updates, don't display (or improve) the "we just need to do one small thing to keep going" message

Status: NEW

(Toolkit :: Application Update, defect, P5)

Description

[Pomax]

Attachment: screenshot.508.png

I just ran into nightly wanting to restart, so I told it to through the usual [⋮] menu "restart" option. Upon restart, firefox immediately threw up a cryptic message:

"Sorry. We just need to do one small thing to keep going.
We have just installed an update in the background. Click Restart Nightly to finish applying it.
We will restart all your pages, windwos and tabs afterwards, so you can be on your way quickly."

This is a very strange message: I restarted nightly, it should have installed everything it needed prior to firing itself back up - I've never seen firefox needing a restart-after-restart, so this in this super rare instance as a nightly user, I would at the very least expect an explanation of why a second restart is required, and one that requires me to click a button instead of just happening since I clearly can't use nightly until I do (if I have no choice, why offer one?).

As such, this message really needs to be more information.

- give an explanation of what really happened ("a background update" should be say what was updated, not 'that something' was updated. Especially if you want bug reports from nightly users about this process going wrong)
- explain why an immediate restart is needed (why is firefox starting in not-headless mode and just running this second update automatically?)
- add an identifier that lets people file bugs when this happens and it doesn't clearly restart firefox (I observed the nightly process sitting at 0% cpu, 1.1MB memory allocated, 0% memory getting used, for a good minute before it finally properly restarted. Having information that I can copy first, then restart, then include in a bug if the restart misbehaves, feels like an important thing to have in nightly)

Comment 1

[Bram Pitoyo [:bram]]

(In reply to Pomax [:pomax] from comment #0)
> This is a very strange message: I restarted nightly, it should have
> installed everything it needed prior to firing itself back up - I've never
> seen firefox needing a restart-after-restart, so this in this super rare
> instance as a nightly user, I would at the very least expect an explanation
> of why a second restart is required, and one that requires me to click a
> button instead of just happening since I clearly can't use nightly until I
> do (if I have no choice, why offer one?).

Jared, can you remind me why this page needed to exist? I did remember working on the copy for this page, but forgot the reason why.

The right solution is to restart twice. And on the first restart, we shouldn’t show any window so that users doesn’t mistakenly think that Firefox is ready to run – even though it doesn’t.

Unless this is a page that shows up when the update process has been botched (so another re-update and re-restart is needed to correct it). And in that case, we should show an error message. Something along the lines of “Sorry. The update we tried to install failed. Can we try to install it again?”.

Comment 2

[Bram Pitoyo [:bram]]

I found this from Stephen Pohl’s document: https://docs.google.com/document/d/1dUhc1fS6vHTIJXMLcs6vTatKmrb2FXtyiMZbtriZGME/edit

----

A user can get into this problematic situation for the following reasons. There may be additional scenarios not described here:

1. A user is running multiple instances of Firefox with multiple profiles. When one of these instances is restarted, it may apply an update, causing the other instance(s) to run into this buildID mismatch.

2. If Firefox is run by multiple users on a system, one user may cause an update to be applied by restarting the browser, leaving other users with a buildID mismatch.

3. The browser toolbox is run under a different user profile. It is suspected that when a user opens the browser toolbox when an update is pending, it may apply the update, resulting in the buildID mismatch. This scenario has not been confirmed yet. 

----

One common thread in every scenario above is the fact that there are multiple instances of Firefox running.

When one instance has updated, the other will have a mismatched buildID and needs to be restarted, too.

Normally, this happened in the middle of the user’s session. It’s disrupting, sure, but also something that they can “forgive” Firefox for doing – as long as it only happens very rarely!

But in your case, :pomax, it happened at the very start of your session, right after a restart. And this double-restart isn’t only annoying, but it’s also a corner case that we didn’t expect.

So, is it realistic to propose a solution that prescribes the behaviour below?

1. If Firefox updates in the background right after a restart, don’t show any UI. Just perform another restart straight away. The user will experience a longer restart time, but the problem will be solved.

2. If Firefox updates in the background in the middle of the user’s session, then show the UI.

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

Half-redirecting my needinfo to Stephen.

I worry that if we did #1 above, then because restarts are happening automatically they may actually happen too fast and more than two restarts would be necessary. Consider the case that Firefox restarts while the update process is still working.

Stephen, what do you think? Would it be safe to add some more explanation here that says something like "Firefox has been updated but some parts were not able to complete updating before restart. One more restart should do the trick. [Restart Nightly]"

Comment 4

[Stephen A Pohl [:spohl]]

I think the first step is to understand how exactly we can get into this situation. Also, this report is against Nightly, which has a significantly higher likelihood of getting into odd update states due to the higher frequency of available updates. My best guess is that a Firefox process failed to quit during the first restart and was therefore still running when the buildID mismatch between the Firefox process and content process was detected.

Even once we understand how we can get into this situation, it will be a challenge to detect a double-restart situation and change the message that we display.

Unless we see a significant number of similar reports, reports against the release branch or repeated reports by the same users, I would not get too worried just yet.

Comment 5

[Justin Dolske [:Dolske]]

Did we do any user-testing on this error page? At least from the handful of reports I've seen (Bugzilla and from people in the office), this page is causing a lot of confusion.

Comment 6

[Stephen A Pohl [:spohl]]

(In reply to Justin Dolske [:Dolske] from comment #5)
> Did we do any user-testing on this error page? At least from the handful of
> reports I've seen (Bugzilla and from people in the office), this page is
> causing a lot of confusion.

This is believed to impact Nightly users significantly more than release users due to the frequency of updates, the higher likelihood of using advanced features such as DevTools (which apparently run under different profiles and trigger this issue) etc. The previous behavior was to crash the browser whenever a buildID mismatch was detected. It was believed that this was an improvement and didn't strictly need user testing.

Whether or not the message can be improved would be a question for UX.

Comment 7

[Jared Wein [:jaws] (please needinfo? me)]

Bram, based on the newer comments, would you still prefer text such as “Sorry. The update we tried to install failed. Can we try to install it again?” Should we do some basic user testing on this?

Comment 8

[Stephen A Pohl [:spohl]]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #7)
> Bram, based on the newer comments, would you still prefer text such as
> “Sorry. The update we tried to install failed. Can we try to install it
> again?” Should we do some basic user testing on this?

I'm a bit confused by this. What kind of user testing would we perform? I think we currently don't know how we got into this double-restart situation that ends up displaying the about:restartrequired page. Even if we did find out how we got into this (believed to be) very rare situation, the error page should be distinct from about:restartrequired, as it would be a different error-scenario than what about:restartrequired is addressing.

Comment 9

[Bram Pitoyo [:bram]]

Hi Jared,

When can pinpoint one (or a few) specific scenario that would result in this error, and when we cannot perform a “double-restart” (or a “restart-until-everything-is-fixed”), then we should rewrite the error page to specifically talk about what went wrong.

The error page was initially designed to provide a generic message to situations that (we thought) happen very rarely. Our thinking went: users would forgive our vagueness if the error only happens very rarely.

But if the error ends up happening a lot (maybe due to a combination of issues? We need to investigate), we should try to first prevent the issue from happening. A clearer error page would only do little to assuage user frustration that results from seeing the error more often.

Comment 10

[Jared Wein [:jaws] (please needinfo? me)]

Thanks. I'll mark this as P5 for now until we have some better steps-to-reproduce it as well as an understanding of how we get in to this state.

Comment 11

[Nathan Froyd [:froydnj]]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #10)
> Thanks. I'll mark this as P5 for now until we have some better
> steps-to-reproduce it as well as an understanding of how we get in to this
> state.

Comment 2, point 1 is an easy way of reproducing:

1. Have two profiles.
2. Have an active session with each profile.
3. Update from one session.
4. Continuing using the other session without restarting.
5. Repeat step 4 until something crashes.

It occurs for me on Nightly once every couple of days with a single profile running, but is much easier to trigger with multiple profiles running.

Comment 12

[Stephen A Pohl [:spohl]]

(In reply to Nathan Froyd [:froydnj] from comment #11)
> (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #10)
> > Thanks. I'll mark this as P5 for now until we have some better
> > steps-to-reproduce it as well as an understanding of how we get in to this
> > state.
> 
> Comment 2, point 1 is an easy way of reproducing:
> 
> 1. Have two profiles.
> 2. Have an active session with each profile.
> 3. Update from one session.
> 4. Continuing using the other session without restarting.
> 5. Repeat step 4 until something crashes.
> 
> It occurs for me on Nightly once every couple of days with a single profile
> running, but is much easier to trigger with multiple profiles running.

This is not the issue discussed in this bug. The report here is against showing this message after an update occurred, as it isn't clear for a user why another restart would be necessary after an update just took place (updated bug title to reflect this).

If you're requesting that the message for the about:restartrequired page be improved in the legitimate situation that you outline above, it should go into a separate bug.

Comment 13

[Benjamin Bach]

Normal user here!

I think part of the issues is that about:restartrequired doesn't provide access to knowing the cause.

I run stable Firefox on Ubuntu and have encountered this message without installing updates for Firefox. Several times. Now I've checked my /var/log/dpkg.log and can see that I had unattended security upgrades switched on without knowing. Which caused the message. Good for me.

But I would still point out that the message has some flaws:

1) It doesn't say what is updated
2) It doesn't say what was done in the background
3) Secondarily (for another bug): It takes away control. If you have 20 tabs open and need to open another one, this is a bit annoying (all props to session restore, but I have no idea what's in the tabs or if I'll loose data).

Unfortunately because of 1 and 2, I couldn't tell immediately why I received the message. I clicked through all my extensions to see their update timestamps, and then found dpkg.log.

Comment 15

[u641055]

There's another problem: if you click an existing tab its contents will be replaced with this message and after restarting Firefox you are left with an empty tab with no way of recovering the old link there (other than playing around with sessionrestore backups).
This is a data loss bug, in my opinion!
Note: I have disabled loading of tabs after the session restore until they are selected.

Comment 16

[Jonathan]

(In reply to u641055 from comment #15)

There's another problem: if you click an existing tab its contents will be replaced with this message and after restarting Firefox you are left with an empty tab with no way of recovering the old link there (other than playing around with sessionrestore backups).
This is a data loss bug, in my opinion!
Note: I have disabled loading of tabs after the session restore until they are selected.

Workaround: Duplicate that tab before clicking the restart button

This happened to me just now:

Profile 1:

• 1 tab (keywordsearch. Triggering the about:restartrequired-message)
• URL of that tab not restored

Profile 2:

• 1 tab with the message
• Duplicated
• Refreshing tab 2 triggers the message
• Duplicate tab 2
• Restart
• All 3 tabs have the URL

Strange

(Both profiles had additional tabs that were not affected)

This is not nightly, but release

91.0.2

Comment 17

[Stephen A Pohl [:spohl]]

I just realized that I never replied to comment 15 and comment 16: The issue described in those comments is tracked in bug 1464441.