Closed
Bug 1514200
Opened 6 years ago
Closed 6 years ago
65 betas fail to start on macOS
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1513328
Tracking | Status | |
---|---|---|
firefox64 | --- | unaffected |
firefox65 | - | fixed |
firefox66 | --- | unaffected |
People
(Reporter: kats, Unassigned)
Details
(Keywords: regression)
I just installed the latest macOS security update on 10.13, and as part of that reboot my beta-channel Fx updated to 65.0b4. Which fails to start. I downloaded fresh copies of both b3 and b4 from archive.m.o and they both fail. 64.0b10 works, for comparison.
When it fails to start, I get no feedback beyond the macOS "you downloaded this from a website, confirm start plz" dialog. Note that I have the setting to show the profile manager on startup, and I don't get the profile manager window. Running from the command line gives no output.
Reporter | ||
Comment 1•6 years ago
|
||
64.0b14 also works, so it's a regression in 65
status-firefox64:
--- → unaffected
status-firefox65:
--- → affected
Keywords: regression
Version: 57 Branch → 65 Branch
Reporter | ||
Comment 3•6 years ago
|
||
Running:
Firefox\ 65.0b4.app/Contents/MacOS/firefox --new-instance -P test
similarly just exits, so it may not be related to the profile manager window.
Running:
Firefox\ 65.0b4.app/Contents/MacOS/firefox --help
emits the help output like I would expect
Running under lldb shows an exit code of 1, as opposed to a crash.
Reporter | ||
Comment 4•6 years ago
|
||
I ran a build off mozilla-beta using mozregression, and that ran fine (using the mozregression-generated profile). And then I ran the exact same build manually (not with mozregression) and it failed to start. So likely the problem is profile-related somehow.
Reporter | ||
Comment 5•6 years ago
|
||
Jeff said that Markus might know what's going on here and/or it might be intentional and/or related to having other Firefox instances running.
Flags: needinfo?(mstange)
Comment 6•6 years ago
|
||
I've never heard of --new-instance before. Can you try whether -no-remote works for you?
Jeff was referring to bug 1513335, which was fixed by a backout.
Flags: needinfo?(mstange)
Reporter | ||
Comment 7•6 years ago
|
||
--no-remote does work, yes. I see this printed to the console:
Can't find symbol 'GetGraphicsResetStatus'.
but that might be totally unrelated.
Is running without --no-remote intended to not work in 65 beta?
Comment 8•6 years ago
|
||
The offending patch was backed out from Beta in bug 469990 comment 77, so it should work again in the next 65 beta.
(I wouldn't go quite as far as saying "intended to not work", but some effects were expected from that patch...)
Reporter | ||
Comment 9•6 years ago
|
||
Ah, cool. Sounds like this is a dupe of bug 1513328 then.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Fixed in bug 1513328.
You need to log in
before you can comment on or make changes to this bug.
Description
•