While we don't emit DOCUMENT_EVENT's for in-process iframes, each new target
will generate DOCUMENT_EVENT for the target's top level document.
So that the frontend do receive DOCUMENT_EVENT's for the remote iframes, in addition to the top level target document.
In most cases, we listen to will-navigate only to watch the top most top level document
and only this one, so we should only consider the top level target's DOCUMENT_EVENT.
As a side effect, we can re-enable browser_inspector_fission_frame_navigation.js which was failing because of this.
Differential Revision: https://phabricator.services.mozilla.com/D117184
We were calling ResourceCommand.watchResources from onTargetAvailable, whereas we could and should
call it once before or after calling TargetCommand.watchTargets.
Doing this helps calling watchResources only once, for all the resource types.
Also tweaked networkFront and responsiveFront instantiation.
to only instantiate them when we need them.
Differential Revision: https://phabricator.services.mozilla.com/D116983
This helps track all navigations, including the cross process navigation
and navigation with JSWindowActor based targets.
With work from bug 1702511, this also helps clearing at the precise right time.
Differential Revision: https://phabricator.services.mozilla.com/D115818
This helps clearing the netmonitor it all navigation, including the cross process navigation
and navigation with JSWindowActor based targets.
With work from bug 1702511, this also helps clearing at the precise right time.
Note that nothing special is being done for the initial document request,
but if we need to we can use NETWORK_EVENT's isNavigationRequest boolean
to help make it work.
Differential Revision: https://phabricator.services.mozilla.com/D116032
* Stop memoizing web console front
* track navigations via DOCUMENT_EVENT's dom-complete
* await for HarAutomation async initialization from toolbox codebase
These changes help fix browser_harautomation_simple.js.
But this isn't enough as will-navigate can easily be missed.
Differential Revision: https://phabricator.services.mozilla.com/D114464
This introduces uncessary complexity and makes it uterly complex to wait
for HarAutomation's async initialization.
Its init isn't async yet.
Differential Revision: https://phabricator.services.mozilla.com/D114837
All these get* methods were hosted on WebConsole fronts,
but weren't related to WebConsole actor.
Instead they all target the NetworkEvent actors.
These actors runs in the parent process, where we listen for network requests.
Going through console fronts were an issue during target switching
as there is a small window in between the previous and new target where
there is no webconsole front being alive. The previous's page one is destroyed
and the new page's one is not yet available.
All that while the network event actors are always available.
We could only remove these get* methods once we refactor all tests still using them.
Also it would be great to followup and stop having one actor per request,
and instead fetch these attributes via the network-parent actor.
By doing this, we could finaly drop the last usage of DevToolsClient.request and make _requestData much simplier.
Differential Revision: https://phabricator.services.mozilla.com/D114538
A preview for fonts is added to the Response view of the Netmonitor. This view displays the name and MIME type of the font and generates a preview for it.
If no preview can be created, a hint is shown to the user. This is the case when the font isn't used within the page when generating the preview. For example, this is the case when loading the font via the Font Loading API.
Depends on D110167
Differential Revision: https://phabricator.services.mozilla.com/D110169
This property does nothing since bug 315209 got implemented.
Every single user that I checked was doing the same math by hand, so
hooray for good defaults :-)
Differential Revision: https://phabricator.services.mozilla.com/D112253
A preview for fonts is added to the Response view of the Netmonitor. This view displays the name and MIME type of the font and generates a preview for it.
If no preview can be created, a hint is shown to the user. This is the case when the font isn't used within the page when generating the preview. For example, this is the case when loading the font via the Font Loading API.
Depends on D110167
Differential Revision: https://phabricator.services.mozilla.com/D110169
A preview for fonts is added to the Response view of the Netmonitor. This view displays the name and MIME type of the font and generates a preview for it.
If no preview can be created, a hint is shown to the user. This is the case when the font isn't used within the page when generating the preview. For example, this is the case when loading the font via the Font Loading API.
Depends on D110167
Differential Revision: https://phabricator.services.mozilla.com/D110169
A preview for fonts is added to the Response view of the Netmonitor. This view displays the name and MIME type of the font and generates a preview for it.
If no preview can be created, a hint is shown to the user. This is the case when the font isn't used within the page when generating the preview. For example, this is the case when loading the font via the Font Loading API.
Depends on D110167
Differential Revision: https://phabricator.services.mozilla.com/D110169
A preview for fonts is added to the Response view of the Netmonitor. This view displays the name and MIME type of the font and generates a preview for it.
If no preview can be created, a hint is shown to the user. This is the case when the font isn't used within the page when generating the preview. For example, this is the case when loading the font via the Font Loading API.
Differential Revision: https://phabricator.services.mozilla.com/D110169
Depends on D110368
Both the flag and the event are not used.
The only thing which matters from the framework perspective is to wait for panel.open to resolve.
Differential Revision: https://phabricator.services.mozilla.com/D110369
Move the methods of the targetCommand that were related to targetConfiguration
to a dedicated command.
We also move the custom TargetConfigurationFront methods into the command.
Callsites are modified to use the new command. Doing so for the debugger involved
a bit more work as we needed to pass the command to the existing `setupCommands`
bootstrap function.
Differential Revision: https://phabricator.services.mozilla.com/D110200
The test previously depended on the position of the blocked request
in the request list view, This causes the test to fail intermittently
when the list is out of order.
This fix instead finds the request using the name in the url which is
more consistent.
Differential Revision: https://phabricator.services.mozilla.com/D109497
I kept a few having some overrides. But they may be irrelevant.
And I kept some eslint files for all folder that aren't matching the pattern matching "**/test*/**/browser*/".
Ideally we would rename these folder to match.
Last but not least, I identified one case where we were using mochitest file for xpcshell tests!
Differential Revision: https://phabricator.services.mozilla.com/D109481
This change unifies the different colors of splitters used within the different panels.
"Splitter" here referes to a thin (usually one pixel wide) line between different items in the UI. It does not mean borders around items.
Differential Revision: https://phabricator.services.mozilla.com/D105682
Depends on D106002
The goal is to reduce the usage of the getToolbox(target) API.
It feels like exposing toolbox on the connector should be a more straightforward way of achieving the same thing?
Differential Revision: https://phabricator.services.mozilla.com/D106032
Depends on D105999
This patch is mostly a mechanical rewrite of:
```lang=javascript
const target = await TargetFactory.forTab(tab);
const toolbox = await gDevTools.showToolbox(target, "inspector");
```
to
```lang=javascript
const toolbox = await gDevTools.showToolboxForTab(tab, { toolId: "inspector" });
```
The main changes are:
- if the target was actually used in the test, it is now retrieved from toolbox.target
- the arguments for showToolboxForTab are using an option argument, to avoid the occasional showToolbox("inspector", null, null, null, startTime, null, reason);
I suspect that any signature rewrite mistake would have been caught on try.
There a few less mechanical changes:
- devtools/client/framework/test/browser_toolbox_screenshot_tool.js the toolId "console" was omitted because this id doesn't match any tool (author probably meant "webconsole")
- a few tests were: 1/ first creating a target, 2/ looping on tool definitions to get supported tools 3/ opening the toolbox with each supported tool. To support this I extracted a helper called `getSupportedToolIds` which opens a temporary toolbox to list all supported tool ids
- all the tests under storage/ use a single helper to start the test, which can open toolboxes for both tab targets and other targets. This made it more complicated to refactor. We could also drop this part and just refactor each test when we actually modify forTab/showToolbox to only work with descriptors
All in all the goal of this stack is to pave the way to stop handling targets when using forTab/showToolbox, and behind the scenes stop replying on targets to cache open toolboxes. We don't aim to kill all the call sites, just get them to a smaller number so that the next refactors will be easier.
Differential Revision: https://phabricator.services.mozilla.com/D106000
Depends on D106002
The goal is to reduce the usage of the getToolbox(target) API.
It feels like exposing toolbox on the connector should be a more straightforward way of achieving the same thing?
Differential Revision: https://phabricator.services.mozilla.com/D106032
Depends on D105999
This patch is mostly a mechanical rewrite of:
```lang=javascript
const target = await TargetFactory.forTab(tab);
const toolbox = await gDevTools.showToolbox(target, "inspector");
```
to
```lang=javascript
const toolbox = await gDevTools.showToolboxForTab(tab, { toolId: "inspector" });
```
The main changes are:
- if the target was actually used in the test, it is now retrieved from toolbox.target
- the arguments for showToolboxForTab are using an option argument, to avoid the occasional showToolbox("inspector", null, null, null, startTime, null, reason);
I suspect that any signature rewrite mistake would have been caught on try.
There a few less mechanical changes:
- devtools/client/framework/test/browser_toolbox_screenshot_tool.js the toolId "console" was omitted because this id doesn't match any tool (author probably meant "webconsole")
- a few tests were: 1/ first creating a target, 2/ looping on tool definitions to get supported tools 3/ opening the toolbox with each supported tool. To support this I extracted a helper called `getSupportedToolIds` which opens a temporary toolbox to list all supported tool ids
- all the tests under storage/ use a single helper to start the test, which can open toolboxes for both tab targets and other targets. This made it more complicated to refactor. We could also drop this part and just refactor each test when we actually modify forTab/showToolbox to only work with descriptors
All in all the goal of this stack is to pave the way to stop handling targets when using forTab/showToolbox, and behind the scenes stop replying on targets to cache open toolboxes. We don't aim to kill all the call sites, just get them to a smaller number so that the next refactors will be easier.
Differential Revision: https://phabricator.services.mozilla.com/D106000
The accordion widget inside the response view of the Network Monitor got replaced by a simple headline with a toggle button at the end.
Differential Revision: https://phabricator.services.mozilla.com/D103839
Depends on D104424
performReload is not a regular configuration option as it is not persisted.
It is rather a flag for a single call to Target::reconfigure.
As we move configuration options outside of the target, it will be easier to drive the reload from the frontend.
The call sites using performReload are quite rare and only found in the netmonitor so it doesn't feel like this
requires a framework solution for now. We add explicit calls to TargetFront::reload() in spots where the netmonitor
used to pass performReload = true.
Differential Revision: https://phabricator.services.mozilla.com/D104891
Depends on D104423
Same as for isJavascriptEnabled in the previous patch.
With the upcoming Configuration actor, updating the configuration should not be on target-scoped API.
Moving the `reconfigure` API to TargetList reduces the required refactors for the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D104424
The test is split in two to make it easier to read.
The test was quite old and still had references to the Params panel, which is
now removed.
The test was also failing when checking the stacktrace, and this was due to an
issue from the webconsole messsage reducer where we would completly replace
the `networkMessagesUpdateById` on NETWORK_MESSAGES_UPDATE, and that would lead
to the stracktrace being removed.
In the Stacktrace component, we prevent fetching the stacktrace if it's already
available.
Differential Revision: https://phabricator.services.mozilla.com/D56884
The test is split in two to make it easier to read.
The test was quite old and still had references to the `Params` panel, which was
renamed to `Request`.
The test was also failing when checking the stacktrace, and this was due to an
issue from the webconsole messsage reducer where we would completely replace
the `networkMessagesUpdateById` on NETWORK_MESSAGES_UPDATE, and that would lead
to the stracktrace being removed.
In the Stacktrace component, we prevent fetching the stacktrace if it's already
available.
Differential Revision: https://phabricator.services.mozilla.com/D56884
This creates a new devtools/client/shared/test-helpers folder in which we add
a share jest config, which define a `moduleNameMapper` option with all the
different fixtures that were used in the codebase.
The fixtures were moved from different panels to a jest-fixtures folder and
the one that were left unused are removed.
Some fixtures file needed to be modified to satisfy eslint rules.
Differential Revision: https://phabricator.services.mozilla.com/D99470
Disabling browser_net_block-csp.js as it fails with fission enabled.
Bug 1682153 details the issue, and the test would be enabled when this
bug is fixed.
Differential Revision: https://phabricator.services.mozilla.com/D99626
This also removes pref overrides from methods like LocaleService::IsLocaleRTL or
IntlService.getLocaleInfo, because it doesn't really make sense to override the
result of checking an arbitrary locale, the relevant use case is overriding the
result for the current app locale.
Removal of the intl.uidirection pref completely will be done in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D96235
Add a needed top-level error boundary component to the Net Monitor panel
in DevTools, to catch errors that would otherwise render the pane blank.
Differential Revision: https://phabricator.services.mozilla.com/D91511
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Merge `thunk-with-options` behavior directly into `thunk`, update `thunk` and `thunk-with-options` callsites and finally remove now unused `thunk-with-options` (as well as netmonitor's own `thunk`)
Depends on D92888
Differential Revision: https://phabricator.services.mozilla.com/D93195
In short, thunk actions are changing from a signature with 2 parameters (dispatch and getState): `(dispatch, getState)`, to an object that contains those properties: `({ dispatch, getState })`.
This is done so we can merge thunk and thunk-with-options
Differential Revision: https://phabricator.services.mozilla.com/D92888
We should register the resource listeners only once.
ResourceWatcher will automatically handle re-registering the per-target listener for us.
Differential Revision: https://phabricator.services.mozilla.com/D92550
Because of this, in netmonitor stubs tests, the resource objects ends up loosing
"intermediate" state and now contains all information that we gathered by the time
we emit throttled resources.
The only way to address that would be to do an archived copy of each resource state,
but I don't think we want to do that...
Differential Revision: https://phabricator.services.mozilla.com/D89628
Sebastian Zartner
Claudia
Nicolas Chevobbe
Alexandre Poirot
Noemi Erli
Hubert Boma Manilla
Ashray
Olli Pettay
Sandor Molnar
Brindusan Cristian
Alexandru Michis
Emilio Cobos Álvarez
Csoregi Natalia
Butkovits Atila
Jon Bauman
Narcis Beleuzu
Larissa
Julian Descottes
Tim Nguyen
Yura Zenevich
Dimi Lee
Kartik Gautam
Cosmin Sabou
Dorel Luca
Florent Viard
Andreea Pavel
Dan Minor
Itiel
Cody Welsh
Neil Deakin
Ricky Stewart
Bogdan Tara
Ben Delevingne
Razvan Maries
Kershaw Chang
Farooq AR
Christoph Kerschbaumer
Daisuke Akatsuka
Sonia Singla
Dev Singh