1513328 - Beta does not start after update to 65.0b3 on OS X

Status: VERIFIED FIXED

(Toolkit :: Startup and Profile System, defect, P1)

Description

[Stefan [:StefanG_QA]]

STR:

1. Download Beta 65.0b3 and install it or update an old Beta build to the latest (65.0b3)
2. Start the build
3. Observe

AR: Nothing happened. The build is not started. When double-clicking the Firefox icon the screen flicker for ~0.2-5 seconds and the build is not started.
ER: The build should be started without any issue. 

Tested on OS X 10.13.6 and 10.14.2. 

Installing fresh build of 65.0b3 does not make any difference.

The issue is not observed on DevEdition 65.0b3.

Comment 1

[Marcia Knous [:marcia]]

Wasn't able to reproduce this using 20181210164452. I successfully updated from 64 beta to 65.0b3. Currently running ahead on 10.14.3.

Comment 2

[Ryan VanderMeulen [:RyanVM]]

Any sort of console errors when it happens?

Comment 3

[Stefan [:StefanG_QA]]

No console output. Here is a video of the issue: https://goo.gl/PonBc6

Comment 4

[Marcia Knous [:marcia]]

Does it only happen when trying to update from 64.0b3?

Comment 5

[Stephen A Pohl [:spohl]]

Also, does this still reproduce if all other instances of Firefox are closed? There appears to be another instance running in the background in the video posted in comment 3.

Comment 6

[Stefan [:StefanG_QA]]

This was happening in other versions as well (59.0b3, 63.0b3, 60.0b5)

(In reply to Stephen A Pohl [:spohl] from comment #5)
> Also, does this still reproduce if all other instances of Firefox are
> closed? There appears to be another instance running in the background in
> the video posted in comment 3.

Actually no, the issue does not happen if only the updating instance of Firefox is running.
In the video, I was running esr 60.4.0 as another instance. I can reproduce the issue when running ESR while trying to perform the update.

Comment 7

[Stephen A Pohl [:spohl]]

So this only affects users who run multiple versions of Firefox at the same time, which is rather rare. One way to fix this might be for the updater to pass the current profile to the new instance after restart.

Comment 8

[Robert Strong (they/them - no direct email)]

Stephen, do you know what landing regressed this? According to the report this also affects simply installing Firefox as well. Since that isn't controlled by update what bug is going to fix that issue?

Comment 9

[Robert Strong (they/them - no direct email)]

Specifically, "Download Beta 65.0b3 and install it"

STR:

1. Download Beta 65.0b3 and install it or update an old Beta build to the latest (65.0b3)
2. Start the build
3. Observe

Comment 10

[Robert Strong (they/them - no direct email)]

(In reply to Stephen A Pohl [:spohl] from comment #7)
> So this only affects users who run multiple versions of Firefox at the same
> time, which is rather rare. One way to fix this might be for the updater to
> pass the current profile to the new instance after restart.
This worked previously because the environment contains the profile information in the XRE_PROFILE_NAME env var already so this should not be necessary.

Comment 11

[Stephen A Pohl [:spohl]]

(In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to contact me) from comment #8)
> Stephen, do you know what landing regressed this? According to the report
> this also affects simply installing Firefox as well. Since that isn't
> controlled by update what bug is going to fix that issue?

My understanding was that this is "installing and opening when another version of Firefox is already running", which will make us switch to the open instance. Are you saying that this isn't the expected behavior?

Comment 12

[Robert Strong (they/them - no direct email)]

(In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to contact me) from comment #10)
> (In reply to Stephen A Pohl [:spohl] from comment #7)
> > So this only affects users who run multiple versions of Firefox at the same
> > time, which is rather rare. One way to fix this might be for the updater to
> > pass the current profile to the new instance after restart.
> This worked previously because the environment contains the profile
> information in the XRE_PROFILE_NAME env var already so this should not be
> necessary.
Forgot to mention that XRE_PROFILE_NAME env var is set in nsAppRunner.cpp and is used by the restart code which has many consumers besides app update. Maybe this is why the simple install case is also failing.

Comment 13

[Robert Strong (they/them - no direct email)]

(In reply to Stephen A Pohl [:spohl] from comment #11)
> (In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to
> contact me) from comment #8)
> > Stephen, do you know what landing regressed this? According to the report
> > this also affects simply installing Firefox as well. Since that isn't
> > controlled by update what bug is going to fix that issue?
> 
> My understanding was that this is "installing and opening when another
> version of Firefox is already running", which will make us switch to the
> open instance. Are you saying that this isn't the expected behavior?
Not sure about all of the details but the nsAppRunner code handled this in the past per my other comments so if you had two instances running and one of the instances updated it would relaunch using the correct profile, command line options including --no-remote if present, etc. without any issue.

Comment 14

[Robert Strong (they/them - no direct email)]

So basically, if for some reason the profile it is needed to provide the profile when updating then that should already be happening and if that isn't working then there is likely a bug in nsAppRunner.cpp.

I don't know if you recall but this is why I stated that it was important to keep the env around when you added the ability for the updater to elevate on OS X. Otherwise the correct profile, etc. wouldn't be properly set.

Comment 15

[rvjanc00]

Don't know about all the comments but 65.0b3 does not start on OS X 10.13.6

Comment 16

[Stephen A Pohl [:spohl]]

(In reply to rvjanc00 from comment #15)
> Don't know about all the comments but 65.0b3 does not start on OS X 10.13.6

Is this after an upgrade? Or fresh install? Is there another instance of Firefox running?

I just downloaded 65.0b3, fresh install with no other instances of Firefox running and 65.0b3 starts as expected.

Comment 17

[rvjanc00]

This is a fresh install / update. I tried both with neither starting.

I have FF64.0 running when the problem occurs. Note, there is no problem in launching FF64b14 when FF64.0 is running, this is only a FF66b3 issue.

I have NEVER had an issue running multiple instances including Nightly.

Comment 18

[rvjanc00]

EDIT - Only a FF65b3 issue.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Markus filed a couple similar-looking bugs recently too.

Comment 20

[Robert Strong (they/them - no direct email)]

Given that the update is applied successfully and that this bug is happening during startup after an update I'm moving this to Toolkit -> Startup and Profile System since that is where the code that handles dealing with running instances, profile selection, etc. lives though this might be better filed in Core:Widget Cocoa per bug 1513341.

(In reply to Stephen A Pohl [:spohl] from comment #7)
> So this only affects users who run multiple versions of Firefox at the same
> time, which is rather rare. One way to fix this might be for the updater to
> pass the current profile to the new instance after restart.
As stated in comment #10 this is already the case and is handled by toolkit/xre/nsAppRunner.cpp

Comment 21

[rvjanc00]

(In reply to Robert Strong (Robert he/him) [:rstrong] (use needinfo to contact me) from comment #20)
 > So this only affects users who run multiple versions of Firefox at the same
> time, 

I can verify that. FF65b3 launches fine if no other instances are running.

Comment 22

[Stephen A Pohl [:spohl]]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #19)
> Markus filed a couple similar-looking bugs recently too.

Those bugs were most likely caused by bug 469990, which is not on beta. This bug here is different and I have been able to reproduce the issue in 65.0b3. I'm looking into all of these bugs.

Comment 23

[Stephen A Pohl [:spohl]]

I can reproduce with the official 65.0b3, but I seem unable to reproduce this with a local Beta build. Will need to find a different way to isolate this.

Comment 24

[rvjanc00]

Don't know if this helps, the issue does not exist in the latest Nightly.

Comment 25

[Stephen A Pohl [:spohl]]

Fixed by the backout of bug 469990 (cset 590bdef6b312) which will be merged to beta shortly.

Comment 26

[Ryan VanderMeulen [:RyanVM]]

The backout has been landed on Beta and will be included in the 65.0b5 release.
https://hg.mozilla.org/releases/mozilla-beta/rev/978402f68f3c

Comment 27

[Ryan VanderMeulen [:RyanVM]]

Stefan, please verify that this is fixed for you when 65.0b5 ships on Tuesday.

Comment 29

[rvjanc00]

65.0b5-candidates/build1 launches just fine with another instance running.

Comment 30

[Stefan [:StefanG_QA]]

This issue has been verified on OS X 10.14. Firefox 65.0b5 launches correctly after update while another instance is running in the background.

Comment 31

[Ryan VanderMeulen [:RyanVM]]

Thanks for helping narrow this down and for confirming the fix, Stefan.