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 webplatform test runner recently added an option to open devtools during their tests.
The current implementation relies on TargetFactory::forTab and gDevTools::showToolbox.
Those methods will most likely change as we move away from targets and start using descriptors.
See previous WPT PR at https://github.com/web-platform-tests/wpt/pull/27309
Differential Revision: https://phabricator.services.mozilla.com/D105740
With Bug 1688813 drawSnapshot will handle fixed element, so we don't have to do
it from DevTools code.
We can remove this._lastScrollPosition in the screenshotContentActor, which means
we can also get rid of captureDone, which was only used to set the original scroll
position back.
Differential Revision: https://phabricator.services.mozilla.com/D106065
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 webplatform test runner recently added an option to open devtools during their tests.
The current implementation relies on TargetFactory::forTab and gDevTools::showToolbox.
Those methods will most likely change as we move away from targets and start using descriptors.
See previous WPT PR at https://github.com/web-platform-tests/wpt/pull/27309
Differential Revision: https://phabricator.services.mozilla.com/D105740
This wasn't needed and could introduce unnecessary delays, so we do all the calls
at the same time and then await for all the calls to be settled.
Differential Revision: https://phabricator.services.mozilla.com/D105944
If there was multiple concurrent calls to listStores, only the last one made would
resolve, the other one would be stuck indefinitely.
This was caused by the call to indexedDb actor `preListStores` method, in which
the `hostVsStores` is reset to an empty Map. So if there was still a previous
pending call, one of the promise who was relying on an entry being in `hostVsStores`
would never resolve.
To prevent this, we cache the pending promise when calling `preListStores` so any
concurrent calls would wait for the same promise.
A test is added to make sure we don't regress in the future.
Differential Revision: https://phabricator.services.mozilla.com/D105943
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
For making the test framework/API change easier, such raw API shouldn't be
used directly. Therefore, this patch makes tests using it directly stop
using it and use `synthesizeNativeMouseEvent` instead.
However, this patch does not fix `browser_touch_event_iframes.js` because
it accesses the API from `ContentTask`. So, `EventUtils.js` isn't available
without larger change.
Note that this patch disables `test_bug596600.xhtml` because as I commented
in it, it's completely broken. It depends on the race of next native event
loop and `waitForTick`, and this patch changes the result of the race.
Differential Revision: https://phabricator.services.mozilla.com/D105765
Currently, it takes a raw native message value, but it makes JS content too
complicated. And on Linux, it cannot synthesize non-primary button events
because GDK has only button press and release messages which dont' include
mouse button information.
For solving these problems, this patch creates a new abstract native message
as `nsIWidget::NativeMouseMessage` and makes each widget converts it to
a platform native message.
Additionally, this patch adds an argument to make it possible its callers
to specify pressing or releasing mouse button with a DOM mouse button value.
Note that the following patch adds new argument to
`synthesizeNativeEventMouse*` for mochitests and which will be tested by
new tests.
Differential Revision: https://phabricator.services.mozilla.com/D105763
### Story
When a COOP+COEP page is opened, we change the remoteness of the tab. After
changing the remoteness, the tab is then restored by its TabState. However,
we haven't collected userContextId through the current mechanism.
To fix that, this patch changes the way to collect userContextId.
### Test Plan
Test: D98296
Depends on D98296
Differential Revision: https://phabricator.services.mozilla.com/D98468
* onResourceListAvailable and populateStorageTree were both computing distinct dictinary. `storages` versus `this.storageResources` (with the resourcesWithHosts making them both differents). It is easier to follow if we have only one dictionary, build by onResourceListAvailable and that's the straight object given by the ResourceWatcher API.
* Since we migrated to resources API. `resources` object passed to onResourceAvailable
should no longer have any `from` attribute. This is no longer a RDP packet, but an array computed by the ResourceWatcher API.
* This isn't really useful to filter out resources with empty `hosts` because `populateTreeFromResource` will be a noop
if that's empty. I think it is easier to follow if we pass all the resources to this method.
Differential Revision: https://phabricator.services.mozilla.com/D105646
This variable name was confusing and didn't help understand the great complexity of this object.
This is a dictionary of storage resources, which also happen to be fronts, keyed by storage type/key (string).
Differential Revision: https://phabricator.services.mozilla.com/D105645
Resource updates and destroyed were ignored because the singleton storage resource
was cleaned on will-navigate.
So, we instead revert back to listen to events on fronts.
But instead of listening to a unique event on storageFront,
we listen to each individual storage resource front (one per type and per target).
This is why we have to do some filtering, still. Both on legacy listener and Watcher classes.
I'm also clarfifying things a bit in ContentProcessStorageWatcher,
I forked StorageActor completely, while removing its protocol.js Actor inheritance
and some stuff that we don't need for the Watcher class.
This help emitting stores-updated and stores-cleared and reuse the exact same
code between legacy listener and watcher class regarding filtering.
Differential Revision: https://phabricator.services.mozilla.com/D104687
This patch fixes the existing test that was flawed, checking if messages weren't
displayed too early, so messages didn't have the time to be rendered.
When checking later, we can see that the messages were displayed when they
shouldn't have been.
Depends on D105945
Differential Revision: https://phabricator.services.mozilla.com/D105972
The missing resource-available-form event on content process target specifications
break console resources for content process targets.
Adding this event will probably create duplicate and so requires some more analysis.
Differential Revision: https://phabricator.services.mozilla.com/D105945
Remove references to flow in build files.
This effectively stop stipping flow from debugger modules.
So any leftover would now start being kept in production file and do an error.
Differential Revision: https://phabricator.services.mozilla.com/D105330
This matches closer what Chrome and Safari do (Safari paints outside of
the box when this happens, but the layout box still respects the
author), see:
data:text/html,<button style="padding: 0; width: 0">
data:text/html,<input type=checkbox style="width: 0">
Etc. For checkboxes, this matches what OSX does, too.
Since we still want checkboxes to be slightly larger than what they'd be
otherwise, we add a hook to tweak it when non-native theme is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D105798
We had failure in tests calling TestActor `getEyeDropperColorValue` method as
we were getting an empty string back.
I couldn't reproduce, but I suspect that it can happen that even if the element
is visible, the text isn't rendered yet somehow.
To fix this issue, we wait until we do get a non empty string for the color-value
element.
Differential Revision: https://phabricator.services.mozilla.com/D105582
The test was assuming that resources are coming in a constant order, which is not
the case. We use find to retrieve the resource we want instead.
There was another weird intermittent with the media query induced resource update
not being triggered. It looks like the resourceId that was used, a simple count
increment, could lead to duplicate ids that would mess with the other methods
of the watcher. Including the target actorID in the resourceId seems to fix the issue.
Differential Revision: https://phabricator.services.mozilla.com/D105722
It should also not be displayed for the browser toolbox.
I messed up strings with the initial landing:
- wrong event name used in browser.js (no dynamic update)
- wrong flag passed from BT launcher (stripes show up when BT is used)
Sorry about that
Differential Revision: https://phabricator.services.mozilla.com/D105666
There is still some usages in isTargetSupported,
but that would requires refactoring this method into isDescriptorSupported
and be async as some isTargetSupported only works against target as it checks for traits on it.
Differential Revision: https://phabricator.services.mozilla.com/D105201
The ChromeWindowTargetActor was not exposed to end users and doesn't support descriptors which will make it a blocker for fission refactors.
So we remove it for now.
Differential Revision: https://phabricator.services.mozilla.com/D105452
Use the correct menu item ID to insert the "Page Source" menu item before the
"Extensions for Developers" menu item in the DevTools menu.
Differential Revision: https://phabricator.services.mozilla.com/D105485
