Devtools can generate fetch request on behalf of the content document,
reporting these requests in PerformanceObserver would cause confusion,
so we should ignore them.
Differential Revision: https://phabricator.services.mozilla.com/D162582
There's only one worrying timeout
(css/css-contain/container-queries/inline-size-bfc-floats.html), but it
isn't a "hard" hang, but an invalidation loop.
Let's enable this by default on nightly to get some feedback while we
work on it and the remaining issues that block enabling them by default.
Differential Revision: https://phabricator.services.mozilla.com/D162292
Depends on D162193
This adds only very basic tests for the observer, but I would like to discuss about switching the API to a fully event-based solution.
I initially decided against it because I didn't want to create unnecessary changes for DevTools, but in the end, the owner pattern is quite verbose if
we want to use it for testing. Having events instead would make it more flexible, we could test only what we are interested in, with minimal overhead.
If we agree on this, we can land those very simple tests and I can move on to change the API to use events and update the tests, before we add more
tests.
Differential Revision: https://phabricator.services.mozilla.com/D162195
While writing a test, I forgot that the filter function was an "ignore" function. Using named arguments should avoid this. Maybe we should
consider using a regular filter approach (ie return true if we want to keep the request)?
Differential Revision: https://phabricator.services.mozilla.com/D162193
We had a number of tests that assumed that when adding a browser_action without
specifying the default_area, that the button would enter the navbar. The previous
patch in this series changes that assumption when the Unified Extensions UI is
enabled.
Instead of updating all of these tests to add additional steps to move the
browser_action's out to the navbar after adding them, I've gone ahead and
updated them to default their browser_action's to the navbar instead.
Differential Revision: https://phabricator.services.mozilla.com/D161721
This reduces the weird interactions that can appear on menus.
This also progresses BiDi support, including for accesskeys.
Differential Revision: https://phabricator.services.mozilla.com/D161498
This patch
- Clears the `_mapsById` map when clearing all state.
- Fix bug introduced during fission work which stops from clearing any of the states at all. `isTopLevel` no longer
exists on the `resource`, rather we can get that from the `targetFront`.
Differential Revision: https://phabricator.services.mozilla.com/D161677
This rule is still a massive hack. Also doesn't work on Shadow DOM, and
I'd rather remove it... But this should fix the assertion.
Differential Revision: https://phabricator.services.mozilla.com/D161778
So it looks like triggering the query container tooltip also shows the highlighter,
and then, later, in another function, we do assert the highlighter behavior.
Since we didn't planned for the first highlighter, we might end up in an unexpected
state.
The fix is to wait for the highlighter to be displayed (and then hidden) in the
function checking the tooltip.
Differential Revision: https://phabricator.services.mozilla.com/D161758
Depends on D161319
The filters & shouldIgnoreChannel arguments feel redundant and make the class harder to reuse outside of devtools, because the filters we currently accept are very much tied to devtools logic. If we switch the filtering logic to only use the shouldIgnoreChannel callback, any consumer can decide of the logic to filter out events.
We could then try to share filters between devtools and bidi, but for now simplifying the signature seems reasonable.
Differential Revision: https://phabricator.services.mozilla.com/D161320
Depends on D161318
The owner property of the NetworkObserver has 2 roles:
- it provides 2 callbacks: onNetworkEvent and shouldIgnoreChannel
- it is used for null checks to know if the NetworkObserver was already destroyed
For the first item we switch to 2 explicit arguments. For the second item, we add a private `#isDestroyed` flag.
With this, the only `owner` left in this codebase, is the network event owner, which would also be nice to remove.
Note that for now I am still keeping a "callback" approach for "onNetworkEvent" rather than emitting an event from NetworkObserver. The reason behind this is that we expect `onNetworkEvent` to return the network event's owner, and this cannot be cleanly emulated with an event-based approach. Maybe further down the road we can fully switch to events, but as an intermediary step this would make things harder to understand.
Differential Revision: https://phabricator.services.mozilla.com/D161319
Depends on D161317
There are 3 different "owner" in the network observer codebase:
- the network observer's owner
- the network events' owners
- the network response listener's owner
The last one is really just always the parent NetworkObserver instance, so let's make it clear and rename this `owner` accordingly
Differential Revision: https://phabricator.services.mozilla.com/D161318
Depends on D161315
NetworkObserver was already a class, but it was not yet using private properties. This makes it more difficult to refactor, as you don't really know what is used outside of the file.
Differential Revision: https://phabricator.services.mozilla.com/D161316
Depends on D161494
In this bug, if we fix the original issue, the markupview will start rendering a property value with the base64 for the image, but the text is so long that the markup view becomes unusable both from a UX perspective (node is way too tall) and from a performance perspective (resizing the markupview triggers reflow which freeze the browser for a very long time).
Differential Revision: https://phabricator.services.mozilla.com/D161559
This patch is only moving all network observer files in the same folder.
For webdriver reviewers, we could update our phabricator herald rule to be added as reviewers for changes in this folder?
Differential Revision: https://phabricator.services.mozilla.com/D160241
This used to be a node package. Let's make it become regular commonjs devtools modules.
This will make it trivial to migrate this to ES Modules.
Also possibly make this code become the unique layer in m-c on top of the source-map package.
We no longer use webpack to build the two bundles (index.js and worker.js),
instead, we are using the toolkit worker loader (require.js) in order to load
all this code without any build step.
As this is no longer a node package, I removed node-specific modules (assertRoot/wasmAsset)
and simplify the definition of wasm file URIs as they are now fixed.
Also moving the debugger to load internal "devtools/client/shared/source-map/source-map.js"
module in jest as running the Web Worker instantiated by source-map/index.js is too complex.
Differential Revision: https://phabricator.services.mozilla.com/D159115
For now, it was vendored by a manual run to webpack from the debugger folder (node bin/bundle.js).
Ship a more explicit bundle of it, next to all other already existing vendored files.
$ git clone git@github.com:mozilla/source-map.git
$ cd source-map/
$ git checkout 0.8.0-beta.0
$ rm -rf .git/
/!\ lib/read-wasm.js has been edited and need to be preserved/rebased /!\
$ hg/git add source-map.js LICENCE lib/
Also, hopefully temporarily vendor whatwg-url:
$ git clone git@github.com:jsdom/whatwg-url.git
$ cd whatwg-url/
$ npm install
$ npm run build
$ npm run build-live-viewer
$ cp live-viewer/whatwg-url.js ..
$ hg/git add whatwg-url.js
and also temporarily replace source-map/lib/url.js with source-map/lib/url-browser.js
And edit this file to do:
module.exports = require("devtools/client/shared/vendor/whatwg-url").URL;
Hopefully, we can remove whatwg-url dependency and remove all this.
Differential Revision: https://phabricator.services.mozilla.com/D159113
The MD5 file is being updated via:
$ wget https://github.com/pvorb/node-md5/archive/refs/tags/v2.3.0.tar.gz
$ tar zxvf v2.3.0.tar.gz
$ cd node-md5-2.3.0/
=> here edit webpack.config.js to set `libraryTarget: "umd"`
$ yarn webpack
$ cp dist/md5.min.js ../md5.js
$ cd ..
$ rm -rf v2.3.0.tar.gz node-md5-2.3.0
Vendor it in m-c, so that it can be used as a regular module
and not bundled via WebPack.
Differential Revision: https://phabricator.services.mozilla.com/D159112
This patch adds a tooltip that is displayed when the user hovers a `@container`
declaration in the rule view.
The tooltip displays the query container that is used for this rule and the selected
node and the computed values of its `containerType`, `inlineSize` and `blockSize`
(if the `containerType` is `size`) properties.
The title attribute is removed on the `ruleview-rule-ancestor-data` items as it
was not playing well with the new tooltip. The styling for those element is
modified so they are never cropped so we can see the whole text (and don't need
the title anymore).
A test case is added to make sure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D161129
