We duplicate the documentation for moz:firefoxOptions between
firefox-source-docs.m.o and MDN. This redirects users to look at MDN.
Differential Revision: https://phabricator.services.mozilla.com/D48695
--HG--
extra : moz-landing-system : lando
Cloning the original node was needed when we needed the MediaInfo copied over, but
HTMLVideoElement::CloneElementVisually copies it over for us, so we can create a
fresh <video> element. This should also be a much healthier thing to do
security-wise, since we're not cloning strange nodes from the web.
Differential Revision: https://phabricator.services.mozilla.com/D48123
--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
Unless the interval is set to 0. We use that in testing, and should let the
initial timer fire happen in that case.
Differential Revision: https://phabricator.services.mozilla.com/D46293
--HG--
extra : moz-landing-system : lando
The UpdateTimerManager has an undocumented behaviour for firing its listeners
very soon after first registration (about 10min into the first session).
Let's document that behaviour, and make it optional.
Differential Revision: https://phabricator.services.mozilla.com/D46292
--HG--
extra : moz-landing-system : lando
Left shifting a negative value results in undefined behaviour. It is safer to
multiply in this case.
Differential Revision: https://phabricator.services.mozilla.com/D48751
--HG--
extra : moz-landing-system : lando
Maybe this test causes crashes of Firefox in [@ mozilla::ShutdownXPCOM(nsIServiceManager*)].
Due to the low intermittent rate lets get it temporarily disabled for further investigation
by next week.
Differential Revision: https://phabricator.services.mozilla.com/D47233
--HG--
extra : moz-landing-system : lando
Having `mProfileBuffer` be a pointer is not really helpful:
- The pointer is never null (It's allocated on ActivePS construction, and
implicitly deleted on ActivePS destruction); it's never moved-from.
- It requires an extra `new` and an extra `delete`.
Differential Revision: https://phabricator.services.mozilla.com/D48650
--HG--
extra : moz-landing-system : lando
Add assertions that all `sInstance` pointers (from both `CorePS` and `ActivePS`)
are not null before being dereferenced.
This is probably more than needed, but it's only `MOZ_ASSERT`s limited to
Nightly, and it should give better feedback in case something goes wrong.
Eventually, I think it would be better to make most methods non-static, and have
a checked reference-to-instance getter.
Differential Revision: https://phabricator.services.mozilla.com/D48649
--HG--
extra : moz-landing-system : lando
Since Bug 1570879, SwapChain is created with alpha at first, then the SwapChain is typically re-created at first RenderCompositorANGLE::BeginFrame() calle, since non Glass window is common since Windows 10. The re-creation is redundant.
Differential Revision: https://phabricator.services.mozilla.com/D48800
--HG--
extra : moz-landing-system : lando
Because implementations were not in agreement about this and the spec
informally called for src-before-dest, the spec was changed to
correspond to the dynamic and canonical operand order:
dest-before-src. So we adapt to this.
Differential Revision: https://phabricator.services.mozilla.com/D48176
--HG--
extra : moz-landing-system : lando
Create dummy implementations for the MediaSession interfaces. The files
are generated by running `./mach webidl-example` with necessary changes
to make it buildable.
The internal implementations are blank in this patch. They will be done
in the following patches.
Due to some spec issues, the final implementations only support some
basic operations like "play" and "pause".
Differential Revision: https://phabricator.services.mozilla.com/D45456
--HG--
extra : moz-landing-system : lando
Razvan Caliman
Daniel Varga
James Graham
ffxbld
Andreas Tolfsen
Alessio Placitelli
Brian Hackett
Mike Conley
Alexander Surkov
Julian Descottes
Chris H-C
Harry Twyford
Coroiu Cristina
Marco Vega
Marian Raiciof
Tomislav Jovanovic
Dan Minor
Honza Bambas
Henrik Skupin
Emilio Cobos Álvarez
dennisschagt
Valentin Gosu
Gerald Squelart
Sebastian Streich
Mustafa
Sam Foster
sotaro
Erica Wright
Lars T Hansen
Chun-Min Chang
Alok Nikhil
Gurzau Raul