This cache might keep destroyed windowUtils helpers in some scenarios involving navigations with a process change.
The regular getter is slightly slower, but the performance hit should not be noticeable.
Differential Revision: https://phabricator.services.mozilla.com/D220785
What devtools wants to do is ignoring the website-specific zoom.
It seems KDE 5.27 on X11 uses the text scale factor to implement scaling
of GTK apps completely (including Firefox), rather than the global
integer GTK scaling combined with it.
This makes this difference way more obvious than it otherwise would.
Differential Revision: https://phabricator.services.mozilla.com/D170195
What devtools wants to do is ignoring the website-specific zoom.
It seems KDE 5.27 on X11 uses the text scale factor to implement scaling
of GTK apps completely (including Firefox), rather than the global
integer GTK scaling combined with it.
This makes this difference way more obvious than it otherwise would.
Differential Revision: https://phabricator.services.mozilla.com/D170195
This will help transition to ES Modules as we won't be able to expose a magic "chrome" ESM.
Also, most of these symbols are exposed as global already.
All but:
* `components` which is `Components`,
* `CC` which is `Components.Constructor`,
* `Cm` which is `Components.manager`.
$ sed -ie "/require(.chrome.)/d" $(git grep -l 'require("chrome")' devtools/)
+ manual edits for all three exceptions
Differential Revision: https://phabricator.services.mozilla.com/D156936
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
We do create dedicated targets for frame documents, but
in isFrameWithChildTarget, we were only checking if the
passed element was an iframe, making some area of the code
not behaving correctly (e.g. using the node picker, or
the Inspect Element context menu entry).
This patch fixes this and add a test case to make sure we
don't regress.
Differential Revision: https://phabricator.services.mozilla.com/D140041
The function was returning true as long as the passed element
was an iframe and EFT was enabled.
But if the passed iframe was blocked by a CSP rule, it would
still return true, although we wouldn't actually have a dedicated
document, nor a target, for that iframe, which would lead to
issues in the inspector when trying to fetch the iframe children.
We fix this by adding a new `isFrameBlockedByCSP` util, which uses
`nsIContentPolicy#shouldLoad` with the iframe url so we can check if the iframe
is blocked by CSP, and in such case, return false.
We're also using this new function in the `NodeActor#form` method to set a `numChildren`
of `0` when the iframe is blocked (so in the inspector, the expand icon will be
hidden for the element), as well as in `WalkerActor#_getChildren` to return an
empty array when called with an iframe blocked by CSP.
A new test is added to check the iframe nodeFront properties and usage of
`WalkerFront#children` with those. We allow to set a specific pref to bypass
the guard in the children method in order to properly check that the root issue
of a given bug was fixed.
Differential Revision: https://phabricator.services.mozilla.com/D137667
With Fission enabled, hovering the padding area of an iframe would not cause the
iframe element to be highlighted.
That's because we were deliberately ignoring any event on remote frames, as we
thought the sub-document picker would take care of this.
We fix this by only checking if the event was fired on a window managed by the
target actor.
An existing test is modified to make it a Fission test case, and a few helper
for highlighterTestFront had to be modified.
Differential Revision: https://phabricator.services.mozilla.com/D126472
With Fission enabled, hovering the padding area of an iframe would not cause the
iframe element to be highlighted.
That's because we were deliberately ignoring any event on remote frames, as we
thought the sub-document picker would take care of this.
We fix this by only checking if the event was fired on a window managed by the
target actor.
An existing test is modified to make it a Fission test case, and a few helper
for highlighterTestFront had to be modified.
Differential Revision: https://phabricator.services.mozilla.com/D126472
This removes the concept of shadowAnonymous, which doesn't make a lot of sense,
and re-enables the shadow dom tests which were disabled when we removed the old
style system (as stylo didn't supported shadow DOM yet by then).
This is a change in behavior as you can now remove nodes from shadow DOM (no
reason you weren't able to, before).
Differential Revision: https://phabricator.services.mozilla.com/D53340
Depends on D47092
Given that the highlighter rendering surface is sized to the viewport of the inspected page (as opposed to the whole document), we need a way to ignore scroll offsets when getting data about the node position so the highlighter doesn't get drawn off-screen.
Differential Revision: https://phabricator.services.mozilla.com/D47094
Depends on D47092
Given that the highlighter rendering surface is sized to the viewport of the inspected page (as opposed to the whole document), we need a way to ignore scroll offsets when getting data about the node position so the highlighter doesn't get drawn off-screen.
Differential Revision: https://phabricator.services.mozilla.com/D47094
The original plan for the node-picker to work with multiple targets was introduced in D41598 (in bug 1568825). The idea was that, because we can have multiple independent inspectable targets, and because the client is the one doing the orchestration between them, to let the client start the node picker in all targets at once.
At the time of this first change, the code was create with this in mind, but there was really just one target (the top-level one).
So, this revision introduces the real code for this. First of all, I removed the now obsolete `getAllInspectorFronts` in `node-picker.js` because we now have a similar function on the inspector front directly.
Then the main code changes to look for are on the actor side, in the `HighlighterActor`. This is where the picking actually happens.
You have to remember that several targets will be picking at the same time, and therefore several `HighlighterActor` instances will be in pick mode at the same time.
The way they allow users to pick is by listening to mouse events (mousemove and clicks essentially).
Because these actors can't see or talk to each other, one can't tell the others that the mouse is now over its content and the other pickers should pause somewhat.
So, when one of them sees that the mouse event is happening on a remote frame, then it bails out and lets events through without handling them. This is so that the embedded document (which also has a picker running) can get a chance to receive the mouse events too.
The other aspect is that each `HighlighterActor`, when picking, does its own highlighting. So if there are 3 remote frames, then there really are 3 highlighters.
So the trick is to make sure only one of them ever appears at any given time. Again, these actors can't talk to each other directly, so the client is responsible for doing this when receiving events that a node was hovered.
This is not perfect, but should normally get far better when the new fission-compatible highlighter is in place. Indeed, when that happens, we won't have to care about this anymore, there will be only one `HighlighterRenderer` for the entire tab. So even if there are multiple `HighlighterActor` instances picking, they will all be sending events to the same renderer.
The only exception is in the browser toolbox where you can inspect both the browser UI and the content UI. In this case, there will be 2 renderers: one over the entire browser window, and one over the <browser> area. So we'll still have to do the dance of hiding one when the other is shown.
Differential Revision: https://phabricator.services.mozilla.com/D42640
Depends on D46957
We are updating three call sites that were still relying on window.top to get the topmost window.
For `getFrameOffsets` and `getRect`, they are currently only called with a non-null `boundaryWindow` argument.
That's why this didn't trigger any regression.
For `getFrameElement`, I could only find STRs that don't have any user impact.
For instance, when the BrowserToolbox debugs a page where you open DevTools, this will load the toolbox in an iframe.
This load will trigger `onFrameLoad` in the walker actor. And because we were using `win.top`, getFrameElement would return null, and onFrameLoad will not emit mutations.
But I couldn't see any scenario where this had an actual impact for users.
Differential Revision: https://phabricator.services.mozilla.com/D46958
Julian Descottes