Ensure that `FirstStartup.init` runs before browser windows are opened
Categories
(Toolkit :: General, enhancement)
Tracking
()
People
(Reporter: nalexander, Unassigned)
References
Details
The initial landing of FirstStartup placed it part way through BrowserContentHandler.handle; see Bug 1576507. What this means is that FirstStartup.init can race opening the first browser window and therefore sessionstore-windows-restored -- e.g., firefox.exe --browser --first-startup can end up with a browser window displayed before Nimbus is initialized. That's definitely not intended behaviour, even though it's mostly benign, because the stub installer invokes Firefox with only --first-startup and a handful of flags that don't impact window opening.
This ticket tracks lifting FirstStartup.init to be as early as possible during command line handling, so that there's less risk of racing when opening browser windows.
|
Reporter | |
Comment 1•28 days ago
|
||
mconley: did you and rhelmer ever think about what guarantees FirstStartup should make about windows, session restore, etc? Any reason to not make this more predictable?
|
||
Comment 2•28 days ago
|
||
Hm. It does look as if there are a few branches above that call to FirstStartup.init() where a browser window might open, yes. I'd certainly be okay moving the call earlier in that command line handler (maybe have it be the first thing).
|
|
||
Comment 3•27 days ago
|
||
Is this something you noticed that is blocking high priority work?
|
|
Reporter | |
Comment 4•27 days ago
|
||
(In reply to Mike Conley (:mconley) (:⚙️) from comment #3)
Is this something you noticed that is blocking high priority work?
No -- it works in my case (--first-startup from the stub installer) because there are no window-creating parameters. So it's just for robustness.
Description
•