This implements the introduction display for the new search engine preference.
The decision for whether or not to display the introduction is handled in AboutPrivateBrowsingHandler.jsm, as we need
to limit it to being displayed once per session.
Differential Revision: https://phabricator.services.mozilla.com/D48722
--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
harry
Noemi Erli
Dão Gottwald
Sebastian Hengst
Matt Woodrow
Kashav Madan
Mike de Boer
Tomislav Jovanovic
Andreea Pavel
Edouard Oger
Andrei Oprea
Mark Banner
Bianca Danforth
Rob Wu
Jared Wein
Daniel Varga
ffxbld
Razvan Caliman
Julian Descottes
Erica Wright
Gijs Kruitbosch
Bogdan Tara
Michael Kaply
Johann Hofmann
mcrawford@mozilla.com
Tim Nguyen
Gurzau Raul
Tim Huang
Neil Deakin
Mark Striemer