Remove devtools/shared/layout/utils.js isNativeAnonymous/isAnonymous and switch
callsites to directly use node.isNativeAnonymous getter.
On the client rename isAnonymous into isNativeAnonymous so it's consistent
with the platform implementation.
Differential Revision: https://phabricator.services.mozilla.com/D271553
We used to compute the pseudo element name (e.g. `::before`, `::marker`, …) in a
few places, both on the server and the client.
This patch does it directly from `getNodeDisplayName`, which is called for assigning
the NodeActorForm displayName.
We also use `getNodeDisplayName` in `getBindingElementAndPseudo` to avoid duplicating
code.
On the client we now use displayName in the few places we used to re-construct
the pseudo element text in (markup view, breadcrumb, rules view, …)
We also no longer pass "individual" pseudo element booleans (e.g. `isAfterPseudoElement`)
in the NodeActor form, but a more generic `isPseudoElement` one so it's easier
to handle future pseudo element (e.g. `::view-transition`).
And we take this as an opportunity to remove the utility functions that we were
using to build those properties, and instead switch to look into `Node.implementedPseudoElement`
to detect when we do handle pseudo elements.
Differential Revision: https://phabricator.services.mozilla.com/D271002
We used to compute the pseudo element name (e.g. `::before`, `::marker`, …) in a
few places, both on the server and the client.
This patch does it directly from `getNodeDisplayName`, which is called for assigning
the NodeActorForm displayName.
We also use `getNodeDisplayName` in `getBindingElementAndPseudo` to avoid duplicating
code.
On the client we now use displayName in the few places we used to re-construct
the pseudo element text in (markup view, breadcrumb, rules view, …)
We also no longer pass "individual" pseudo element booleans (e.g. `isAfterPseudoElement`)
in the NodeActor form, but a more generic `isPseudoElement` one so it's easier
to handle future pseudo element (e.g. `::view-transition`).
And we take this as an opportunity to remove the utility functions that we were
using to build those properties, and instead switch to look into `Node.implementedPseudoElement`
to detect when we do handle pseudo elements.
Differential Revision: https://phabricator.services.mozilla.com/D271002
This is a simple version for now, showing a non-interactive `container` badge
for elements with `container-type` of `size` or `inline-size` (`style` isn't
supported yet).
Differential Revision: https://phabricator.services.mozilla.com/D156567
This will help transition to ES Modules as this symbol is exposed to them.
$ sed -ie "/require(.ChromeUtils.)/d" $(git grep -l 'require("ChromeUtils")' devtools/)
$ sed -ie "/loader.lazyRequireGetter(this, .ChromeUtils./d" $(git grep -l 'loader.lazyRequireGetter(this, "ChromeUtils"' devtools/)
+ the edition of builtin-modules.js + eslintrc.js + manual eslint fixes
Differential Revision: https://phabricator.services.mozilla.com/D156402
This will help transition to ES Modules as this symbol is exposed to them.
$ sed -ie "/require(.Services.)/d" $(git grep -l 'require("Services")' devtools/)
$ sed -ie "/loader.lazyRequireGetter(this, .Services./d" $(git grep -l 'loader.lazyRequireGetter(this, "Services"' devtools/)
+ the edition of builtin-modules.js + eslintrc.js
+ manual eslint fixes
+ removal of devtools-services in the debugger, except for jest tests
Differential Revision: https://phabricator.services.mozilla.com/D156401
`getAllSelectors` was used to retrieve a given nodeFront selector from the top
window (e.g. it would go up through documents).
This doesn't work with nodeFronts in remote frames, as we wouldn't be able to
reach for cross-process parent documents.
This patchs adds a new inspector command that computes the selector, reaching the
different documents.
All usages of `NodeFront#getAllSelectors` are switched to the new command, which
allows us to delete the method and another function that was only used there.
With the new command doing a bit more work, this highlighted some issue in our
codebase. Some consumers were relying on `selectionCssSelectors`, without waiting
for it to be updated when a new node was selected.
As a result a few tests were failing because of this.
So where it's possible and not perf critical, we simply compute the selector again.
We also emit a new event, `selection-css-selectors-updated`, so tests can wait
until it's properly set before doing further actions.
Differential Revision: https://phabricator.services.mozilla.com/D127928
The change in the NodeFront caused one test to fail. Switching getLongString function
to an async function fixes the test (and makes it easier to read).
Depends on D127077
Differential Revision: https://phabricator.services.mozilla.com/D127078
As explained in the bug, the test test_inspector-dead-nodes.html exercises an edge case which is probably irrelevant now.
It aimed to check that you could call APIs on target scoped fronts during target reload.
Eg, get the children of a node, while you reload a page. However with SSTS, we now destroy the target, so all fronts are destroyed.
This test should probably be migrated to a commands test, and we should define what should be the behavior of such a command during reload.
However in its current shape the test is doing the following:
- get walkerFront1 and nodeFront1 for target1
- reload the page
- wait for the new target target2 and get walkerFront2
- call walkerFront2.children(nodeFront1)
- check there are no errors
This call doesn't really make sense however. walkerFront2 and nodeFront1 are fronts from different targets and nodeFront1 is already destroyed. Here it happens to crash when trying to use a getter on nodeFront1 and it would be nicer to not throw anyway, hence the proposed fix.
But the test should still be reviewed.
Differential Revision: https://phabricator.services.mozilla.com/D123138
This turns all existing backward compatibility comments (or
comments mentioning a specific Firefox version), into the new
syntax we agreed upon in Bug 1673535.
Differential Revision: https://phabricator.services.mozilla.com/D97395
This patch completely removes the `HighlighterActor` and its accessors.
The rest of the patches in this commit series update the consumers and tests to use the new highlighter manager added to `HighlightersOverlay` in D81526. [Bug 1646028](https://bugzilla.mozilla.org/show_bug.cgi?id=1646028) updated all consumers within the **Inspector** panel to use this approach. Now, we're updating the rest of the consumers outside the Inspector.
### Why remove HighlighterActor?
The changes introduced in D81526 for [Bug 1646028](https://bugzilla.mozilla.org/show_bug.cgi?id=1646028) make it possible to highlight nodes using the `CustomHighligtherActor` with the **Box Model Highlighter** implementation.
The `HighlighterActor` was itself a wrapper around **Box Model Highlighter** and Simple Outline Highlighter, and exposed node picking functionality. Simple Outline Highlighter was removed with [Bug 1650094](https://bugzilla.mozilla.org/show_bug.cgi?id=1650094). The node picking functionality was decoupled from `HighlighterActor`in [Bug 1607756](https://bugzilla.mozilla.org/show_bug.cgi?id=1607756).
After those changes, `HighlighterActor` is no longer special. It can be removed in favor of a single generic actor, `CustomHighligtherActor`, with the Box Model Highlighter implementation.
Differential Revision: https://phabricator.services.mozilla.com/D92220
This patch completely removes the `HighlighterActor` and its accessors.
The rest of the patches in this commit series update the consumers and tests to use the new highlighter manager added to `HighlightersOverlay` in D81526. [Bug 1646028](https://bugzilla.mozilla.org/show_bug.cgi?id=1646028) updated all consumers within the **Inspector** panel to use this approach. Now, we're updating the rest of the consumers outside the Inspector.
### Why remove HighlighterActor?
The changes introduced in D81526 for [Bug 1646028](https://bugzilla.mozilla.org/show_bug.cgi?id=1646028) make it possible to highlight nodes using the `CustomHighligtherActor` with the **Box Model Highlighter** implementation.
The `HighlighterActor` was itself a wrapper around **Box Model Highlighter** and Simple Outline Highlighter, and exposed node picking functionality. Simple Outline Highlighter was removed with [Bug 1650094](https://bugzilla.mozilla.org/show_bug.cgi?id=1650094). The node picking functionality was decoupled from `HighlighterActor`in [Bug 1607756](https://bugzilla.mozilla.org/show_bug.cgi?id=1607756).
After those changes, `HighlighterActor` is no longer special. It can be removed in favor of a single generic actor, `CustomHighligtherActor`, with the Box Model Highlighter implementation.
Differential Revision: https://phabricator.services.mozilla.com/D92220
Depends on D85599
The WalkerActor is currently responsible for watching navigations and exposes them to the client.
However, this is communicated to the client differently depending on what kind of frame navigates.
If the top frame of the target navigates, this will be exposed via the watchRootNode API (onDestroyed/onAvailable callbacks will be triggered)
If an inner frame navigates, mutations will be emitted: "frameLoad"/"documentUnload" + a fake "childList" mutation.
On the client side, we have to handle both very similarly which leads to some duplication.
Also "frameLoad"/"documentUnload" are one of the last "immediateMutations" which usually means they should not have been mutations in the first place.
The goal here is to use the watchRootNode API for all frames.
Differential Revision: https://phabricator.services.mozilla.com/D84973
Now that the BrowsingContextTarget are created by the watcher,
we should redirect existing code in the frontend which was using
`RootFront.getBrowsingContextDescriptor` in order to directly fetch the target from the watcher.
We don't really need descriptors for additional targets.
I think that descriptors are mostly useful for the top level target and for about:debugging, to describe a target without debugging it yet.
This patch is a bit complex because we can't fetch the "parent BrowsingContext ID" from actors/browsing-context.js:form().
browsingContext.parent and browsingContext.embedderWindowGlobal are both null from the content process.
I have not found any way/API to get the parent browsing context ID from the content process, i.e. the ID of browser.xhtml from a tab content process.
So, I end up with this helper method on Watcher actor to get the parent ID on-demand.
We could also inject the parent ID into the browsingContextTarget's form in WindowGlobalWatcher._createTarget,
but that sounds very hacky and hard to follow.
Note that this patch address the issue of duplicated targets.
WatcherFront.getBrowsingContextTarget ensures fetching the ParentProcessTarget for browser.xhtml
instead of recreating a duplicated FrameDescriptor and BrowsingContextTarget for this document, as we do in the existing codebase.
Differential Revision: https://phabricator.services.mozilla.com/D62465
Nicolas Chevobbe