User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20180205211730 Steps to reproduce: 1. Leave Firefox Developer Edition open for a couple of days 2. Press Ctrl+Alt+Shift+I Actual results: The browser applies updates to the remote debugging process before prompting to allow remote debugging... which I suspect is the cause of the "Firefox crashes on attempting to open a new window" bugs I've been noticing occasionally. Expected results: Updates shouldn't have been applied since this action doesn't result in the existing Firefox process being restarted.

...and it appears to just have caused a Firefox that had been stable for several days to crash when I clicked a different tab.

The update issue is tracked in Bug 1120863. Although I haven't seen reports of the main profile crashing associated with this - does that continue to happen after restarting Firefox?

While I agree that the two bugs share root causes, the symptoms I'm encountering are very different from that bug. In my case, the browser toolbox works perfectly well... but the main window becomes a ticking crash time-bomb, just waiting for the right navigation/new-window action. To answer your question, no. Once I reopen Firefox after it crashes, crashing won't happen until the next time Ctrl+Alt+Shift+I pushes the running process out of sync with the on-disk version. (Given that, a few years ago, this same kind of mismatch could cause Flash plugin processes to crash, my hypothesis is that the crashes happen when the running chrome process tries to launch a new content process and trips over the version mismatch.)