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
Instead of replicationg the browser list fetch using the
preference on the server side, we send the browser list from the
client side to the CompatibilityActor to get the declaration block
compatibility issues.
This way the pref setting is retained completely on the client
side and server doesn't have code duplication.
Differential Revision: https://phabricator.services.mozilla.com/D87613
This moves the MDNCompatibility library and the related datasets
and tests to the server side. It also moves the compatibility actor
file intot he compatibility directory.
The links to these files have been updated and the library tests have
been moved to the new location.
Differential Revision: https://phabricator.services.mozilla.com/D86521
Most of the client side imports from the MDNCompatibility library
is to access the MDNCompatibility.ISSUE_TYPE property.
This patch moves the property into devtools/shared/constants.js
from where it can be accessed on both the client and server side.
Differential Revision: https://phabricator.services.mozilla.com/D86519
Depends on D85863
Follow-up for code review https://phabricator.services.mozilla.com/D81526#inline-471516
Renaming existing events emitted on behalf of `CssTransformHighlighter` to avoid conflict and confusion with the generic show/hide highlighter events introduced in HighlightersOverlay. When migrating the CssTransformHighlighter to the Fission-ready highlighters approach, these event names will go away completely.
Differential Revision: https://phabricator.services.mozilla.com/D89570
Depends on D85859
The Box Model diagram in the Layout sidebar panel of the Inspector shows a Box Model Highlighter on hover over its components parts: margin, border, padding, content.
This patch routes the calls to the highlighter to use the approach introduced in `HighlightersOverlay` in D81526
Differential Revision: https://phabricator.services.mozilla.com/D85860
Depends on D85858
The Markup view uses the highlighter in a few places:
- while hovering over nodes in the node tree
- while hovering over nodes in the breadcrumbs view under the node tree
- after clicking a node from the node tree, a highlighter is shown, then it is automatically hidden after a delay
This patch routes all calls to show and hide the highlighter to the newly implemented approach in `HighlightersOverlay` which ensures hiding existing instances before showing others regardless of target.
A slight change is made in `HighlightersOverlay` to allow passing in an option to automatically hide the highlighter after a delay. This removes the need for discrete handling of timers within the markup view (removes [_brieflyShowBoxModel](https://searchfox.org/mozilla-central/source/devtools/client/inspector/markup/markup.js#742-756)) and enables reusing this mechanism with the Node Picker after picking (see `onPickerPicked` in [this diff](https://phabricator.services.mozilla.com/D81528?vs=321451&id=332813#toc) from D81528)
`HighlightersOverlay.showHighlighterTypeForNode()` no longer skips duplicate calls with the same highlighter type and nodeFront if the options provided are different between calls. This supports scheduling autohide on an already visible highlighter. Use case: in the node tree, hover over a node (shows highlighter), then click on the node (shows highlighter again, but schedules autohide after a delay)
NOTE: This automatic hiding after a delay can cause intermittent test failures. Slow running tests can find themselves without a highlighter midway through the checks. To mitigate this, while testing, highlighters are not automatically hidden. See `HIGHLIGHTER_AUTOHIDE_TIMER` in [this diff](https://phabricator.services.mozilla.com/D81528?vs=321451&id=332813#toc) from D81528. Tests which explicitly check the autohide behavior can reinstate `inspector.HIGHLIGHTER_AUTOHIDE_TIMER`.
Tests are updated to invoke actual highlighters and listen to their events. No more mocking.
Differential Revision: https://phabricator.services.mozilla.com/D85859
Depends on D81526
This patch updates tests pertaining only to node picker behavior. Run one-by-one, they're all expected to pass.
However, running the whole Inspector test suite at this point in the commit series will fail some other tests because:
- we're updating shared test helpers here without also updating the other tests;
- there is inter-dependence in the other tests between node picker and markup view which is being migrated to the new highlighters approach in D81530
The rest of the tests are getting updated in the subsequent patches in this commit series.
Differential Revision: https://phabricator.services.mozilla.com/D81528
Depends on D81525
Introduced a centralized way in `HighlightersOverlay` to invoke highlighters by type, automatically managing previously active highlighters.
First some context.
`HighlightersOverlay` is a bit of a misnomer. It already does a few things:
- provides methods to manually invoke some highlighters (Flex/Grid/Shapes/BoxModel)
- provides a way to delegate mouse events from Rules view / Computed view / Markup and invoke highlighters based on the event's target node
- manages state of Flex/Grid highlighters to be able to restore them on page refresh
- exposes the node that is highlighted by a particular highlighter
- misc handlers for events that require hiding highlighters by type (ex mutation events)
The changes in this patch add the core functionality which will automatically manage the visibility of highlighters regardless of their node's host frame:
- `this._activeHighlighters` is a Map which maps a highlighter type to the currently visible highlighter instance and its corresponding `NodeFront`
- `showHighlighterTypeForNode(type, nodeFront, options)` invokes a highlighter type for a given `NodeFront` while toggling off any existing highlighter for that type. For situations where multiple highlighters of the same type can be visible at the same time (ex: Grid), this is where we could manage their visibility.
- `hideHighlighterType(type)` hides all highlighters of a given type; can be followed-up with a more specific `hideHighlighterTypeForNode()` when needed
- `getNodeForActiveHighlighter(type)` returns the `NodeFront` currently highlighted by a highlighter type. This is an abstracted replacement for `flexboxHighlighterShown`, `geometryEditorHighlighterShown`, etc.
##### Accommodation for tests
To mitigate the fact that many tests and some consumers expect [exact event names](https://searchfox.org/mozilla-central/search?path=&q=-highlighter-shown) to be fired, like "box-model-highlighter-shown", instead of generic shown/hidden events with the highlighter type property as event data, we introduce a temporary map, `HIGHLIGHTER_EVENTS`, from which we pick the event to fire according to the highlighter type. As we progress in refactoring, the intent is for this map to slowly go away.
##### Intent for refactoring
The intent is for all client-side consumers to invoke highlighters via these methods. For example:
```
this.inspector.highlighters.showHighlighterTypeForNode(
"BoxModelHighlighter",
nodeFront
)
```
See another example of this in the migration of `FlexboxHighligther` in D79694.
##### Future plans
In the medium-term, it's likely we'll move this part of `HighligthersOverlay` from inspector to toolbox and rename it `HighlightersManager`. This way, other consumers, like Debugger and Console can also use it [instead of the existing approach](https://searchfox.org/mozilla-central/rev/027893497316897b8f292bde48dbb6da2391a331/devtools/client/framework/toolbox.js#3503-3557). Haven't attempted this yet. Pending updates to the Flexbox, Grid, Shapes and CSS Transform highlighters so when we migrate paths from `inspector.highlighters` to ⭐️ `toolbox.highlighters` is done in one go for all tests and consumers.
Differential Revision: https://phabricator.services.mozilla.com/D81526
This isn't really related to EventLoop, but this is another exception thrown when running DAMP.
This time related to a request made against an already destroyed NodeFront.
Differential Revision: https://phabricator.services.mozilla.com/D89451
We check if telemetry "devtools.tooltip.shown" is set for label
"css-compatibility" once the tooltip is toggled visible during
the test.
Differential Revision: https://phabricator.services.mozilla.com/D86403
Based on initital implementation of inactive css tooltip telemetry
implementation in D32810
We record toggling of tooltip using `sendOpenScalarToTelemetry`
against the label "css-compatibility".
Differential Revision: https://phabricator.services.mozilla.com/D86402
The key of the object is incorrectly used as `css-compatibility-experimental-supported-message`
instead of `experimental-supported`. This leads to the l10n translation
for undefined msgId leading to failure of appearance of tooltip.
This patch fixes the problem and adds a test to prevent regression.
Differential Revision: https://phabricator.services.mozilla.com/D86584
Butkovits Atila
Alexandre Poirot
Cristina Coroiu
Razvan Caliman
Kriyszig
Julian Descottes
Csoregi Natalia
Emilio Cobos Álvarez
manas
Daisuke Akatsuka
Narcis Beleuzu