This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
In the ParentProcessStorage class, we are listening for window-global-created/destroyed
event to notify the client that hosts can be added/removed.
But in case of bfcache navigation, those events are not emitted.
In order to fix this issue, we forward pageshow and pagehide events from the
DevToolsFrameChild to the DevToolsFrameParent, where the watcher actor can emit
those events, which we'll be listened to by the ParentProcessStorage.
Test cases are added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D118325
This fixes an issue where when pausing in two distinct targets, and doing
a stepping, the debbuger tab highlight is still on when all the paused
thread have resumed.
The issue here is that the _pausedTargets count was not updated when a
step is done, so it goes out of sync.
Differential Revision: https://phabricator.services.mozilla.com/D119624
This step removes all the dependencies of mach commands to
having a MachCommandBase as the `self` by using the `command_context`
argument instead. This also removes any remaining statefulness from those
classes that implement mach commands, ultimately making it easier to move
existing commands out of classes in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D118058
The check from `shouldNotifyWindowGlobal` was only used from frame-target helper, from the parent process.
The only case it was filtering out was for browser toolbox watcher,
where we were filtering out tabs with about:blank loaded in a content process.
We weren't having any issues around about:blank with tab watchers.
I added test coverage for tab watchers, but they were already passing.
The check in DevToolsFrameChild was wrong with the browser toolbox codepath.
We don't have any browserId. This wasn't throwing because shouldNotifyWindowGlobal
was rejecting the about:blank documents.
This issue was catched by browser_console_content_object_in_sidebar.js,
which probably only involve about:blank documents.
Differential Revision: https://phabricator.services.mozilla.com/D117466
Worker targets only set threadActor late, quite asynchronously.
So that the target is registered in TargetCommand, but we can't call target.getFront
without having it to throw.
Differential Revision: https://phabricator.services.mozilla.com/D119672
ActorReadyGeckoProfilerInterface is used in two contexts:
- For the perf actor, which is used when the profiler is used from the
devtools Performance panel or via remote debugging (on about:debugging), and
- On about:profiling, which only exercises a subset of the interface's methods
because about:profiling does not have any UI for capturing profiles.
There are three other ways to capture profiles:
- The global browser keyboard shortcuts (implemented in DevToolsStartup.jsm)
- Clicking the toolbarbutton directly (implemented in popup/menu-button.jsm.js)
- Clicking the Capture button inside the popup (implemented in popup/panel.jsm.js)
These three other ways use functions in popup/background.jsm.js to capture the profile.
They do not call ActorReadyGeckoProfilerInterface.getProfileAndStopProfiler().
When the ActorReadyGeckoProfilerInterface instance for the perf actor is created,
we pass { gzipped: false }. Consequently, ActorReadyGeckoProfilerInterface.getProfileAndStopProfiler()
is only ever called with gzipped: false. So the option can be removed.
The other three ways to capture profiles, which use captureProfile in
popup/background.jsm.js, always get the gzipped profile because captureProfile
calls Services.profiler.getProfileDataAsGzippedArrayBuffer().
Differential Revision: https://phabricator.services.mozilla.com/D119561
Worker targets only set threadActor late, quite asynchronously.
So that the target is registered in TargetCommand, but we can't call target.getFront
without having it to throw.
Differential Revision: https://phabricator.services.mozilla.com/D119672
`beforeinput` event was shipped and it won't be disabled for avoiding confusion
of web developers. So, we can drop the pref setting of
"dom.input_events.beforeinput.enabled" in our tests.
Depends on D119716
Differential Revision: https://phabricator.services.mozilla.com/D119729
This fixes intermittent failures on browser_target_list_service_workers_navigation.js
that were appearing with the next patch on the queue (switching to dom-loading resource
in legacy service worker watcher).
Differential Revision: https://phabricator.services.mozilla.com/D119511
I don't think it was any useful to block synchronously on the call to `doResume`.
In the past it used to send an event to the client synchronously,
it may have been important back then.
test_nesting-03.js is still covering nested event loop by using two clients.
Differential Revision: https://phabricator.services.mozilla.com/D118173
Switches to the JavaScript stacks by default when capturing profile
with active tab view (with the "web developer" preset)
Also refactors previous ternary condition for better readability
Differential Revision: https://phabricator.services.mozilla.com/D119305
Previously, we worked with the assumption the NETWORK_STACKTRACE_EVENT resources will always
come before NETWORK_EVENT resources. Even though that's the order they are sent on the backend.
There is no gurantee when it comes through the resource watcher api, this becomes obvious with
server side target-switching on. Ideally there should not be dependency on the order. This patch
fixes that and fixes these 2 tests browser_net_initiator.js and browser_net_cause_source_map.js.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1717050#c0 and https://bugzilla.mozilla.org/show_bug.cgi?id=1717050#c3
for exact commands to run the tests
Differential Revision: https://phabricator.services.mozilla.com/D119494
The error message seems to be different in Nighly and Beta,
but I wasn't able to find any pref that is driving this.
Since the error message itself isn't super relevant, and given
that we're at the end of the cycle, this patch is only modifying
the expression so we get a different error.
Differential Revision: https://phabricator.services.mozilla.com/D119520
The selector that was used to not show toolbars in the console
input was also matching the codeMirror instance in the network
detail response tab. This is fixed by making the selector more
specific.
Differential Revision: https://phabricator.services.mozilla.com/D119192
It prevents having actions which are still pending when closing the toolbox.
Like `fetchScopes` when running browser_dbg-continue-to-here-click.js.
Differential Revision: https://phabricator.services.mozilla.com/D119388
Slow runtimes highlight race conditions explain in bugzilla comment 3,
which aren't trivial to address. So better disable this test on debug builds for now.
And at least keep it running on opt.
Differential Revision: https://phabricator.services.mozilla.com/D119323
Instead of manually replacing actorIDs in `getCleanedPacket`, we're introducing
a `replaceActorIds` option to `getSerializedPacket` that will replace all actorIDs
occurences with a fake one.
That way, we won't have to modify `getCleanedPacket` each time a new property is
added on a grip.
Depends on D119096
Differential Revision: https://phabricator.services.mozilla.com/D119167
Depends on D118474
This patch improves the inspector initialization in order to make it more resilient to race issues which can occur with watchTargets.
watchTargets might resolve before all targets have been processed, in case some targets become available after the watchTargets call already started.
After this patch, the inspector initialization flow should be easy to track from the init method:
- first we initialize the splitter (this is a mandatory first step before we attempt to create any other UI, including the markup view)
- then we watch for targets and resources
- when we receive the first root node resource, we initialize the markup view
- when watchResources resolves, the first root node should have been processed, the markup view is initialized and the various inspector fronts are also initialized
- finally we go back to init() and finish initializing the UI
Differential Revision: https://phabricator.services.mozilla.com/D118475
Depends on D118473
This changeset is purely moving code around. The various inspector initialization methods are spread all over inspector.js, which makes it difficult to follow.
Here we try to sort them more or less in the order in which they should be invoked.
Differential Revision: https://phabricator.services.mozilla.com/D118474
Dana Keeler
Alex Lopez
Alexandre Poirot
Nicolas Chevobbe
Hubert Boma Manilla
Sonia Singla
Fabien CASTERS
Butkovits Atila
Julian Descottes
Sebastian Zartner
Iulian Moraru
Markus Stange
Claudia
Tooru Fujisawa
Masayuki Nakano
Sam Foster
Marian-Vasile Laza
Md. Pial Ahamed
danfragoso
Jon Coppeard
Jonathan Kew