The WebConsoleActor tries to destroy it via a debug:destroy-network-monitor.
But as it is done during the destruction of the target actor, typically when there is a
top level target switching, this message doesn't reach the parent process.
So, ensure destroying this actor from the parent process side, when we see that the
frame target is being destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D92654
- Rename `id` to a more explicit `forwardingPrefix` property
- Add comments to why we need to handle a list of connections
- Remove the `rpcs` property from the connections object
- Turn `rpcDeferred` from an array to an object, as it's used like one.
Differential Revision: https://phabricator.services.mozilla.com/D92752
The previous code was all wrong and we weren't correctly listening to resource
for already existing additional targets. Top level target was still working fine
thanks to WatcherActor.watchResources calling watchTargetResource directly.
Differential Revision: https://phabricator.services.mozilla.com/D91969
The problem with `getOverflowCausingElement`s seems to be that it returned an array
of nodes that weren't properly attached to their parents.
To mitigate this, we call `attachElements` on the entire list of nodes and
return a `disconnectedNodeArray` which ensures that the returned nodes
are properly attached and therefore has all their parent node information
when calling `showNode`.
Differential Revision: https://phabricator.services.mozilla.com/D92360
This patch adds a simple WorkerTargetActor, which is similar to the mock target
actor we had in startup/worker.js.
Its spec file is empty at the moment, and it does not have an associated front,
but that might change with Bug 1633712 where we will at least have events for
resources available/destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D91128
This renames the current WorkerTargetActor which is actually a descriptor.
We also rename the existing `workerTargetFront` occurences to `workerDescriptorFront`
to avoid confusion when we do introduce the real worker fronts and actors.
Differential Revision: https://phabricator.services.mozilla.com/D91100
This patch adds a simple WorkerTargetActor, which is similar to the mock target
actor we had in startup/worker.js.
Its spec file is empty at the moment, and it does not have an associated front,
but that might change with Bug 1633712 where we will at least have events for
resources available/destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D91128
This renames the current WorkerTargetActor which is actually a descriptor.
We also rename the existing `workerTargetFront` occurences to `workerDescriptorFront`
to avoid confusion when we do introduce the real worker fronts and actors.
Differential Revision: https://phabricator.services.mozilla.com/D91100
This renames the internal -moz-math-script-level property in order to
prepare for full math-depth support. Currently, the property is guarded
under a disabled-by-default flag, so there should be no observable
behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D91285
This renames the internal -moz-math-script-level property in order to
prepare for full math-depth support. Currently, the property is guarded
under a disabled-by-default flag, so there should be no observable
behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D91285
This renames the internal -moz-math-script-level property in order to
prepare for full math-depth support. Currently, the property is guarded
under a disabled-by-default flag, so there should be no observable
behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D91285
This renames the internal -moz-math-script-level property in order to
prepare for full math-depth support. Currently, the property is guarded
under a disabled-by-default flag, so there should be no observable
behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D91285
This patch renames the internal -moz-math-display to math-style and
exposes it under the layout.css.math-style.enabled preference. The
initial value becomes "normal" but that does not affect the default
MathML behavior since the UA style sheet sets the math-style property
explicitly on <math> tags. WPT tests are updated to use the syntax
approved by the CSSWG.
Intent to prototype: https://groups.google.com/forum/#!msg/mozilla.dev.platform/1hQQ7ISudGo/_yLEckEeBQAJ
Differential Revision: https://phabricator.services.mozilla.com/D90731
This patch renames the internal -moz-math-display to math-style and
exposes it under the layout.css.math-style.enabled preference. The
initial value becomes "normal" but that does not affect the default
MathML behavior since the UA style sheet sets the math-style property
explicitly on <math> tags. WPT tests are updated to use the syntax
approved by the CSSWG.
Intent to prototype: https://groups.google.com/forum/#!msg/mozilla.dev.platform/1hQQ7ISudGo/_yLEckEeBQAJ
Differential Revision: https://phabricator.services.mozilla.com/D90731
This patch renames the internal -moz-math-display to math-style and
exposes it under the layout.css.math-style.enabled preference. The
initial value becomes "normal" but that does not affect the default
MathML behavior since the UA style sheet sets the math-style property
explicitly on <math> tags. WPT tests are updated to use the syntax
approved by the CSSWG.
Intent to prototype: https://groups.google.com/forum/#!msg/mozilla.dev.platform/1hQQ7ISudGo/_yLEckEeBQAJ
Differential Revision: https://phabricator.services.mozilla.com/D90731
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
The callee getter returned |undefined| for certain functions because it's
hard to recover the callee consistently for all environments (and we can't
return the internal canonical function). See also bug 1414684.
This patch fixes that by exposing the script instead of the callee. Devtools is
only interested in the displayName and parameterNames properties and those are
also available on scripts (the previous patch adds Script.parameterNames).
Differential Revision: https://phabricator.services.mozilla.com/D89701
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
Sylvestre Ledru
Alexandre Poirot
Nicolas Chevobbe
Razvan Maries
Gabriel Luong
Gijs Kruitbosch
Dorel Luca
Frederic Wang
Narcis Beleuzu
Mihai Alexandru Michis
Bogdan Tara
Razvan Caliman
Kriyszig
Daisuke Akatsuka
Julian Descottes
Jan de Mooij
Christoph Kerschbaumer