Closed Bug 1492023 Opened 6 years ago Closed 6 years ago

Unacceptable. "Sorry. We just need to do one small thing to keep going."

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Version:
62 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1705217

People

(Reporter: clickwir631, Unassigned, NeedInfo)

Details

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

Steps to reproduce:

When I opened a new tab to get some work done tonight, I get greeted with the following message: "Sorry. We just need to do one small thing to keep going." "! Restart Required !"

I understand that updates are needed and part of a healthy system. But I have work to do right now and I can't be forced to doing updates. There are other tabs I have open that I cannot loose where I am with them and when I restart, I loose where I am and what I've done. 

Now I'm forced to reuse existing tabs to try and get my work done before I can restart. This is causing my work to be delayed and having to redo work that I've already done

I don't mind a healthy warning about a restart being needed, but this heavy handed approach to blocking is unacceptable. 

Version: 62.0+build2-0ubuntu0.18.04.5


Actual results:

Browsing blocked.


Expected results:

I should be allowed to browse and use the program without being blocked like this.
Component: Untriaged → Application Update
Product: Firefox → Toolkit
This warning was added in bug 1366808. It's not telling you that you need to restart in order to apply an update, it's telling you that an update has already been applied in the background while the browser was running, outside of its control (presumably by the package manager). That means that if you don't restart then you're risking tabs crashing because new child processes can't be started when the version on disk is different from the version that's running. That's why the message has the level of urgency that it does. Prior to bug 1366808 (prior to version 62, that is) the new tab you created would simply have crashed immediately.

There's not really anything to be done about this except to heed the warning and wrap up what work you can in your existing tabs.
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
See Also: → 1366808

I agree that this is better than crashing. But, it seems like this isn't an insolvable problem. After all, chrome doesn't have this behaviour after it is updated on disk by a package manager, and it also uses a multi-process architecture.

I agree with the OP that this is unacceptable behaviour. I would readily accept the current behaviour as a stop-gap until a better solution is found, but closing this bug as invalid without even investigating if there is a way to allow users to continue browsing after an out-of-band update seems like the wrong thing to do.

I would really like to see firefox recapture some marketshare from chrome, but things like this make that hard to do.

I should also mention that as a Linux user, I get this page basically every time firefox updates, since firefox is always updated in the background by my package manager. The restart page might be acceptable on windows and mac, where this is more rare, but on linux it is much more of a problem.

It's still bad UI and unacceptable behavior:

  • Firefox should not assume that all users are a bit slow there up, and the message should point more clearly to the problem:

"Your Firefox executable was changed, perhaps updated, and Firefox needs to be re-started before you can open a new tab. If you want to avoid this problem in the future, configure any third-party package manager to warn you before update to Firefox"

As it stands now, it looks like the Firefox team has decided disruptive updates are a necessary evil. They are not.

As it stands now, it looks like the Firefox team has decided disruptive updates are a necessary evil. They are not.

Seriously! Name one other program on linux that behaves like this. Imagine if gnome or kde required you to restart whenever your package manager updates them.

How was this resolved? This is bad UI. It's one of the reasons I left Windows in the first place. Restarting the browser after updates should not be forced. Instead, there could be a message/popup that informs the user that they need to restart to apply updates.

Flags: needinfo?(clickwir631)

Can I request that this be reopened. This is a poor experience that I have to deal with every time I update firefox. And I suspect many other linux users feel this pains as well. At the very least, could the "Restart" button actually restart firefox, rather than simply closing it, and requiring me to start firefox again myself.

Flags: needinfo?(nalexander)

(In reply to Thayne from comment #11)

Can I request that this be reopened.

You can, and have done so, but there's nothing to be done here: #c1 is still the explanation, and it's not actionable.

This is a poor experience that I have to deal with every time I update firefox.

Pretty much. The architecture of web browsers is multi-process for security reasons; it's just not feasible to "switch out" some processes without the web browser's knowledge and expect that to work. Many, many daemon + client combinations are going to see the same problems -- but most don't try to avoid this issue with a message.

And I suspect many other linux users feel this pains as well.

Probably.

At the very least, could the "Restart" button actually restart firefox, rather than simply closing it, and requiring me to start firefox again myself.

Now this sounds like something that might be actionable. I am not aware of a way to do this on Linux (or via POSIX) but presumably many exist. If you think there's a good way to do this, or that we're supposed to be doing this, please file a separate ticket to track improving this particular workflow.

As it stands, there's no reasonable way to accommodate transparent background updates, so this remains closed.

Flags: needinfo?(nalexander)

The architecture of web browsers is multi-process for security reasons; it's just not feasible to "switch out" some processes without the web browser's knowledge and expect that to work.

Chrome also uses multiple processes, and does not have this issue. I'm not familiar with Firefox's implementation, but it seems like this is not an unsolvable problem. From my understanding, this isn't an issue if firefox updates itself. How is that different from the package manager updating firefox?

Maybe the problem is with how the processes are created? Looking at my running firefox process, it looks like they are all running the same executable but with different arguments, so I'm guessing that it creates new process using a fork/exec with the same executable. It seems to me, that if instead it just did a fork, and changed the state of the new process, you wouldn't have to worry about the new process not matching the old one. (this approach was mentioned at https://bugzilla.mozilla.org/show_bug.cgi?id=1366808#c60). That might be more difficult to implement, but not impossible. I don't think that approach would work on Windows, but this error is much less common on Windows than on Linux.

Alternatively, if the IPC between processes was backwards compatible between consecutive releases of firefox, then I think you could avoid having to force a restart unless there have been two updates since the last restart, which is considerably less likely.

I understand this is not an easy problem, but I don't think it is impossible (at least on Linux).

Many, many daemon + client combinations are going to see the same problems -- but most don't try to avoid this issue with a message.

Yes, the more standard approach to dealing with this is to make the interface between the client and server backwards compatible, so that clients and servers of different versions are able to communicate with each other, possibly using protocol negotiation.

(In reply to Thayne from comment #13)

The architecture of web browsers is multi-process for security reasons; it's just not feasible to "switch out" some processes without the web browser's knowledge and expect that to work.

Chrome also uses multiple processes, and does not have this issue. I'm not familiar with Firefox's implementation, but it seems like this is not an unsolvable problem. From my understanding, this isn't an issue if firefox updates itself. How is that different from the package manager updating firefox?

Firefox stages updates, does the swap atomically, and then restarts itself, so that the main and content processes always use the same binaries.

Maybe the problem is with how the processes are created? Looking at my running firefox process, it looks like they are all running the same executable but with different arguments, so I'm guessing that it creates new process using a fork/exec with the same executable. It seems to me, that if instead it just did a fork, and changed the state of the new process, you wouldn't have to worry about the new process not matching the old one. (this approach was mentioned at https://bugzilla.mozilla.org/show_bug.cgi?id=1366808#c60). That might be more difficult to implement, but not impossible. I don't think that approach would work on Windows, but this error is much less common on Windows than on Linux.

I can't comment on the technical feasibility of this approach. I believe that there are trade-offs in all of the process launching mechanisms (fork/exec, etc).

Alternatively, if the IPC between processes was backwards compatible between consecutive releases of firefox, then I think you could avoid having to force a restart unless there have been two updates since the last restart, which is considerably less likely.

I understand this is not an easy problem, but I don't think it is impossible (at least on Linux).

It's not an easy problem, but you're right, it's not impossible. It's a huge effort for very little gain, though, and no matter how hard one tries, it's unlikely you'll ever maintain back compatibility.

Many, many daemon + client combinations are going to see the same problems -- but most don't try to avoid this issue with a message.

Yes, the more standard approach to dealing with this is to make the interface between the client and server backwards compatible, so that clients and servers of different versions are able to communicate with each other, possibly using protocol negotiation.

The labour involved in this is significant. It's certainly very unlikely to ever come to pass.

Thanks for filing the ticket about restarting -- that seems like something we should be able to improve.

Firefox stages updates, does the swap atomically, and then restarts itself

I'm not entirely sure how the "swap atomically" part works, but why can't it detect when the package manager updates firefox, and restart itself in a similar way?

Also, I'm curious how chrome handles this issue, and if their solution could be adapted to firefox.

(In reply to Thayne from comment #16)

Firefox stages updates, does the swap atomically, and then restarts itself

Let me expand on this: First Firefox stages the update. Then Firefox waits to be restarted naturally. If this takes a long time, notifications are shown requesting that the user restart to install the update. Regardless of how it exits, when Firefox starts next, it notices the pending update very early in startup, starts the updater process, and terminates. The updater process swaps the current installation for the staged, updated installation. Then the updater starts the new Firefox installation.

I'm not entirely sure how the "swap atomically" part works, but why can't it detect when the package manager updates firefox, and restart itself in a similar way?

The mechanism I described above is completely different from how a package manager updates Firefox. I am not aware of the specifics behind how package managers work, but presumably they are removing the old installation's files and replacing them with the updated ones. In any event, they aren't invoking Firefox's built-in updater.

This means that Firefox not only doesn't control when a package manager updates it, it isn't even aware that it has been updated until it tries to launch a new process and discovers that it didn't get the version of the process it expected. Once Firefox is in this state, the best we can really do is to display the page you are seeing: "Sorry. A restart is required to keep using Firefox".

Also, I'm curious how chrome handles this issue, and if their solution could be adapted to firefox.

I'm also curious how Chrome handles it. If I have some time, I might take a look and try to find out. However, it is quite likely that structural differences would prevent us from just copying their solution.

This means that Firefox not only doesn't control when a package manager updates it, it isn't even aware that it has been updated until it tries to launch a new process and discovers that it didn't get the version of the process it expected.

Obviously there isn't anything to do about not controlling when a package manager updates firefox, but it is possible to detect if it has been updated. One possibility is to use inotify to watch when certain files are changed, although without knowing more details about how it works, I'm not sure if that would be useful. But perhaps a better way would be to expose a mechanism to do an in-place update which could be performed in a post (or pre?) install hook for the package manager. Most package managers support such hooks.

Resolution: INVALID → DUPLICATE
See Also: 1366808 →
You need to log in before you can comment on or make changes to this bug.