Closed
Bug 1513328
Opened 6 years ago
Closed 6 years ago
Beta does not start after update to 65.0b3 on OS X
Categories
(Toolkit :: Startup and Profile System, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla66
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox64 | --- | unaffected |
firefox65 | + | verified |
firefox66 | + | verified |
People
(Reporter: StefanG_QA, Assigned: spohl)
References
Details
(Keywords: regression)
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.
status-firefox65:
--- → affected
Comment 1•6 years ago
|
||
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•6 years ago
|
||
Any sort of console errors when it happens?
Flags: needinfo?(stefan.georgiev)
Reporter | ||
Comment 3•6 years ago
|
||
No console output. Here is a video of the issue: https://goo.gl/PonBc6
Flags: needinfo?(stefan.georgiev)
Comment 4•6 years ago
|
||
Does it only happen when trying to update from 64.0b3?
Flags: needinfo?(stefan.georgiev)
Assignee | ||
Comment 5•6 years ago
|
||
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.
Reporter | ||
Comment 6•6 years ago
|
||
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)
Assignee | ||
Comment 7•6 years ago
|
||
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
Comment 8•6 years ago
|
||
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)
Comment 9•6 years ago
|
||
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•6 years ago
|
||
(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.
Assignee | ||
Comment 11•6 years ago
|
||
(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)
Comment 12•6 years ago
|
||
(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•6 years ago
|
||
(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•6 years ago
|
||
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•6 years ago
|
||
Don't know about all the comments but 65.0b3 does not start on OS X 10.13.6
Assignee | ||
Comment 16•6 years ago
|
||
(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)
Comment 17•6 years ago
|
||
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)
Comment 18•6 years ago
|
||
EDIT - Only a FF65b3 issue.
Comment 19•6 years ago
|
||
Markus filed a couple similar-looking bugs recently too.
Comment 20•6 years ago
|
||
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
Comment 21•6 years ago
|
||
(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 | ||
Updated•6 years ago
|
Assignee: nobody → spohl.mozilla.bugs
Status: NEW → ASSIGNED
Assignee | ||
Comment 22•6 years ago
|
||
(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.
Assignee | ||
Comment 23•6 years ago
|
||
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•6 years ago
|
||
Don't know if this helps, the issue does not exist in the latest Nightly.
Assignee | ||
Comment 25•6 years ago
|
||
Fixed by the backout of bug 469990 (cset 590bdef6b312) which will be merged to beta shortly.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•6 years ago
|
Comment 26•6 years ago
|
||
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
status-firefox66:
--- → fixed
Target Milestone: --- → mozilla66
Updated•6 years ago
|
status-firefox64:
--- → unaffected
status-firefox-esr60:
--- → unaffected
tracking-firefox65:
--- → +
tracking-firefox66:
--- → +
Keywords: regression
Comment 27•6 years ago
|
||
Stefan, please verify that this is fixed for you when 65.0b5 ships on Tuesday.
Flags: qe-verify+
Flags: needinfo?(stefan.georgiev)
Comment 29•6 years ago
|
||
65.0b5-candidates/build1 launches just fine with another instance running.
Reporter | ||
Comment 30•6 years ago
|
||
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•6 years ago
|
||
Thanks for helping narrow this down and for confirming the fix, Stefan.
Updated•6 years ago
|
Priority: P3 → P1
Reporter | ||
Updated•6 years ago
|
Flags: qe-verify+
You need to log in
before you can comment on or make changes to this bug.
Description
•