Startup should handle being launched without calling ProcessUpdates
Categories
(Toolkit :: Startup and Profile System, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox65 | --- | unaffected |
firefox66 | --- | unaffected |
firefox67 | --- | fixed |
People
(Reporter: robert.strong.bugs, Assigned: mossop)
References
Details
(Keywords: regression)
Attachments
(1 file)
Not sure when startup changed but it is calling ProcessUpdates when being launched with an existing instance instead of handing off to the existing instance before ProcessUpdates.
Assignee | ||
Comment 1•6 years ago
|
||
Assignee | ||
Comment 2•6 years ago
|
||
Comment on attachment 9050347 [details]
Bug 1534508: Move ProcessUpdates to after we have attempted to remote arguments to an existing instance.
Haven't had chance to test this yet but I'd expect this to return us to the previous state where we check for existing instances and remote to them before calling ProcessUpdates.
But that leads me to a question, wasn't this always an issue for cases where users were running with -no-remote where we wouldn't check for an existing instance?
Reporter | ||
Comment 4•6 years ago
|
||
I haven't seen bugs on issues when using -no-remote. It is possible it was an issue and I'll check on Windows if there was previously.
Reporter | ||
Comment 5•6 years ago
|
||
It looks like -no-remote also has had this issue since day one of app update though the lack of bug reports make me think it didn't cause crashes such as in bug 1534485
Reporter | ||
Comment 6•6 years ago
|
||
Comment on attachment 9050347 [details]
Bug 1534508: Move ProcessUpdates to after we have attempted to remote arguments to an existing instance.
I'm fine with giving this feedback+ but with all of the recent changes to startup it is impossible for me to say whether there will be other unintended side affects in startup.
Comment 8•6 years ago
|
||
bugherder |
Updated•6 years ago
|
Updated•6 years ago
|
Description
•