For `--backgroundtask ... --jsdebugger` invocations, the devtools
profile is kept inside the ephemeral background profile. This means
that breakpoints, etc are not preserved across repeated debugging
invocations. This change eases the debugging process.
Differential Revision: https://phabricator.services.mozilla.com/D145893
Right now we rely on the menulist to be injected by hand in all the
relevant windows. Instead create it lazily, making the select code more
standalone.
The DevTools window was missing it, for example.
Differential Revision: https://phabricator.services.mozilla.com/D149620
This only fail on MBT because it still uses non-EFT
and the top level document is displayed in the iframe dropdown
via the old "listFrames/frameUpdate" codepath.
So that its frameData's id isn't related to a target actor
but rather to a frame of the parent-process/window-global target actor...
I'm adding test coverage for the regular web toolbox,
but the fix only reproduce in the context of the browser toolbox.
Depends on D149257
Differential Revision: https://phabricator.services.mozilla.com/D148793
This add some minimal test coverage for the UI bits.
But more detailed test should rather be done around the TargetCommand API (browser_target_command_scope_flag.js).
Depends on D149256
Differential Revision: https://phabricator.services.mozilla.com/D149257
When passing an array, only booleans and number were accepted.
Also arrays were stringified to list of value coma separated,
as if arrays were refering to list of arguments.
That while passing a primitive value would be passed as a unique argument.
Clarify this by explicitely accepting arrays refering as list of argument,
or a primitive value being a unique argument.
I'm also fixing an issue with exceptions not being correctly reported.
Depends on D148527
Differential Revision: https://phabricator.services.mozilla.com/D149256
This introduces a checkbox in the iframe dropdown to enable/disable multiprocess debugging live.
Switching between:
- debugging only the main process (all documents, workers and priviledged JS)
- debugging all the processes (same, for each process, we will debug documents, workers, JS, ...)
This helps significantly speed up the browser toolbox when debugging only parent process resources,
while still allowing to switch to debug everything when required.
Depends on D146891
Differential Revision: https://phabricator.services.mozilla.com/D148527
This only fail on MBT because it still uses non-EFT
and the top level document is displayed in the iframe dropdown
via the old "listFrames/frameUpdate" codepath.
So that its frameData's id isn't related to a target actor
but rather to a frame of the parent-process/window-global target actor...
I'm adding test coverage for the regular web toolbox,
but the fix only reproduce in the context of the browser toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D148793
This add some minimal test coverage for the UI bits.
But more detailed test should rather be done around the TargetCommand API (browser_target_command_scope_flag.js).
Differential Revision: https://phabricator.services.mozilla.com/D149257
When passing an array, only booleans and number were accepted.
Also arrays were stringified to list of value coma separated,
as if arrays were refering to list of arguments.
That while passing a primitive value would be passed as a unique argument.
Clarify this by explicitely accepting arrays refering as list of argument,
or a primitive value being a unique argument.
I'm also fixing an issue with exceptions not being correctly reported.
Differential Revision: https://phabricator.services.mozilla.com/D149256
This introduces a checkbox in the iframe dropdown to enable/disable multiprocess debugging live.
Switching between:
- debugging only the main process (all documents, workers and priviledged JS)
- debugging all the processes (same, for each process, we will debug documents, workers, JS, ...)
This helps significantly speed up the browser toolbox when debugging only parent process resources,
while still allowing to switch to debug everything when required.
Differential Revision: https://phabricator.services.mozilla.com/D148527
The safe mode dialog will be displayed instead of the browser toolbox when the previous browser
toolbox has been closed too brutaly. This happens every now and then.
Also, when you opened a URL from the browser toolbox, this will then trigger a transient
browser window that appears and immediately disappear when opening the browser toolbox
all next time you start it. It might be related to session restore, but it looks like it is not enough
to get rid of this blinking window.
Differential Revision: https://phabricator.services.mozilla.com/D148515
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.
Differential Revision: https://phabricator.services.mozilla.com/D148128
We were instantiating one new Loader per DevToolsFrameChild instance.
This patch tries to share this loader with all the instances as well as share it
with the one used to load DevToolsServer when we are running in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D147257
In `viewSourceInStyleEditor`, we used to first load the styleeditor, and then
select the stylesheet and show the panel. This mean that when clicking on a location
from the rule view, there would be some delays before we show any feedback to the user.
Since the load promise for the panel only settles once we watched for all existing
stylesheets and loaded their content for each of them, it could take a while in
cases where we have lots of stylesheets, like in the BrowserToolbox.
So here we modify `viewSourceInStyleEditor` to directly select the styleeditor and
passing it a stylesheet that can be added right away, in case the panel wasn't
loaded yet, without waiting for the stylesheets to be watched.
We take this as an opportunity add a test when `viewSourceInStyleEditor` is called
with a stylesheet not used on the page, and check that it does open a view-source tab.
Differential Revision: https://phabricator.services.mozilla.com/D146540
The test was only waiting for addTab to resolve, waiting for the proper toolbox-ready event could reduce intermittent issues.
Differential Revision: https://phabricator.services.mozilla.com/D146530
I tried various approaches around the session restore, but this isn't reliable.
Using an environment variable is much easier and also help making the path global
for the whole instance in case we close and reopen it.
Differential Revision: https://phabricator.services.mozilla.com/D143695
You can run:
```
$ MOZ_BROWSER_TOOLBOX_PROFILER_STARTUP=1 ./mach run --jsdebugger
```
This will open a first browser toolbox for which we will record its startup.
Then, open a second browser toolbox, and open the recorded profile from its performance panel.
Differential Revision: https://phabricator.services.mozilla.com/D143567
This will help debug browser toolbox performance.
The performance panel displayed in the first browser toolbox is a bit pointless,
you better have to use the toolbar icon so that you avoid having all DevTools noise.
This enabling is actually mostly meant for the second browser toolbox you can open,
which will debug the first browser toolbox.
In this second browser toolbox, you will be able to record the first browser toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D143566
And pass a toolbox instead of only the toplevel target.
It helps identify the browser toolbox and easily enable/disable tools for it.
Differential Revision: https://phabricator.services.mozilla.com/D143628
Joel Maher
Nick Alexander
Emilio Cobos Álvarez
Hubert Boma Manilla
Nicolas Chevobbe
Iulian Moraru
Alexandre Poirot
Julian Descottes
criss
Tetsuharu Ohzeki
Tooru Fujisawa
Molnar Sandor
Michael Ratcliffe
Gabriele Svelto
Greg Tatum
Andreea Pavel