Depends on D93817
There should no longer be new message managers during the lifecycle of the actor.
We can simplify the storage actor thanks to this.
Differential Revision: https://phabricator.services.mozilla.com/D93819
Depends on D93817
There should no longer be new message managers during the lifecycle of the actor.
We can simplify the storage actor thanks to this.
Differential Revision: https://phabricator.services.mozilla.com/D93819
Depends on D92220
Rephrasing of code comments and cleanup of documentation to reflect that `CustomHighlighterActor` is now the only actor which deals with highlighting stuff after removing `HighlighterActor` in D92220. No functionality is changed in this patch.
Differential Revision: https://phabricator.services.mozilla.com/D92221
This patch completely removes the `HighlighterActor` and its accessors.
The rest of the patches in this commit series update the consumers and tests to use the new highlighter manager added to `HighlightersOverlay` in D81526. [Bug 1646028](https://bugzilla.mozilla.org/show_bug.cgi?id=1646028) updated all consumers within the **Inspector** panel to use this approach. Now, we're updating the rest of the consumers outside the Inspector.
### Why remove HighlighterActor?
The changes introduced in D81526 for [Bug 1646028](https://bugzilla.mozilla.org/show_bug.cgi?id=1646028) make it possible to highlight nodes using the `CustomHighligtherActor` with the **Box Model Highlighter** implementation.
The `HighlighterActor` was itself a wrapper around **Box Model Highlighter** and Simple Outline Highlighter, and exposed node picking functionality. Simple Outline Highlighter was removed with [Bug 1650094](https://bugzilla.mozilla.org/show_bug.cgi?id=1650094). The node picking functionality was decoupled from `HighlighterActor`in [Bug 1607756](https://bugzilla.mozilla.org/show_bug.cgi?id=1607756).
After those changes, `HighlighterActor` is no longer special. It can be removed in favor of a single generic actor, `CustomHighligtherActor`, with the Box Model Highlighter implementation.
Differential Revision: https://phabricator.services.mozilla.com/D92220
This patch adds support for dedicated worker targets in the Watcher actor.
Shared and Service workers are not handled yet.
In a similar manner to what we already have for frame targets, we add a worker-helper
file that will communicate with a JsWindowActor pair spawned on each document,
that will manage workers (DevToolsWorkerParent/DevToolsWorkerChild).
For a given document, the DevToolsWorkerChild will enumerate the existing workers
related to it, as well as add an event listener to be notified when workers are
being registered and unregistered, and communicate that back to the DevToolsWorkerParent
on the main thread, so worker targets creation and destruction are notified by
the Watcher actor (via target-available-form and target-destroyed-form events).
When a worker is created, the DevToolsWorkerChild for the document the worker
was spawned from will create a WorkerTargetActor, that will live in the worker
thread (using worker-connector.js), passing it resources the Watcher is currently
listening for. It will also handle communication between the main thread and the
worker thread, when the watcher listen to new resources (or stop watching resources).
A WorkerTargetFront is created so the client can be notified about available
resources (via the resource-available-form event, emitted from the worker target).
Tests are added in the next patches of this queue.
Differential Revision: https://phabricator.services.mozilla.com/D85399
Depends on D92756
Detach errors can happen when a target is being destroyed.
Historically, those errors were swallowed in the TargetFront mixin.
However this logic became outdated when we started purging requests during Front::destroy.
This results in non-actionable error messages logged frequently while using DevTools.
This changeset updates the logic in target-mixin.js in order to swallow errors due to purged requests.
Differential Revision: https://phabricator.services.mozilla.com/D92757
Depends on D93030
All Front requests are purged before the Front is destroyed.
In theory there is no reason to process packets after the Front has been destroyed.
It will only create cryptic error messages.
Differential Revision: https://phabricator.services.mozilla.com/D92756
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
Depends on D86162
The resource watcher already guarantees that listeners are only called once, caches resources etc.
Consequently, the client side logic currently implemented in the WalkerFront is redundant and should be removed.
Differential Revision: https://phabricator.services.mozilla.com/D86163
At the moment, it is easy to break remote debugging by reading preferences incorrectly.
Typically, creating a preference in the firefox preference index file will only create it for Firefox, not for mobile (Fenix).
When trying to read the preference from the server with the Services.prefs.get*Pref APIs, the call will throw unless a fallback value was specified.
A longer term solution is investigated at https://bugzilla.mozilla.org/show_bug.cgi?id=1660182, but for now this changeset allows about:debugging to set a few default values for preferences when connecting to a remote runtime.
Differential Revision: https://phabricator.services.mozilla.com/D88782
Move the function taking care of closing the Browser Console to shared-head so
we can close it before closing the tabs opened during the test.
While attaching the worker, check that the Worker Debugger isn't closed, and
if it is, reject the promise. On the target list, catch rejection while attaching
and simply bail out so we don't call the rest of the code in onTargetAvailable.
Those guards are not enough to prevent any failure while attaching, so we're
wrapping calls to `attachAndInitThread`/`_onThreadInitialized` in try/catch
blocks to avoid test failures.
Differential Revision: https://phabricator.services.mozilla.com/D88766
PDF print preview are using about:blank documents, which are ignored
by DevTools in order to save resources.
We avoid creating targets for these, very often, transcient documents.
I tried to find ways to distinguish typical temporary about:blank documents
from this print preview one.
Differential Revision: https://phabricator.services.mozilla.com/D88956
The issue was that the getHighlighter request for the about:printpreview
target never settled. It appears that the document always stays in an
unitialized readyState, which was causing trouble.
Instead of relying only on readyState, we now call isDocumentReady, which
also checks if the document is loading.
Differential Revision: https://phabricator.services.mozilla.com/D87756
The issue was that the getHighlighter request for the about:printpreview
target never settled. It appears that the document always stays in an
unitialized readyState, which was causing trouble.
Instead of relying only on readyState, we now call isDocumentReady, which
also checks if the document is loading.
Differential Revision: https://phabricator.services.mozilla.com/D87756
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
We already had a function that was returning a resourceType dictionnary for
a given watcher or target actor, on which we were then checking the targetType
to return the appropriate dictionnary.
It feels appropriate to have a dedicated function to get the dictionnary from
the targetType only, so we can call it from other places instead of repeating
the same instructions.
Differential Revision: https://phabricator.services.mozilla.com/D86979
Depends on D85599
The WalkerActor is currently responsible for watching navigations and exposes them to the client.
However, this is communicated to the client differently depending on what kind of frame navigates.
If the top frame of the target navigates, this will be exposed via the watchRootNode API (onDestroyed/onAvailable callbacks will be triggered)
If an inner frame navigates, mutations will be emitted: "frameLoad"/"documentUnload" + a fake "childList" mutation.
On the client side, we have to handle both very similarly which leads to some duplication.
Also "frameLoad"/"documentUnload" are one of the last "immediateMutations" which usually means they should not have been mutations in the first place.
The goal here is to use the watchRootNode API for all frames.
Differential Revision: https://phabricator.services.mozilla.com/D84973
Depends on D85598
This test relies on mutations which are no longer emitted for most navigations and which will no longer be emitted at all with the next patches.
It has been disabled for 9 months and should be removed.
Differential Revision: https://phabricator.services.mozilla.com/D85599
Depends on D85597
newRoot mutations are no longer emitted by any server we support, we can remove the corresponding client code.
Differential Revision: https://phabricator.services.mozilla.com/D85598
_ref is renamed to _getOrCreateNodeActor to better reflect the purpose of the method.
_refMap is renamed to _nodeActorsMap
The test helper inspector-helpers was also directly querying _refMap.
This has been replaced by a call to the public API getNode.
Differential Revision: https://phabricator.services.mozilla.com/D84972
Previously CompatibilityActor could only compute the compatiblity
issues taking node actor. However with the implementation of
inline compatibility warning, it becomes necessary to compute
compatiblity issue from the CSS declaration block. This patch
exposes a getCssDeclarationBlockIssues and add browser dataset
fetch within the actor for inline warnings.
Differential Revision: https://phabricator.services.mozilla.com/D81472
Not having the window property anymore, we have to change the `window` getter
in WebConsoleActor to retrieve `workerGlobal`. And since the getter name wasn't
reflecting what it was holding (it can be a window, a worker global or a sandbox),
we rename it to `global` (and `evalWindow` to `evalGlobal`).
We remove the `globalDebugObject` getter on the thread actor that wasn't used
anywhere in the code.
Differential Revision: https://phabricator.services.mozilla.com/D86035
The `watchResources` function [1] takes as a first parameter either a watcher
actor or a target actor, that is used to manage the created resources (e.g. the
object actors of console messages). In order to be able to manage actors, it
needs to extend the `Pool` class (which is the case for Actor).
In the worker cases, things are a bit different, since we create a DevToolServer
which only have a WebConsole and a Thread actor. Those actors usually take a target
actor as a parent, but in the Worker thread we simply have an object implementing
the properties and methods it needs.
This will be this target actor mock that we're going to pass to `watchResources`,
and in order to be able to do that, it needs to be able to manage actors.
In regard of all this, this patch makes the target actor mock an actual Actor,
witout spec, on which we then put the existing methods and properties.
[1] https://searchfox.org/mozilla-central/rev/0e309417bdc73be33fc93f6bd7a0d4063d2c6e51/devtools/server/actors/resources/index.js#66
Differential Revision: https://phabricator.services.mozilla.com/D85814
* removing simulations for protanomaly, deuteranomaly and tritanomaly
* updating (fixing) the color matrices for protanopia, deuteranopia and tritanopia
* adding a matrix to simulate achromatopsia
Co-authored-by: Matthew Petroff <mozilla@mpetroff.net>
Differential Revision: https://phabricator.services.mozilla.com/D85508
Depends on D75157
A thread actor attach error shows up as
Protocol error (unknownError): error occurred while processing 'attach':
[object Object] from: server0.conn145.content-process36/workerTarget5/thread1
[object Object] is a legacy {error, message} object thrown by the thread actor
Differential Revision: https://phabricator.services.mozilla.com/D83507
If we don't, content processes may have outdated data and create a target actor
for a watcher that no longer watch for targets.
Differential Revision: https://phabricator.services.mozilla.com/D82798
-moz-inert CSS property reflects inert subtrees concept and can be used to implement HTML:dialog element and HTML:inert attribute
Differential Revision: https://phabricator.services.mozilla.com/D81701
There's two issues being fixed here - the first is that no-unused-vars now reports against the last instance of the unused variable. The second is no-dupe-else-if is now on by default.
Depends on D84816
Differential Revision: https://phabricator.services.mozilla.com/D84818
This is the only meaningful callsite for actorHasMethod.
This method has many bugs and we want to replace it with traits
Differential Revision: https://phabricator.services.mozilla.com/D84689
This patch is a mixed bag of fixes:
- don't log an error when the string couldn't be analyzed, as it can occur
frequently when the console input isn't valid, and it clutters the browser
console
- never return a `null` matchProp. Default to empty string, so consumer code
can always assume it's a string
- don't call trim on a property if it's not a string (it can be an integer at
this point).
Differential Revision: https://phabricator.services.mozilla.com/D84779
We do not expose it nor ever style it. Just use the parent style all the
time. This avoids problematic style resolution calls during reflow.
Differential Revision: https://phabricator.services.mozilla.com/D84358
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
The problem has 2 folds.
The first one is that the shutdown function on DevToolsExtensionPageContextParent
wasn't called, which means the target was never destroyed. This is fixed by
overriding unload in DevToolsExtensionPageContextParent instead of shutdown, so
the function gets called and the target destroyed.
The second issue was that a single webextension could create 2 targets, and since
we only keep track of a single target, we would miss one. This is fixed by putting
the call to watchTargets in getCurrentDevTools in a promise, so subsequent calls
that might occur before the resulting promise isn't resolved don't end up calling
watchTargets a second time.
Differential Revision: https://phabricator.services.mozilla.com/D83935
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
This is quite similar to the error messages watcher, except that we call
ensureCSSErrorReportingEnabled after retrieving the cached messages.
Resource no longer includes `errorMessageName` and `isPromiseRejection` as it
makes little sense for the CSS warning.
The existing resource test is updated to run with and without the server support.
Differential Revision: https://phabricator.services.mozilla.com/D83047
I've not got Windows to test the fix specifically.
This should stop from throwing an Error if the WeakMap does not contain
any data for the channel.
It should just return `null`
Differential Revision: https://phabricator.services.mozilla.com/D83840
Uses of `-moz-appearance: none` are changed to `appearance: none`.
Uses of other values that are simply reverting the appearance back to
its default are changed to `appearance: auto`.
Uses of values in UA sheets that are defining the inherent appearance of
widgets are changed to:
appearance: auto;
-moz-default-appearance: <value>;
since those values are either no longer supported on (-moz-)appearance,
or are still supported but only in some limited form.
There are some uses of `-moz-appearance: textfield` on <input
type=number> elements that are renamed to `appearance: textfield`.
Differential Revision: https://phabricator.services.mozilla.com/D83430
This removes the calculation method coordinatesRelativeToScreen in favor of
using the event-supplied screen coordinates. Those coordinates are scaled to
device coordinates to meet expectations of the sendNative methods.
Differential Revision: https://phabricator.services.mozilla.com/D74161
Note: Until private fields are enabled by default, this test case will take the
early return. However, I have tested locally that it fails without the fix, and
passes with the fix.
Differential Revision: https://phabricator.services.mozilla.com/D82786
The reply was never used, and due to other changes in this bug, was causing
ignored exceptions to be thrown occasionally when a query was sent immediately
before unregistering the actor.
Differential Revision: https://phabricator.services.mozilla.com/D82615
Julian Descottes
Razvan Maries
Csoregi Natalia
Razvan Caliman
Hubert Boma Manilla
Bogdan Tara
Alexandre Poirot
Nicolas Chevobbe
JulianWels
Mihai Alexandru Michis
Emilio Cobos Álvarez
Sylvestre Ledru
Gabriel Luong
Gijs Kruitbosch
Dorel Luca
Frederic Wang
Narcis Beleuzu
Kriyszig
Daisuke Akatsuka
Jan de Mooij
Christoph Kerschbaumer
Brad Werth
manas
Kris Maglione
Noemi Erli
Butkovits Atila
Logan Smyth
wartmanm
Sebastian Streich
Taegeon Lee
Jeremy Ir
Yura Zenevich
Sonia Singla
Alexander Surkov
Mark Banner
Kashav Madan
Luca Greco
Cameron McCormack
Johann Hofmann
Frederik Braun
Farooq AR
Andrea Marchesini
Andreea Pavel
Matthew Gaudet
Nika Layzell