Closed Bug 1462805 Opened 7 years ago Closed 7 years ago

Firefox said "restart required" when I tried to load a file:// link

Categories

(Toolkit :: Application Update, defect)

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

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: botond, Unassigned)

References

Details

I had a fairly strange experience with Firefox today. I was running a Nightly build that's a few days old, and tried to load a file:// page. I got a page that said: "Restart required 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 restore all your pages, windows and tabs afterwards, so you can be on your way quickly." Tried again in a new tab, same result. Basically, Firefox was forcing me to restart the browser before rendering the file:// page. I assume this is not intentional?
Regression from bug 1366808 which added this page?
See Also: → 1366808
:spohl, is this an expected outcome of bug 1366808?
Flags: needinfo?(spohl.mozilla.bugs)
Did this go away after a restart? If yes, this is intentional because there would be a buildID mismatch between content and parent process otherwise, which can lead to undefined behavior including crashes.
Flags: needinfo?(spohl.mozilla.bugs) → needinfo?(botond)
(In reply to Stephen A Pohl [:spohl] from comment #3) > Did this go away after a restart? Yes. > If yes, this is intentional because there > would be a buildID mismatch between content and parent process otherwise, > which can lead to undefined behavior including crashes. Interesting. Is there something about file:// links that causes them to create a new content process? Does the issue ever affect web links?
Flags: needinfo?(botond)
(In reply to Botond Ballo [:botond] from comment #4) > (In reply to Stephen A Pohl [:spohl] from comment #3) > > Did this go away after a restart? > > Yes. Great! > > If yes, this is intentional because there > > would be a buildID mismatch between content and parent process otherwise, > > which can lead to undefined behavior including crashes. > > Interesting. Is there something about file:// links that causes them to > create a new content process? Bug 1366808 handles buildID mismatches no matter the reason why a content process was launched. I'm not aware that file:// links would always launch a new content process. This might just have been a coincidence. > Does the issue ever affect web links? Absolutely. The check is performed any time a new content process is launched. This is probably the more likely situation when we display this new about: page to the user.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
I didn't mean to close this bug with my last comment, but I guess that's where it's headed. Please reopen if you think it's necessary.
Resolution: FIXED → INVALID
Just so I understand the scenario, this happens when: - You're using multiple profiles - Profile A updates while profile B is running - Profile B tries to launch a new content process? Would it make sense to mention in the message that "another profile has triggered updating of the program files", or something like that?
(In reply to Botond Ballo [:botond] from comment #7) > Just so I understand the scenario, this happens when: > > - You're using multiple profiles > > - Profile A updates while profile B is running > > - Profile B tries to launch a new content process? Correct. > Would it make sense to mention in the message that "another profile has > triggered updating of the program files", or something like that? No, because it may not be apparent to users that they are running multiple profiles. For example, I've been told that DevTools run in their own profile. This would cause this issue, but the user would not have been aware that there was a second profile involved.
(In reply to Stephen A Pohl [:spohl] from comment #5) > I'm not aware that file:// links would always launch a > new content process. This might just have been a coincidence. File URLs are opened in a separate content process, for sandboxing reasons. So if you'd never opened a file URL in your current session, and then you opened one, you'd create a new content process.
(In reply to Andrew McCreight [:mccr8] from comment #9) > (In reply to Stephen A Pohl [:spohl] from comment #5) > > I'm not aware that file:// links would always launch a > > new content process. This might just have been a coincidence. > > File URLs are opened in a separate content process, for sandboxing reasons. > So if you'd never opened a file URL in your current session, and then you > opened one, you'd create a new content process. Ah, this makes sense. Thanks for the clarification!

I have started to see this more often, and not just with file:// URLs.

I am finding it sufficiently annoying (especially in combination with bug 1536150), that I'm seriously considering switching from dogfooding the Nightly channel to a more stable one like Beta, or alternately disabling automatic updates on the Nightly channel.

I'm concerned that I'm not the only one who feels like this, and that we may be driving users away from the Nightly channel as a result of this behaviour.

I use firefox with multiple profiles. I have literally 100s of browser windows in different profiles, normally running for weeks and months.

This behaviour is so annoying that I consider switch to other browsers. Can someone please explain why I can not
run different versions of firefox in different profiles ? What communication happens between different profiles that
requires the different firefox instances to run the same code ?

Does the startup-flag --new-instance avoid this problem ?

(In reply to Kurt Jaeger from comment #12)

Can someone please explain why I can not run different versions of firefox in different profiles ?

Yes, I can explain. Normally, Firefox downloads and prepares updates while it is running. When it restarts, it detects the pending update very early in startup and, instead of completing startup, starts the update process. After the updater runs, Firefox is restarted.

If you run Firefox normally (i.e. with a single profile) when an instance of Firefox is already running, it simply connects to that instance and tells it to open the specified link or new window. This does not invoke the updater.

But, if you start a new instance of Firefox with another profile, it will go through the usual startup process. This includes installing any pending update. When already-running instances of Firefox try to start a new process (they will need to do this from time to time), they will discover that the process that they start is not the same version as the process that is running. This results in the "Restart Required" page being shown.

For some time now, I've been trying to investigate solutions to this problem. So far, the potential solutions that I have found require substantially more developer-hours than are available for this project.

We have also considered preventing Firefox from updating if there is another instance of Firefox still running. But there are two problems. The first has to do with malware. Malware often attacks web browsers for various reasons. To prevent the browser from "fighting back", it often seeks to prevent the browser from updating. We really don't want malware to be able to prevent us from updating by pretending to be a running Firefox instance.

The second problem has to do with the fact that we often release important security updates. The longer that users avoid installing these updates, the more likely it is that they will be exposed to malicious code that can exploit old browsers. Even if you only navigate to sites that you trust, malware sometimes finds its way into trusted systems, especially through advertisements. If we prevent updates when another profile is running and the user always runs multiple profiles, then we are sort of stuck in a situation where we can never install potentially important updates.

Does the startup-flag --new-instance avoid this problem ?

No, I don't believe there is a startup flag that will solve this problem for you.

I'm sorry that I don't have better news for you about this. If you would like to watch our progress as we work on this bug, I would recommend following Bug 1480452.

You need to log in before you can comment on or make changes to this bug.