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

VERIFIED FIXED in Firefox 65

Status

()

defect
P1
normal
VERIFIED FIXED
7 months ago
6 months ago

People

(Reporter: StefanG_QA, Assigned: spohl)

Tracking

({regression})

65 Branch
mozilla66
Points:
---

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox64 unaffected, firefox65+ verified, firefox66+ verified)

Details

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.
Wasn't able to reproduce this using 20181210164452. I successfully updated from 64 beta to 65.0b3. Currently running ahead on 10.14.3.
Any sort of console errors when it happens?
Flags: needinfo?(stefan.georgiev)
No console output. Here is a video of the issue: https://goo.gl/PonBc6
Flags: needinfo?(stefan.georgiev)
Does it only happen when trying to update from 64.0b3?
Flags: needinfo?(stefan.georgiev)
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.
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.
Flags: needinfo?(stefan.georgiev)
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.
Component: General → Application Update
Priority: -- → P3
Product: Firefox → Toolkit
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?
Flags: needinfo?(spohl.mozilla.bugs)
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
(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.
(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?
Flags: needinfo?(spohl.mozilla.bugs)
(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.
(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.
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.
Don't know about all the comments but 65.0b3 does not start on OS X 10.13.6
(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.
Flags: needinfo?(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.
Flags: needinfo?(rvjanc00)
EDIT - Only a FF65b3 issue.
Markus filed a couple similar-looking bugs recently too.
See Also: → 1513335, 1513341
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
Component: Application Update → Startup and Profile System
(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.
Assignee: nobody → spohl.mozilla.bugs
Status: NEW → ASSIGNED
(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.
See Also: 1513335, 1513341
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.
Don't know if this helps, the issue does not exist in the latest Nightly.
Fixed by the backout of bug 469990 (cset 590bdef6b312) which will be merged to beta shortly.
Status: ASSIGNED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
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
Target Milestone: --- → mozilla66
Stefan, please verify that this is fixed for you when 65.0b5 ships on Tuesday.
Flags: qe-verify+
Flags: needinfo?(stefan.georgiev)
65.0b5-candidates/build1 launches just fine with another instance running.
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.
Status: RESOLVED → VERIFIED
Flags: needinfo?(stefan.georgiev)
Thanks for helping narrow this down and for confirming the fix, Stefan.
Priority: P3 → P1
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.