Unbind the ArrowLeft and ArrowRight keys in the request list and messages list, keeping only ArrowUp and ArrowDown, to be consistent with tree navigation and more predictable in RTL UI layout.
Differential Revision: https://phabricator.services.mozilla.com/D49457
--HG--
extra : moz-landing-system : lando
This adds a color scheme simulation toggle button in the rules view,
which will toggle between 4 different states: default, dark, light,
and no-preference.
This feature is currently hidden away under a preference:
devtools.inspector.color-scheme-simulation.enabled
The final UI/UX still needs to be figured out, however, this initial step is
to land the ability to prototype this feature.
Differential Revision: https://phabricator.services.mozilla.com/D49833
--HG--
extra : moz-landing-system : lando
The change to await snapshotWindow is something that should have been
done in Bug 1573254.
Differential Revision: https://phabricator.services.mozilla.com/D47510
--HG--
extra : moz-landing-system : lando
This helper function awaits the new custom event sent by the RDM pane
frame script when zooming is done, then waits for the reflow to be
complete also. After this is done, resolution and window and content
sizes all have their correct, final values.
Differential Revision: https://phabricator.services.mozilla.com/D47366
--HG--
extra : moz-landing-system : lando
The ZoomChild actor normally caches its full zoom level only when it is
changed, then emits a FullZoomChange event. That event causes problems
with Responsive Design Mode, which receives the event after other
similar events that carry the full zoom level of the RDM pane content.
The RDM UI pane itself always stays at 1.0 zoom. This change makes the
ZoomChild cache its initial fullZoom level as soon as possible, which
prevents the first RDM zoom change from sending the unwanted event.
Differential Revision: https://phabricator.services.mozilla.com/D49793
--HG--
extra : moz-landing-system : lando
This change makes the RDM content frame script listen to the new
PreFullZoomChange event, and treat that as a trigger to save the
existing resolution. The content window will send 2 resize events
as it adjusts to the new RDM pane size set by the front end. After
these events are received, the resolution is restored and a new
event is fired that indicates the work of zooming is complete.
Differential Revision: https://phabricator.services.mozilla.com/D48624
--HG--
extra : moz-landing-system : lando
This adds a color scheme simulation toggle button in the rules view,
which will toggle between 4 different states: default, dark, light,
and no-preference.
This feature is currently hidden away under a preference:
devtools.inspector.color-scheme-simulation.enabled
The final UI/UX still needs to be figured out, however, this initial step is
to land the ability to prototype this feature.
Differential Revision: https://phabricator.services.mozilla.com/D49833
--HG--
extra : moz-landing-system : lando
The race isn't trivial to reproduce and the test do not reproduce it.
But this was making target list tests to fail.
Differential Revision: https://phabricator.services.mozilla.com/D48856
--HG--
extra : moz-landing-system : lando
The accessibility panel is calculating the height of some of its containers by doing 100vh - toolbar height.
But the accessibility panel was relying on a local variable --accessibility-toolbar-height which was actually not used to set the height of the toolbar.
So when the toolbar height increased of 1px, all those calculations became wrong.
The --accessibility-toolbar-height is now the same as --theme-toolbar-height so I propose to remove the local variable and only use the devtools one.
Differential Revision: https://phabricator.services.mozilla.com/D50291
--HG--
extra : moz-landing-system : lando
This should make it more obvious what kind of document
the component is expecting.
Differential Revision: https://phabricator.services.mozilla.com/D50240
--HG--
extra : moz-landing-system : lando
This test is relying on a profiler feature that is not available in every
platform. This patch changes it to use the "js" feature, which should be
supported everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D49948
--HG--
extra : moz-landing-system : lando
DEBUG_JS_MODULES will make the BrowserLoader load different versions of some React files.
This confuses our metrics test that checks against duplicated modules and relies on a strict whitelist.
We fail the test explicitly since this performance metrics test should really only be run without DEBUG modules.
Differential Revision: https://phabricator.services.mozilla.com/D50160
--HG--
extra : moz-landing-system : lando
This value isn't really used, nevertheless it's good to have it to the
right value for documentation reason and consistency.
Differential Revision: https://phabricator.services.mozilla.com/D49643
--HG--
extra : moz-landing-system : lando
This also renames various variables from "settings" to "preferences" to
make it clearer that the values are about actual preferences stored in
the user profile.
Differential Revision: https://phabricator.services.mozilla.com/D49641
--HG--
extra : moz-landing-system : lando
Expose the Gecko Profiler feature "nostacksampling" as "No Periodic Sampling".
Differential Revision: https://phabricator.services.mozilla.com/D49231
--HG--
extra : moz-landing-system : lando
We have a few CodeMirror instances where we're using the default line height (`line-height: normal`), resulting in a line-height in the 13-14.5px range (depending on the font, OS, resolution). By contrast, the Debugger uses 15px explictly, and that's a style we're trying to generalize.
This patch sets a 15px line-height for:
- Inspector: the CodeMirror instance used in the markup view for "Edit as HTML" and in event tooltips
- Style Editor: the main editor instance
- Console: the jsterm but only in editor mode (since the output uses a 14px line-height on purpose, the jsterm in standard mode keeps this 14px line-height to minimize visual jumps when sending a command)
Differential Revision: https://phabricator.services.mozilla.com/D49593
--HG--
extra : moz-landing-system : lando
Where possible I ported tests to use the shadow DOM. The following could
potentially be ported, but don't think it worth of it:
test_bug414907.xul - uses children nodes in constructor which is very
different in shadow DOM world
test_bug233643.xul - really tests XBL behavior
test_anonymous_content.py - bug on file already to create shadow DOM
test from scratch
Differential Revision: https://phabricator.services.mozilla.com/D49341
--HG--
rename : devtools/client/inspector/test/browser_inspector_highlighter-xbl.js => devtools/client/inspector/test/browser_inspector_highlighter-custom-element.js
extra : moz-landing-system : lando
This function is used in several locations and at least two files, so
it's useful to have it exist as a named and exported function.
Differential Revision: https://phabricator.services.mozilla.com/D49945
--HG--
extra : moz-landing-system : lando
Some panels, like the debugger, might handle both nodeFronts and grips
at the same time, so there's no way to know ahead of time which kind
of object we're going to deal with.
This patch remove the isGrip parameter, and perform a check on the
passed object to see if it's a nodeFront instance or not.
Differential Revision: https://phabricator.services.mozilla.com/D49399
--HG--
extra : moz-landing-system : lando
The object-client.js file is now a proper protocol.js front,
but is still named after a client.
This is confusing, so we rename and move the file next to other
fronts, and update all consumers to the new terminology.
Differential Revision: https://phabricator.services.mozilla.com/D49878
--HG--
rename : devtools/client/debugger/packages/devtools-reps/src/object-inspector/tests/__mocks__/object-client.js => devtools/client/debugger/packages/devtools-reps/src/object-inspector/tests/__mocks__/object-front.js
rename : devtools/shared/client/object-client.js => devtools/shared/fronts/object.js
extra : moz-landing-system : lando
test_adb.js is likely failing because the socket is still in use.
Refactor the code to exit ASAP, by ungracefully exiting adb.py.
This logic is also used by the actual adb binary:
727b07b260/adb/adb.cpp (1039)
Differential Revision: https://phabricator.services.mozilla.com/D49864
--HG--
extra : moz-landing-system : lando
The focus previous element function needed to be modified
in order to not find non-visible elements.
Differential Revision: https://phabricator.services.mozilla.com/D49729
--HG--
extra : moz-landing-system : lando
The rotate property is only enabled on Nightly.
For beta, we need to use transform: rotate instead.
Differential Revision: https://phabricator.services.mozilla.com/D49847
--HG--
extra : moz-landing-system : lando
This is where it should have been in the first place. Those attributes belong there.
Differential Revision: https://phabricator.services.mozilla.com/D49577
--HG--
extra : moz-landing-system : lando
Using cmd+F in the Console/Debugger after using the inspector will be caught by inspector code and will not show the panel's search ui.
Differential Revision: https://phabricator.services.mozilla.com/D49756
--HG--
extra : moz-landing-system : lando
The previous condition didn't fully check that the grid node was previously a subgrid.
So, we run into a scenario where we refresh the page and a "display-change" event is hit
after a new root is loaded, and the grid highlighter is restored and hidden because
the check will pass as long as the node is a grid container.
Differential Revision: https://phabricator.services.mozilla.com/D49659
--HG--
extra : moz-landing-system : lando
Depends on D49711
I was a bit confused but we just forgot to remove this in Bug 1548465
Differential Revision: https://phabricator.services.mozilla.com/D49716
--HG--
extra : moz-landing-system : lando
When starting to resize, we store the direction of the
controlled element in the state.
When resizing, we check the current element direction
to set the appropriate width to the controlled element.
A test is added to ensure the resizer works as expected
in RTL languages elements.
Differential Revision: https://phabricator.services.mozilla.com/D49719
--HG--
rename : devtools/client/shared/components/test/mochitest/test_GridElementWidthResizer.html => devtools/client/shared/components/test/mochitest/test_GridElementWidthResizer_RTL.html
extra : moz-landing-system : lando
Since we want the button to be placed on the right side
in RTL languages and we don't have logical properties
on background-position yet, we display the icon in
a :before pseudo element which will adapt for both LTR
and RTL languages. The icon is then mirrored in RTL.
Differential Revision: https://phabricator.services.mozilla.com/D49718
--HG--
extra : moz-landing-system : lando
We remove the pseudo elements we were using to draw the borders and
put them on the grid elements instead.
We make the GridElementResizer 6px and translate it so there's
handle on "both sides" of the splitter.
Differential Revision: https://phabricator.services.mozilla.com/D45302
--HG--
extra : moz-landing-system : lando
We retrieve the right NodeFront from a given grip, which we
can then tell the inspector panel to select.
Differential Revision: https://phabricator.services.mozilla.com/D48810
--HG--
extra : moz-landing-system : lando
This allow us to retrieve the appropriate nodeFront from a grip,
and thus the right highlighterFront to highlight a given element.
We also need to cache the highlighter front used for the current
highlight, as we need to use the same front for unhighlighting,
and this saves us a few server round-trip to get the right front.
Differential Revision: https://phabricator.services.mozilla.com/D48809
--HG--
extra : moz-landing-system : lando
A function is added on the walker actor that creates a NodeFront
from a ContentDomReference, e.g. an object containing a browsingContextId
and a unique DOM element identifier.
A trait is added on the walker actor since the ContentDomReference API was
only added in Firefox 69.
We then add a function on the toolbox that can return a NodeFront from a
element grip.
Differential Revision: https://phabricator.services.mozilla.com/D48808
--HG--
extra : moz-landing-system : lando
This will allow us to retrieve the appropriate inspector
(and thus walker, highlighter, ...) for a given element
later, potentially from a different DebuggerServer.
Differential Revision: https://phabricator.services.mozilla.com/D48807
--HG--
extra : moz-landing-system : lando
The function was close to hit the complexity limit set by eslint,
so we break it up into smaller functions.
We also group assignments where we can.
Differential Revision: https://phabricator.services.mozilla.com/D48806
--HG--
extra : moz-landing-system : lando
- Converted the ObjectClient into an protocoljs Front
- Converted the SymbolIteratorClient into a protocoljs Front and moved it to devtools/shared/fronts
- Converted the PropertyIteratorClient into a protocoljs Front and moved it to devtools/shared/fronts
- Converted the EnvironmentClient into a protocoljs Front and moved it to devtools/shared/fronts
- Modified calls to `DebuggerClient.release()` so that it tries to call the ObjectFront's release method first, and falls back on `DebuggerClient.release()` if there's no object front
- Changed reps so that it instantiates only one ObjectClient per grip
- Changed tests so that they expect what the Front's request method resolves to where applicable (i.e. ObjectFront.allocationStack resolves to allocationStack, not a packet object with an allocationStack property)
- Changed callbacks provided to ObjectClient methods to be chained to the ObjectFront methods (e.g. ObjectClient.getScope(callback) changed to ObjectFront.getScope().callback())
- Changed tests to use async/await (test_framebindings-x.js, test_functiongrips-x.js, test_objectgrips-x.js)
- Changed tests to expect protocoljs to throw an error string instead of an error object (test_objectgrips-fn-apply-03.js, test_threadlifetime-02.js, test_pauselifetime-03.js)
Differential Revision: https://phabricator.services.mozilla.com/D48182
--HG--
rename : devtools/shared/client/environment-client.js => devtools/shared/fronts/environment.js
rename : devtools/shared/client/property-iterator-client.js => devtools/shared/fronts/property-iterator.js
rename : devtools/shared/client/symbol-iterator-client.js => devtools/shared/fronts/symbol-iterator.js
extra : moz-landing-system : lando
Apply the following optimizations:
- Don't use regular expressions where they can be avoided
- Reduce unnecessary memory allocations (e.g. avoid doing a map and a filter by writing the code in an imperative fashion)
- Reduce layout trashing by using `rAF` and `setTimeout`
- Perform cheaper checks first in conditional statements
See commit messages for more details.
Differential Revision: https://phabricator.services.mozilla.com/D49214
--HG--
extra : moz-landing-system : lando
The webconsole actor now has an associated front for some
time, but the naming of variables and properties didn't
reflect that (most weren't updated and were still calling
it a client).
This patch tries to rename all those variables so it's more
obvious we're dealing with an actual front.
Differential Revision: https://phabricator.services.mozilla.com/D49401
--HG--
extra : moz-landing-system : lando
The format of the Fenix versionName on Nightly no longer matches our regular expression.
Updating the regular expression to accommodate both versions such as "2.1.0" and "Nightly 191016 06:01"
Differential Revision: https://phabricator.services.mozilla.com/D49428
--HG--
extra : moz-landing-system : lando
- Converted the ObjectClient into an protocoljs Front
- Converted the SymbolIteratorClient into a protocoljs Front and moved it to devtools/shared/fronts
- Converted the PropertyIteratorClient into a protocoljs Front and moved it to devtools/shared/fronts
- Converted the EnvironmentClient into a protocoljs Front and moved it to devtools/shared/fronts
- Modified calls to `DebuggerClient.release()` so that it tries to call the ObjectFront's release method first, and falls back on `DebuggerClient.release()` if there's no object front
- Changed reps so that it instantiates only one ObjectClient per grip
- Changed tests so that they expect what the Front's request method resolves to where applicable (i.e. ObjectFront.allocationStack resolves to allocationStack, not a packet object with an allocationStack property)
- Changed callbacks provided to ObjectClient methods to be chained to the ObjectFront methods (e.g. ObjectClient.getScope(callback) changed to ObjectFront.getScope().callback())
- Changed tests to use async/await (test_framebindings-x.js, test_functiongrips-x.js, test_objectgrips-x.js)
- Changed tests to expect protocoljs to throw an error string instead of an error object (test_objectgrips-fn-apply-03.js, test_threadlifetime-02.js, test_pauselifetime-03.js)
Differential Revision: https://phabricator.services.mozilla.com/D48182
--HG--
rename : devtools/shared/client/environment-client.js => devtools/shared/fronts/environment.js
rename : devtools/shared/client/property-iterator-client.js => devtools/shared/fronts/property-iterator.js
rename : devtools/shared/client/symbol-iterator-client.js => devtools/shared/fronts/symbol-iterator.js
extra : moz-landing-system : lando
Enforced Title Case on all the labels listed in the bug description for all panels except the Debugger.
Differential Revision: https://phabricator.services.mozilla.com/D49109
--HG--
extra : moz-landing-system : lando
The sourceId is then used in the various places where we call the sourcemap service.
A test is added in the console to make sure that we do navigate to the mapped
location in the debugger.
Differential Revision: https://phabricator.services.mozilla.com/D49103
--HG--
extra : moz-landing-system : lando
The function had the wrong argument parameters, and it wasn't
fetching the latest list of objdirs.
Differential Revision: https://phabricator.services.mozilla.com/D49006
--HG--
extra : moz-landing-system : lando
You can listen for fronts creation via `parentFront.onFront(typeName, callback)`.
For now, we were calling `callback` before we pass the `form` to Front.
This leads to empty attributes as the Front doesn't have access to any data.
Differential Revision: https://phabricator.services.mozilla.com/D49261
--HG--
extra : moz-landing-system : lando
I thought I would contribute to this test.
As it doesn't involve any child actor, I'm not, but this cleanup is still valuable.
Differential Revision: https://phabricator.services.mozilla.com/D49260
--HG--
extra : moz-landing-system : lando
Move analyzeInputString function below JSPropertyProvider, so
the exported function appears first in the file.
Differential Revision: https://phabricator.services.mozilla.com/D49107
--HG--
extra : moz-landing-system : lando
We always have a debugee for the eval window, so we can
remove the now unnecessary check.
We also take this as an opportunity to always attach the
thread when attaching the console in devtools/shared/webconsole/test/common.js
as it's what makes the evalWindow a debuggee.
Differential Revision: https://phabricator.services.mozilla.com/D49105
--HG--
extra : moz-landing-system : lando
- Use tabular numbers in search input message to reduce layout shifts that impact the loader icon
- Use new highlight colors in search results
- Use standard code font-family (platform-dependent) and font-size (11px); change result row height to 18px (from 16px)
- Add row hover background color, similar to Network request list
- And a few more spacing tweaks
Differential Revision: https://phabricator.services.mozilla.com/D49091
--HG--
extra : moz-landing-system : lando
The inline start border on hover is now unnecessary
since we have block borders.
Some properties are tweaked to ensure everything is
still lined up properly.
Differential Revision: https://phabricator.services.mozilla.com/D48148
--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
NOTE: To use the new box model highlighter, flip this pref to true: `devtools.inspector.use-new-box-model-highlighter`
Adding Julian as reviewer to check the sanity of the communication system (see `BoxModelHiglighterObserver` constructor and `BoxModelHighlighterRenderer.setMessageManager()`, `BoxModelHighlighterRenderer.onMessage()`, `BoxModelHighlighterRenderer.postMessage()`) and Patrick for the overall highlighter behavior which is mostly a clean split of the existing [`BoxModelHighlighter`](https://searchfox.org/mozilla-central/rev/f43ae7e1c43a4a940b658381157a6ea6c5a185c1/devtools/server/actors/highlighters/box-model.js)).
---
Depends on D47091
## Preamble
This patch looks more frightening than it actually is. Let me explain:
The vast majority of the code in `box-model-highlighter-observer.js` and `box-model-highlighter-renderer.js` is a clean split of the code existing in `box-model-highlighter.js` into distinct parts which handle the node measurement (observer) and the drawing the highlighter (renderer). I kept the method names identical to help in matching them up with their original sources.
There was no simple way chunk this without confusing the daylight out of you so I decided to co-locate all changes so it's easier to track and reference methods.
I will detail below the important differences.
## Overview:
The box model highlighter is split into two distinct parts:
- an observer which monitors the node's position
- a renderer which draws the highlighter on top of the node
The renderer always lives in the parent process (browser window) and overlays an iframe with the highlighter markup:
- either over the content if highlighting in the context of the content toolbox
- or over the whole browser UI if highlighting in the context of the browser toolbox
When in the context of the browser toolbox (i.e. highlighting the browser UI), both observer and renderer live in the parent process. Communication is done by direct calls.
When in the context of the content toolbox (i.e. highlighting the page content), the observer lives in content process (so it can measure the node) while the renderer lives in the parent process. Communication is done by message passing via `MessageManager` (soon to be deprecated and replaced with JSWindowActor API)
## Notable differences after the split
- the observer checks whether it is in the content process (aka child process) and sets up the highlighter in the parent process by using [`setupInParent()`](https://docs.firefox-dev.tools/backend/actor-e10s-handling.html) and establishes a communication system to it via message manager. If the observer is in the parent process (browser toolbox scenario), the renderer is setup directly via its constructor and no additional communication system is required.
- whenever the node quads change (as determined by the untouched existing base class `auto-refresh.js`), the observer gathers the data about the node position and sends it over to the renderer. This happens in the `BoxModelHighlighterObserver._update()` (corresponding to the [`_update()` from the existing highlighter](https://searchfox.org/mozilla-central/rev/45f30e1d19bde27bf07e47a0a5dd0962dd27ba18/devtools/server/actors/highlighters/box-model.js#361-383)).
- the renderer expects its `render()` method to be called with the necessary node position information whenever it should update the highlighter. It is the entry point which then calls all the DOM manipulation methods copied over from the existing box model highlighter.
- the only notable change in DOM manipulation methods is in `BoxModelHighlighterRenderer._updateBoxModel()` (corresponding to [`updateBoxModel()` from the existing highlighter](https://searchfox.org/mozilla-central/rev/45f30e1d19bde27bf07e47a0a5dd0962dd27ba18/devtools/server/actors/highlighters/box-model.js#504-560)) where the `_nodeNeedsHighlighting()` is kept on the observer part and the canvas zoom adjustment is removed (`this.markup.scaleRootElement(this.currentNode, rootId)`) because the canvas is no longer influenced by the page zoom (the canvas lives in the browser window, not the content window)
Differential Revision: https://phabricator.services.mozilla.com/D47092
--HG--
rename : devtools/server/actors/highlighters/box-model.js => devtools/server/actors/highlighters/box-model-renderer.js
extra : moz-landing-system : lando
**Update October 8**
To use the new box model highlighter, flip this pref to true:
`devtools.inspector.use-new-box-model-highlighter`
---
Adding Julian as reviewer to check the sanity of the communication system and Patrick for the overall highlighter behavior.
---
This patch adds a base class for the renderer part of highlighters which is set up on the parent process in the browser window.
This is used by the `BoxModelHighlighterRender` introduced by D47092
`HighlighterRenderer.init()` will create an HTML iframe and inject it to the appropriate position in the browser window in order to serve as a rendering surface for highlighters of the inspected page content (content toolbox) or the browser UI (browser toolbox). A host iframe is used until [Bug 1492582](https://bugzilla.mozilla.org/show_bug.cgi?id=1492582) is fixed because the browser window is XUL and does not support the anonymous canvas frame used by existing highlighters.
The primary use case of `HighlighterRenderer` is as a base class for renderers which live in a separate process than the observers. This happens with highlighters for the content toolbox. Therefore, it provides methods to setup a communication system (via MessageManager for now) whereby the observer can send messages to the renderer and vice-versa: `setMessageManager()`, `postMessage()` and `onMessage()`.
I used the existing code from [`AccessibilityParent`](https://searchfox.org/mozilla-central/source/devtools/server/actors/accessibility/accessibility-parent.js) as a reference for this.
Classes that extend HighlighterRenderer must implement:
- a typeName representing the highlighter type; used to differentiate between other types of messages when the Message Manager is used;
- a _buildMarkup() method to generate the highlighter markup;
- a `render()` method to update the highlighter markup when given new information about the observed node.
NOTE: A temporary pink outline is set on the highlighter surface as a quick visual check to show its extent depending on context: browser toolbox or content toolbox. This will be removed before landing.
Differential Revision: https://phabricator.services.mozilla.com/D47091
--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
NOTE: To use the new box model highlighter, flip this pref to true: `devtools.inspector.use-new-box-model-highlighter`
Adding Julian as reviewer to check the sanity of the communication system (see `BoxModelHiglighterObserver` constructor and `BoxModelHighlighterRenderer.setMessageManager()`, `BoxModelHighlighterRenderer.onMessage()`, `BoxModelHighlighterRenderer.postMessage()`) and Patrick for the overall highlighter behavior which is mostly a clean split of the existing [`BoxModelHighlighter`](https://searchfox.org/mozilla-central/rev/f43ae7e1c43a4a940b658381157a6ea6c5a185c1/devtools/server/actors/highlighters/box-model.js)).
---
Depends on D47091
## Preamble
This patch looks more frightening than it actually is. Let me explain:
The vast majority of the code in `box-model-highlighter-observer.js` and `box-model-highlighter-renderer.js` is a clean split of the code existing in `box-model-highlighter.js` into distinct parts which handle the node measurement (observer) and the drawing the highlighter (renderer). I kept the method names identical to help in matching them up with their original sources.
There was no simple way chunk this without confusing the daylight out of you so I decided to co-locate all changes so it's easier to track and reference methods.
I will detail below the important differences.
## Overview:
The box model highlighter is split into two distinct parts:
- an observer which monitors the node's position
- a renderer which draws the highlighter on top of the node
The renderer always lives in the parent process (browser window) and overlays an iframe with the highlighter markup:
- either over the content if highlighting in the context of the content toolbox
- or over the whole browser UI if highlighting in the context of the browser toolbox
When in the context of the browser toolbox (i.e. highlighting the browser UI), both observer and renderer live in the parent process. Communication is done by direct calls.
When in the context of the content toolbox (i.e. highlighting the page content), the observer lives in content process (so it can measure the node) while the renderer lives in the parent process. Communication is done by message passing via `MessageManager` (soon to be deprecated and replaced with JSWindowActor API)
## Notable differences after the split
- the observer checks whether it is in the content process (aka child process) and sets up the highlighter in the parent process by using [`setupInParent()`](https://docs.firefox-dev.tools/backend/actor-e10s-handling.html) and establishes a communication system to it via message manager. If the observer is in the parent process (browser toolbox scenario), the renderer is setup directly via its constructor and no additional communication system is required.
- whenever the node quads change (as determined by the untouched existing base class `auto-refresh.js`), the observer gathers the data about the node position and sends it over to the renderer. This happens in the `BoxModelHighlighterObserver._update()` (corresponding to the [`_update()` from the existing highlighter](https://searchfox.org/mozilla-central/rev/45f30e1d19bde27bf07e47a0a5dd0962dd27ba18/devtools/server/actors/highlighters/box-model.js#361-383)).
- the renderer expects its `render()` method to be called with the necessary node position information whenever it should update the highlighter. It is the entry point which then calls all the DOM manipulation methods copied over from the existing box model highlighter.
- the only notable change in DOM manipulation methods is in `BoxModelHighlighterRenderer._updateBoxModel()` (corresponding to [`updateBoxModel()` from the existing highlighter](https://searchfox.org/mozilla-central/rev/45f30e1d19bde27bf07e47a0a5dd0962dd27ba18/devtools/server/actors/highlighters/box-model.js#504-560)) where the `_nodeNeedsHighlighting()` is kept on the observer part and the canvas zoom adjustment is removed (`this.markup.scaleRootElement(this.currentNode, rootId)`) because the canvas is no longer influenced by the page zoom (the canvas lives in the browser window, not the content window)
Differential Revision: https://phabricator.services.mozilla.com/D47092
--HG--
rename : devtools/server/actors/highlighters/box-model.js => devtools/server/actors/highlighters/box-model-renderer.js
extra : moz-landing-system : lando
**Update October 8**
To use the new box model highlighter, flip this pref to true:
`devtools.inspector.use-new-box-model-highlighter`
---
Adding Julian as reviewer to check the sanity of the communication system and Patrick for the overall highlighter behavior.
---
This patch adds a base class for the renderer part of highlighters which is set up on the parent process in the browser window.
This is used by the `BoxModelHighlighterRender` introduced by D47092
`HighlighterRenderer.init()` will create an HTML iframe and inject it to the appropriate position in the browser window in order to serve as a rendering surface for highlighters of the inspected page content (content toolbox) or the browser UI (browser toolbox). A host iframe is used until [Bug 1492582](https://bugzilla.mozilla.org/show_bug.cgi?id=1492582) is fixed because the browser window is XUL and does not support the anonymous canvas frame used by existing highlighters.
The primary use case of `HighlighterRenderer` is as a base class for renderers which live in a separate process than the observers. This happens with highlighters for the content toolbox. Therefore, it provides methods to setup a communication system (via MessageManager for now) whereby the observer can send messages to the renderer and vice-versa: `setMessageManager()`, `postMessage()` and `onMessage()`.
I used the existing code from [`AccessibilityParent`](https://searchfox.org/mozilla-central/source/devtools/server/actors/accessibility/accessibility-parent.js) as a reference for this.
Classes that extend HighlighterRenderer must implement:
- a typeName representing the highlighter type; used to differentiate between other types of messages when the Message Manager is used;
- a _buildMarkup() method to generate the highlighter markup;
- a `render()` method to update the highlighter markup when given new information about the observed node.
NOTE: A temporary pink outline is set on the highlighter surface as a quick visual check to show its extent depending on context: browser toolbox or content toolbox. This will be removed before landing.
Differential Revision: https://phabricator.services.mozilla.com/D47091
--HG--
extra : moz-landing-system : lando
Based on the failure log, `prefs.alphabetizeOutline` from the previous run seems to intervene the current test run. The patch resets the prefs at the beginning of each test run.
Differential Revision: https://phabricator.services.mozilla.com/D48644
--HG--
extra : moz-landing-system : lando
Gabriel Luong
alexdominguezg
Brad Werth
Gurzau Raul
Alexandre Poirot
Itiel
Julian Descottes
Nicolas Chevobbe
Brian Hackett
Belén Albeza
Greg Tatum
Daisuke Akatsuka
jaril
Jason Laster
Micah Tigley
Dorel Luca
David Walsh
Julien Wajsberg
Gerald Squelart
Florens Verschelde
Jim Porter
Brendan Dahl
Marco Vega
Rob Wu
Jean-Yves Avenard
Oana Pop Rus
Daniel Varga
Chris Muldoon
Michael Ratcliffe
Sorin Davidoi
Bogdan Tara
Miriam
Logan Smyth
zhaogang
Ciure Andrei
Cosmin Sabou
Mellina Y.
alessandro
Armando Ferreira
Narcis Beleuzu
Razvan Caliman
Emilio Cobos Álvarez
lloan
Michael Hoffmann
Matt Woodrow
Mustafa
chujun