While the availability of Reader View is somewhat noticeable visually, a screen reader user won't be aware of this unless they explicitly explore the toolbar.
Differential Revision: https://phabricator.services.mozilla.com/D48036
--HG--
extra : moz-landing-system : lando
This reverts bug 1425541.
This was intended to make it easy for accessibility clients to retrieve the Reader View state programmatically.
However, it was never actually used by any clients.
Differential Revision: https://phabricator.services.mozilla.com/D48035
--HG--
extra : moz-landing-system : lando
We want to remove flat strings (JSFlatString). With this patch we only expose
linear strings (JSLinearString) to API consumers.
This is very mechanical for the most part, because code typically only cares
about linear strings and not the null-termination aspect.
CTypes's Library.cpp has some Windows-specific code where we relied on null-terminated
strings. This patch adds JS_CopyStringCharsZ for that use case.
Differential Revision: https://phabricator.services.mozilla.com/D48314
--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
This allows installing a SIGXCPU handler, which will simply set an atomic to
true when reached.
Another function allows querying this atomic.
Finally, another function allows demoting the current thread from real-time
priority.
This is per-process currently, as there is only one audio callback thread that
is set to RT scheduling per process, servicing all HTMLMediaElements and MSGs.
Whenever any of those go over the soft limit, the thread is demoted.
Differential Revision: https://phabricator.services.mozilla.com/D43404
--HG--
extra : moz-landing-system : lando
Going over the RT budget is now handled by demoting the thread instead of
crashing.
Differential Revision: https://phabricator.services.mozilla.com/D47083
--HG--
extra : moz-landing-system : lando
These probes should allow us to compute:
- percentage of users that use FTP
- percentage of navigations using FTP protocol to fetch directory listing
- percentage of navigations using FTP protocol to fetch resource
Differential Revision: https://phabricator.services.mozilla.com/D48770
--HG--
extra : moz-landing-system : lando
Instead of allocating a tile surface from the texture cache during
the tile post_update method, this is now deferred until the
take_context method of picture.
This will allow a simple CPU occlusion culling pass to run after
all the tile cache dependency updates (when the visible tiles and
rects are know), but before the surfaces are allocated. In this way,
we will be able to skip allocating, rasterizing and compositing
any tiles that are eliminated by the occlusion culling test.
Differential Revision: https://phabricator.services.mozilla.com/D48795
--HG--
extra : moz-landing-system : lando
Tim Huang
Jan de Mooij
Jon Coppeard
James Teh
ffxbld
Razvan Caliman
Nihanth Subramanya
Paul Adenot
Simon Giesecke
Alok Nikhil
Michal Novotny
Tim Nguyen
Zhao Jiazhong
Lina Cambridge
Mark Hammond
Glenn Watson
Brian Hackett
Oana Pop Rus
Jorg K
Emilio Cobos Álvarez