Closing a Firefox dev build doesn't simultaneously close the browser toolbox
Categories
(DevTools :: General, defect)
Tracking
(firefox103 verified)
Tracking | Status | |
---|---|---|
firefox103 | --- | verified |
People
(Reporter: scunnane, Assigned: ochameau)
Details
(Keywords: regressionwindow-wanted)
Attachments
(3 files)
I use WSL2 with Ubuntu 20.04 for development.
Steps to reproduce:
- Do a full local build of Firefox
- Execute
./mach run
- Open the browser toolbox (
ctrl-shift-alt-i
) - Close the dev build of Firefox
Expected behavior:
After closing the dev build of Firefox, the browser toolbox window should close simultaneously.
Actual behavior:
The dev build of Firefox is now closed, but the corresponding browser toolbox window remains open. A large number of errors appear in the terminal.
I've attached a file with the full terminal output from taking the following steps:
./mach run
(right after doing a full build)- Opening the browser toolbox via the keyboard shortcut (
ctrl-shift-alt-i
) - Clicking the 'X' in the top right corner of my Firefox dev build to close the application
- Clicking the 'X' in the top right corner of my browser toolbox to end the debugging session.
Further info:
A teammate of mine was not able to reproduce this bug on MacOS.
He then tried to reproduce the bug on a Linux VM and initially couldn't. But he was using a build that was a few months old. When he refreshed the tree and rebuilt, he was able to reproduce the bug on Linux.
Comment 1•2 years ago
•
|
||
I am experiencing this too (Win10, Nightly), it feels like a recent regression.
Updated•2 years ago
|
Comment 2•2 years ago
|
||
I was able to reproduce this bug on a Devedition build as well as on a Nightly build from 2022-05-20 on Ubuntu 20.04 using the following steps:
- Open the Web Developer Tools (Ctrl+Shift+I or F12).
- Go to Settings (F1) and check the foolowing options: “Enable browser chrome and add-on debugging toolboxes” and “Enable remote debugging”.
- Open the Browser Toolbox ( Ctrl + Alt + Shift + I).
- Close Firefox.
Unfortunately the issue is intermittent for me on Ubuntu 20.04 and Win 10 and I cannot find a proper regression range. I will try to find more reliable steps to reproduce or if you think that there are any other steps that can help me reproduce this constantly please let me know.
I would also like to add a mention here, that he issue is more frequent on the Devedition build. On the Nightly build the reproduction rate is approximately 1 out of 7-10 tries.
Reporter | ||
Comment 3•2 years ago
|
||
Reporter | ||
Comment 4•2 years ago
|
||
Giorgia, when I first filed the bug, the issue was occurring consistently using my dev build on WSL2 (Windows 11).
However, it's only occurring intermittently for me now. Just now I made 10 attempts to reproduce the bug, and I only successfully reproduced it once. The other 9 times, closing the dev build DID simultaneously close the associated browser toolbox.
In the original bug description, I attached a text file with the terminal output when the bug DOES occur. Now I've also attached a separate text file with the terminal output when the bug does NOT occur.
Reporter | ||
Updated•2 years ago
|
Assignee | ||
Comment 6•2 years ago
|
||
Either of the two changes fixes the reported issue.
On the frontend side, we weren't listening to DevToolsClient/connection close.
So that there was no guarantee that the Browser Toolbox would close if the remote connection is lost.
We were actually depending on Launcher.close to be called (it is called correctly)
and complete dbgProcess.kill()
, which apparently doesn't always work during shutdown.
It looks like SubProcess.kill
was made slower and didn't always had time to complete
because on the server side, the Parent Process Target actor was trying
to switch from browser.xhtml to chrome://extensions/content/dummy.xhtml.
But this document is being destroyed and the target as well as all children
actors and watchers were still trying to debug stuff and were all throwing.
Correctly destroying the parent process target actor when browser.xhtml is closed
seems to allow SubProcess.kill to complete...
And thanks to client's closed listener, even if we stop killing the process,
the browser toolbox process will close by itself.
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Comment 8•2 years ago
|
||
bugherder |
Updated•2 years ago
|
I managed to reproduce this issue on DevEdition 102.0b9(build ID: 20220616185542) on Ubuntu 22.04. Verified as fixed on DevEdition 103.0b4(build ID: 20220703190044) on Ubuntu 22.04 and Windows 10 64-bits.
Description
•