Register them as soon as we open devtools, instead of waiting for debugger panel opening.
So that breakpoints can work even if we did not open debugger panel yet.
So far, only debugger statement would force the opening of the debugger.
This allows to remove the redundant code from debugger frontend.
Also clarify in this patch that thread-utils exports thread configurations.
Differential Revision: https://phabricator.services.mozilla.com/D205772
In order to select elements referenced in idref/idreflist attributes,
we were querying the whole node document.
This is incorrect as id reference are scipes within a shadow root.
To fix this, we add a dedicated walker method to retrieve the referenced
node within the base node rootNode.
A test case is added to ensure we don't regress.
Differential Revision: https://phabricator.services.mozilla.com/D202451
We should probably expose new RDP methods to prevent relying on console evaluations for this.
We would still have some potential issues if the evaluated method is about a JS symbol
whose name is the console command.
Differential Revision: https://phabricator.services.mozilla.com/D200167
Because the JavaScript tracer is currently running in each process/thread/target actor independently,
it is more complex to make it record across navigations as it may be spawn in a distinct process.
While it is fine for stdout and webconsole outputs (we could just spawn many concurrent tracers in each process),
this is more complex for the experimental "profiler" output.
For now, the profiler output automatically stops on target destruction and will open the profiler result.
By having an option to start recording on next page load, it prevents starting the tracer and prevent logging traces
for the current WindowGlobal. It should help focus on the new document.
For the profiler output, it prevents having the profiler to show up for the previous WindowGlobal.
Sideby tweak:
* stop passing logMethod and consider, like other option to be coming from the preferences.
* fix confusing state when debugging a page running in the same process.
Differential Revision: https://phabricator.services.mozilla.com/D196874
For now we were releasing object actors one by one.
This would force to send an individual RDP request for each of them.
The console often release all objects actors related to older console message
going over the maximum limit of displayed console messages (10k).
This can easily grow in a large number of actors to be released,
either if console message are receiving many arguments and/or
if many console are logged.
We have to have one request per target as the actors could only be reached
within same-thread actor.
In order to prepare for ObjectFront removal, introduce a target-scoped "Objects" actor
which is a singleton per Target. It will receive the new "release in bulk objects actors"
method. Later, it will start implementing all the existing methods of the Object Actor
in order to migrate away from having to instantiate one Object Front (notice the singular on "Object"),
per inspected JS Object.
On the fronted side a new Object Command is introduced in order to abstract away the RDP/Fronts work.
Differential Revision: https://phabricator.services.mozilla.com/D198784
For now we were releasing object actors one by one.
This would force to send an individual RDP request for each of them.
The console often release all objects actors related to older console message
going over the maximum limit of displayed console messages (10k).
This can easily grow in a large number of actors to be released,
either if console message are receiving many arguments and/or
if many console are logged.
We have to have one request per target as the actors could only be reached
within same-thread actor.
In order to prepare for ObjectFront removal, introduce a target-scoped "Objects" actor
which is a singleton per Target. It will receive the new "release in bulk objects actors"
method. Later, it will start implementing all the existing methods of the Object Actor
in order to migrate away from having to instantiate one Object Front (notice the singular on "Object"),
per inspected JS Object.
On the fronted side a new Object Command is introduced in order to abstract away the RDP/Fronts work.
Differential Revision: https://phabricator.services.mozilla.com/D198784
Introduce a new global option in the tracer to log values.
For now, it only triggers javascript function call arguments to be logged,
but this will also impact the incoming feature logging native function calls,
and also the other incoming feature to log the returned values.
Differential Revision: https://phabricator.services.mozilla.com/D196019
Introduce a new global option in the tracer to log values.
For now, it only triggers javascript function call arguments to be logged,
but this will also impact the incoming feature logging native function calls,
and also the other incoming feature to log the returned values.
Differential Revision: https://phabricator.services.mozilla.com/D196019
The property isn't used anywhere, but those objects would still be serialized
(via `form()`) and sent to the client.
Specs are updated to reflect the new situation, and handle backward compatibility.
Differential Revision: https://phabricator.services.mozilla.com/D184728
This aligns all features in DevTools frontend currently evaluating some JavaScript code:
console input, eager evaluation, watch expression, log breakpoint, conditional breakpoint, inline preview, preview tooltips,
console "store as global", inspector "store as temp variable", DOM panel "window" retrieval,...
Except the console evaluation input, none of the many features evaluating code should:
* trigger any type of breakpoint via the evaluated code,
* evaluated sources should not be shown in the debugger.
This has been done by adding a `disableBreaks` argument to the web console actor evaluation method.
This mimic CDP's existing argument and disable trigerring any type of breakpoint,
while also avoiding instantiating Debugger.Source for the evaluated source.
Differential Revision: https://phabricator.services.mozilla.com/D180094
This is a simple version for now, showing a non-interactive `container` badge
for elements with `container-type` of `size` or `inline-size` (`style` isn't
supported yet).
Differential Revision: https://phabricator.services.mozilla.com/D156567
The `mdn_url` property in the compatibility data is not always defined,
as some properties are not documented on MDN.
Luckily, there's a `spec_url` property that we can default to in such case,
so we return that from the server, and fall back to this in the compatibility
panel and the compatibility tooltip.
We might still have cases where we don't have any link at all, so in such case,
we don't render a link in the compatibility panel, and we don't show the "Learn more"
link in the compatibility tooltip.
In order to properly check the page the user might be taken to, we move
the `simulateLinkClick` helper to `shared-head.js` and use it in both compatibility
panel and compatibility tooltip assertion helpers.
Some tests are then updated to provide the now missing information that those
helpers expect.
Differential Revision: https://phabricator.services.mozilla.com/D179030
The `mdn_url` property in the compatibility data is not always defined,
as some properties are not documented on MDN.
Luckily, there's a `spec_url` property that we can default to in such case,
so we return that from the server, and fall back to this in the compatibility
panel and the compatibility tooltip.
We might still have cases where we don't have any link at all, so in such case,
we don't render a link in the compatibility panel, and we don't show the "Learn more"
link in the compatibility tooltip.
In order to properly check the page the user might be taken to, we move
the `simulateLinkClick` helper to `shared-head.js` and use it in both compatibility
panel and compatibility tooltip assertion helpers.
Some tests are then updated to provide the now missing information that those
helpers expect.
Differential Revision: https://phabricator.services.mozilla.com/D179030
Previously, we were calling `getCssDeclarationBlockIssues` for each dom rule.
This was causing performance issue when displaying a lot of rules as we'd make
almost concurrent RDP calls.
In this patch, we make `CompatibilityActor#getCssDeclarationBlockIssues` take
an array of dom rule declarations, so we can get the data for multiple rules at once.
From the client, we add a method to the inspector command, that will batch calls
to the RDP method.
`compatibility-user-settings.js` is moved to `devtools/shared` so it can safely
be loaded from the command.
Differential Revision: https://phabricator.services.mozilla.com/D178313
On the server side, this patch introduces:
* a new "tracer" Target Scope actor to start and stop tracing per target
* a new TRACING_STATE resource in order to report to the client when we start/stop tracing and with which log method.
On the frontend side, this patch introduces:
* a global tracer button, which will enable/disable tracing for all targets/threads
all at once.
* a global header, similar to pause, reporting if any target is tracing or not.
The header reuses the pause header and we may want to followup to better coordinate case
where we pause and trace at the same time. Only one of the two states is displayed.
We may want to followup here to be able to trace only one target and see the state per target.
Differential Revision: https://phabricator.services.mozilla.com/D163614
This wasn't so trivial to revisit tests, but at least we stop shipping test-only
features in RDP. And the cryptic echo implement now only exists in tests.
Differential Revision: https://phabricator.services.mozilla.com/D168360
Instead of keeping track of an index, store the formatter entry in
the object actor from `customFormatterHeader` so we can re-use it
in `customFormatterBody`.
Differential Revision: https://phabricator.services.mozilla.com/D167905
This actor was only used by the legacy listener.
Its main method was listStores which exposed all the storage type actors.
Now they are exposed via storage Resource watchers.
This requires to tweak the decision making to show the storage panel
as the actor no longer exists... Unfortunately we can't check for
resource traits on the watcher actor as the browser toolbox
on older runtime won't expose it.
Note that this.front wasn't used for a little while in ui.js.
I had to keep a few things in the frontend in order to still be able
to connect to old servers. But I put lots of comments to do proper cleanup later.
Differential Revision: https://phabricator.services.mozilla.com/D166770
This was the last resource type requiring to keep the old storage actor as-is.
This will help drastically simplify it and move storage type code into each Resource Watcher class.
Differential Revision: https://phabricator.services.mozilla.com/D166661
Depends on D166139
This is one of the easiest actors to unplug, and it has very little connections to the rest, so doing it early in the stack
Differential Revision: https://phabricator.services.mozilla.com/D166141
These preferences ended up being specifics to network observation.
The only one lastly supported is now set via NetworkParentActor.setSaveRequestAndResponseBodies.
Differential Revision: https://phabricator.services.mozilla.com/D165864
With the removal of the old non-fission browser toolbox,
we removed the last usage of this old codebase.
We used to be able to listen to network events via WebConsole's actor's startListeners method.
Nowadays we should rather use the Watcher actor's watchResources method and listen to
NETWORK_EVENT resource.
(or migrate to WebDriver Bidi which will soon allow to listen to network requests see bug 1790369)
This patch also removed all now unused block* requests from webconsole actor,
Differential Revision: https://phabricator.services.mozilla.com/D165603
This patch adds a tooltip that is displayed when the user hovers a `@container`
declaration in the rule view.
The tooltip displays the query container that is used for this rule and the selected
node and the computed values of its `containerType`, `inlineSize` and `blockSize`
(if the `containerType` is `size`) properties.
The title attribute is removed on the `ruleview-rule-ancestor-data` items as it
was not playing well with the new tooltip. The styling for those element is
modified so they are never cropped so we can see the whole text (and don't need
the title anymore).
A test case is added to make sure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D161129
