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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
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
--HG--
extra : moz-landing-system : lando
This gives a very noticable increase in speed. When Brad finishes https://bugzil.la/1523336 we can stop walking the DOM and simply use `parentFlexElement` and `parentGridElement`.
Differential Revision: https://phabricator.services.mozilla.com/D18674
--HG--
extra : moz-landing-system : lando
This fixes the issue but because of our virtual canvas implementation and the
fact that reflow events are batched there is quite a bit of flicker and some
drag (see attached video).
Unfortunately, until bug 1509071 is implemented (full screen canvas using
`position:fixed`) we can't really do anything about the flicker... I suppose we
could stop batching reflow events but that would make all of our highlighters
unusably slow.
Differential Revision: https://phabricator.services.mozilla.com/D16988
--HG--
extra : moz-landing-system : lando
- Added AutoRefreshHighlighter flag to AutoRefreshHighlighter. This ensures that getQuads() ignores the zoom factor.
Differential Revision: https://phabricator.services.mozilla.com/D7599
--HG--
extra : moz-landing-system : lando
doc.getAnonymousNodes no longer returns shadow dom nodes, so no need
to filter them out in isXBLAnonymous.
This feature is tested in browser_markup_anonymous_02.js so reenabling
this test.
toolbarbutton has 4 children now, but since our tests are no longer
running in non-e10s, the regression was missed!
MozReview-Commit-ID: BHYb5ufyQjg
--HG--
extra : rebase_source : bb933452d3780fa1c632240314014ad9c605c52a
This leaves getAdjustedQuads alone because it lives in its own world and its
result gets sent over IPC. That leaves things in a bit of an intermediate
state, but that should be OK for now.
MozReview-Commit-ID: DH6eGqCFhPr
--HG--
extra : rebase_source : 39feed5868c86a104e586f40bd1e80e8f8f34e0b
The writing mode / RTL adjustments performed by `getWritingModeMatrix` needs the
element's content size without margins, borders, or padding.
MozReview-Commit-ID: LsSfNN4fyDR
--HG--
extra : rebase_source : 2c98d6ad0ee7593d542d84e64b65332a6917c7a5
These issues were previously ignored due to the nature of our global import
rules. They need to be fixed before that rule can be updated.
MozReview-Commit-ID: DCChktTc5TW
--HG--
extra : rebase_source : cffb1c9762191c579d1397c8169e6e7635d229da
extra : histedit_source : dea59ddd2daaae52069c5faceae9149a4f08dd73
Use the getBoxQuads's relativeTo option to avoid having to calculate the offset
due to frames.
Also reduce the precision of numbers used when checking if the highlighter is
correctly displayed.
Finally, for some strange reasons, this patch seems to cause a totally unrelated
events mutation event to be sent during the test. This polutes the mutations
received and made the test fail. So I filtered the list of mutations to only
preserve the ones we care about here.
I could not reproduce this extra mutation when running Firefox. Only during the
test. So I did not investigate further.
MozReview-Commit-ID: 1ZQ6FGULjHG
--HG--
extra : rebase_source : 6406571849afb1d3dcec176f68ef4d3d122a1abf
Adjust the grid outline in the Inspector's Layout panel as needed to match the
writing mode and text direction of the grid container.
MozReview-Commit-ID: Ggcp1e4ZipE
--HG--
extra : rebase_source : e9acadc8837ad3c05c038a2156272c9eff8c7330