This leaves the paperName blank instead as it is not actually needed.
The paper size is retrieved from the information context instead.
This also changes to using a double literal for converting inches to points for
better precision.
Differential Revision: https://phabricator.services.mozilla.com/D90567
The displayport is aligned to screen pixels by an alignment number; there was
code to increase that alignment number for the WebRender codepath. This is
desirable because it causes the displayport to move less frequently, which
provides better performance characteristics with WebRender. However, the
way that was implemented, it was possible for the aligned displayport to not
completely enclose the unaligned displayport, which could then result in
perma-checkerboarding.
This patch removes that code and replaces it with a simpler approach to scale
up the existing alignment number by a factor based on the size of the scroller's
base rect (roughly how much of the scroller is visible to the user).
This does make the displayports larger, more so for scrollers with more visible
area. This has negative performance implications, so we mitigate that by also
scaling down the displayport margin multiplier by the same scaling factor. This
isn't perfect, but seems to work well enough in practice.
Differential Revision: https://phabricator.services.mozilla.com/D90503
The next patch requires gfxVars::UseWebRender to work in gtests, so we need
to make sure gfxPlatform is initialized correctly for all the tester classes.
Differential Revision: https://phabricator.services.mozilla.com/D90502
This ensures that even with the displayport margins dropped to zero we don't
get any checkerboarding. This currently fails with WR enabled, because the
displayport alignment code moves the displayport so it doesn't enclose the
unaligned displayport, and that's bad.
Differential Revision: https://phabricator.services.mozilla.com/D90501
We unfortunately can't use the AsyncShutdownService in either the GPU or RDD process.
So we add a little utility class AsyncBlockers that will resolve its promise once all services have deregistered from it.
We use it to temporily suspend the RDDParent or GPUParent from killing the process, up to 10s.
This allows for cleaner shutdown as the parent process doesn't guarantee the order in which processes are killed (even though it should).
Differential Revision: https://phabricator.services.mozilla.com/D90487
The RDD process gets shutdown following a NS_XPCOM_SHUTDOWN_OBSERVER_ID notification.
Notifications are processed in LIFO order, since the RDD process is started on demand it would have typically be registered after a content process.
We must ensure that the RDD get shutdown after all content processes so that it can receive notifications that the RemoteDecoderManagerChilds are shutting down.
Differential Revision: https://phabricator.services.mozilla.com/D90485
The root cause in this bug is that the connection info used by `SpdyConnectTransaction` is the same instance as the connection info in `nsHttpTransaction`, so we should clone it and let `SpdyConnectTransaction` use the cloned one.
Differential Revision: https://phabricator.services.mozilla.com/D89801
Depends on D90248
This patch combines two test helpers into one: removes `getRuleViewSelectorHighlighterIcon()` and folds its logic into `clickSelectorIcon()`.
The other callsites for `getRuleViewSelectorHighlighterIcon()` are removed in D90250.
The augmented `clickSelectorIcon()` will toggle the selector highlighter accordingly (on or off for the given selector depending on its current state). It returns a promise that resolves with the event data from either the "highlighter-hidden" or "highlighter-shown" events emitted by the selector highlighter. Tests check this data for the expected results.
Tests no longer use mocks for selector highlighter. They test the real thing.
Differential Revision: https://phabricator.services.mozilla.com/D90249
Depends on D90247
The new React-based Rules view is a stalled project, but not yet abandoned.
This patch updates the logic to toggle the selector highlighter so it doesn't fall too far behind in parity with the legacy but still active Rules view.
Flip this pref to test the new Rules view: `devtools.inspector.new-rulesview.enabled`.
It will add a new Rules panel to the Inspector sidebar at the far right end of the tabs.
To avoid confusion and bugs, disable 3-pane mode so you only see one Inspector sidebar panel at a time.
Differential Revision: https://phabricator.services.mozilla.com/D90248
Depends on D90246
This patch updates the logic to toggle the selector highlighter (icon next to CSS selectors in the Rules view) using the process-agnostic approach introduced in `HighlightersOverlay`.
There are 3 main chunks of logic:
- A) Introduce event delegation in the Rules view (`CssRuleView.handleEvent()`)
- B) Introduce generic handler for highligther events in Rules view (`CssRuleView.handleHighlighterEvent()`)
- C) Toggle the selector highlighter using the `HighlightersOverlay.showHighlighterTypeForNode()`/`HighlightersOverlay.hideHighlighterType()` methods with the `SELECTOR` highlighter type.
### Part A
With Part A, CssRuleView.handleEvent(), we're laying the groundwork to have the Rules view react to events within its DOM tree.
Currently, `HighlightersOverlay` is doing too much. Along with managing highlighters, it acts as an event delegate for the Rules view and Computed view via [HighlightersOverlay.addToView()](https://searchfox.org/mozilla-central/rev/0c97a6410ff018c22e65a0cbe4e5f2ca4581b22e/devtools/client/inspector/shared/highlighters-overlay.js#415-428). This adds [cumbersome logic to check the target](https://searchfox.org/mozilla-central/rev/0c97a6410ff018c22e65a0cbe4e5f2ca4581b22e/devtools/client/inspector/shared/highlighters-overlay.js#1402-1428) of an event in order to know whether to react to it. This isn't wrong per-se, but it concentrates DOM knowledge from a broad part of the Inspector away from where it is generated.
Ideally, `HighlightersOverlay` should only manage highlighters. It should be called from various endpoints without regard to who is calling and in reaction to which events.
The intent is to reuse this `CssRuleView.handleEvent()` for:
- toggling the CSS Transforms Highlighter by reacting to mouseover events from corresponding CSS values
- toggling the Flexbox / Grid / Shapes highlighters by reacting to clicks on corresponding swatch icons next to CSS values
### Part B
Part B, `CssRuleView.handleHighlighterEvent()`, adds a generic highlighter event handler to the Rules view. Checking the event name and highlighter type, the Rules view can update itself in reaction to highlighters triggered from elsewhere in the Inspector.
In this patch, we're using it to toggle the active CSS class name on the selector highlighter icon in response to "highlighter-shown" / "highlighter-hidden" events of the `SELECTOR` highlighter type.
Probably a bit overkill here. But it gets more useful with the Flexbox and Grid Highlighters which have call sites in multiple places with indicators that need to be reconciled:
- Flex/Grid badges in Markup view
- Checkboxes in Layout panel
- Swatch icons for Flex and Grid in Rules view
### Part C
Part C replaces the legacy toggling logic for selector highlighter with the abstract methods in `HighligthersOverlay`, does some slight clean-up, and fixes some bugs in the previous implementation.
All CSS rules matching the same selector will be marked when the selector is active (see inline comment)
When editing a selector, the selector highlighter for another CSS rule will no longer be hidden (see inline comment)
Differential Revision: https://phabricator.services.mozilla.com/D90247
If a native compositor surface ends up with no effective clip rect,
the clip rect supplied via the compositor trait to CoreAnimation
may be very large.
This large clip rect can cause accuracy issues inside CoreAnimation
resulting in layers that are drawn incorrectly.
To work around this, clamp the surface clip rect to the current
allocated area of the tiles for a given compositor surface.
Differential Revision: https://phabricator.services.mozilla.com/D90638
This moves a bunch of stuff that uses the internals of the helper thread system
into HelperThreads.cpp and puts it behind an API.
Differential Revision: https://phabricator.services.mozilla.com/D90524
If in a textarea, a blank line is inserted, we need to return the offsets of just that new inner paragraph, or the braille display of a screen reader will show the previous line and not a blank one.
Differential Revision: https://phabricator.services.mozilla.com/D90655
We unfortunately can't use the AsyncShutdownService in either the GPU or RDD process.
So we add a little utility class AsyncBlockers that will resolve its promise once all services have deregistered from it.
We use it to temporily suspend the RDDParent or GPUParent from killing the process, up to 10s.
This allows for cleaner shutdown as the parent process doesn't guarantee the order in which processes are killed (even though it should).
Differential Revision: https://phabricator.services.mozilla.com/D90487
The RDD process gets shutdown following a NS_XPCOM_SHUTDOWN_OBSERVER_ID notification.
Notifications are processed in LIFO order, since the RDD process is started on demand it would have typically be registered after a content process.
We must ensure that the RDD get shutdown after all content processes so that it can receive notifications that the RemoteDecoderManagerChilds are shutting down.
Differential Revision: https://phabricator.services.mozilla.com/D90485
On windows, just subprocessing `pip3 ...` was running the mach
virtualenv's pip3 binary, rather than the system's (or user's
virtualenv's) pip3.
Differential Revision: https://phabricator.services.mozilla.com/D90492
I've wanted to use this recently for a couple things. This uses the
same scheme and even templates we use for attributes, so it's mostly
moving code around...
Inverting the code generation so that the implementation is infallible,
and we actually generate the NS_IMETHOD goop inline somehow could be
potentially desirable, though that causes an extra virtual call for
non-C++ callers I guess, so maybe it's not such a great trade-off. Plus
it seems more complicated...
Explicitly forbid mixing infallible with notxpcom (as it doesn't make
sense), and similarly forbid infallible + returning void (as C++ doesn't
allow us to overload a function that differs only on its return type).
Differential Revision: https://phabricator.services.mozilla.com/D90044
Gregory Mierzwinski
Bob Owen
Jon Coppeard
Mihai Alexandru Michis
Kartikaya Gupta
David Teller
Jean-Yves Avenard
Jonathan Watt
Andy Grover
Denis Palmeiro
Dmitry Bezhetskov
Kershaw Chang
Nicolas Silva
Brindusan Cristian
Razvan Caliman
Glenn Watson
Dão Gottwald
Marco Zehe
Simon Giesecke
Moritz Birghan
Michael Goossens
Mitchell Hentges
Emilio Cobos Álvarez
Kris Maglione
Andrew Halberstadt