Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
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
Ricky Stewart
Bogdan Tara
Dorel Luca
Kris Maglione
Jason Laster
Noemi Erli
Andreea Pavel
Julian Descottes
Narcis Beleuzu
Emilio Cobos Álvarez
Gabriel Luong
Razvan Caliman
Daniel Varga
Patrick Brosset
Brad Werth
Victor Porof
Brian Hackett
Ian Moody
arthur.iakab
Michael Ratcliffe
Cosmin Sabou
Mark Banner
Boris Zbarsky
Belén Albeza
Blake Kaplan