The paused frame will still be considered as selected from the point of view of stepping buttons, and shown with a grey background,
but will no longer be highlighted with a blue background.
Differential Revision: https://phabricator.services.mozilla.com/D219779
The paused frame will still be considered as selected from the point of view of stepping buttons, and shown with a grey background,
but will no longer be highlighted with a blue background.
Differential Revision: https://phabricator.services.mozilla.com/D219779
When selecting a trace in the debugger sidebar, we are opening the location
in CodeMirror, but compared to the Web Console input, we were missing the recorded JS values.
Let's try to display them similarly to inline previews.
Differential Revision: https://phabricator.services.mozilla.com/D197118
Spidermonkey fails returning source text content via `Source.text` attribute.
It returns "[no source]" and the urlContents fallback was trying to keep using this instead
of the text content fetched via a request.
Differential Revision: https://phabricator.services.mozilla.com/D218003
Keep supporting the pref makes a lot of `click`, `auxclick` and `contextmenu`
event creators complicated (and look messy). So, let's delete it as soon as
possible.
Differential Revision: https://phabricator.services.mozilla.com/D217225
- make them both use .theme-twisty to show an arrow icon.
- move some specifics stylings of SourcesTree to the base class.
- make SourcesTree use the arrow React component provided by Tree class.
- use .theme-twisty instead of .arrow (which already implements rotation and colors on expand). But it uses "open" instead of "expanded" classname.
(VirtualizedTree was already using theme-twisty)
This impacts the Source Tree, ObjectInspector (console, debugger), Watch Expressions, memory panel (dominator view).
Differential Revision: https://phabricator.services.mozilla.com/D215637
Also moving the LOG_METHODS from actors to specs so that the frontend
can import them from devtools/shared instead of devtools/server.
Differential Revision: https://phabricator.services.mozilla.com/D215085
Also moving the LOG_METHODS from actors to specs so that the frontend
can import them from devtools/shared instead of devtools/server.
Differential Revision: https://phabricator.services.mozilla.com/D215085
The component used to set a `focused` class on the input container, which we
don't rely on anymore for styling the input.
This means we can remove the `focused` state property that was handling the
focused state.
Differential Revision: https://phabricator.services.mozilla.com/D214718
This patch includes:
- Enables editor shortcuts for CM6
- Fixes bug on CM5/CM6 where the shortcut for opening the log breakpoint panel opens the conditional breakpoint panel
- Add tests to cove the log panel fix
Differential Revision: https://phabricator.services.mozilla.com/D213814
This patch makes the all `ePointerClick` event dispatcher in C++ code use
`WidgetPointerEvent` instead of `WidgetMouseEvent`.
Then, this patch also makes the all `click` event dispatcher in chrome code use
`PointerEvent` instead of `MouseEvent`. For detecting wrong trusted event
dispatching of `click` event, this patch adds assertion into `MouseEvent`.
Therefore, all chrome test dispatchers also changed to use `PointerEvent`.
Finally, this patch includes a change of a WPT. That checks the `pointerId`
caused by executing an access key. In this case, the value should be `-1`
rather than the default value `0` because Pointer Event spec defines so for
synthetic pointer events caused by non-pointing devices [1]. Chrome also
sets it to `-1` and fails [2]. Therefore, the new assertion will pass on both
Firefox and Chrome.
1. https://w3c.github.io/pointerevents/#dom-pointerevent-pointerid
2. https://wpt.fyi/results/uievents/interface/keyboard-accesskey-click-event.html?run_id=5087897523060736&run_id=5136270464647168&run_id=5163620816388096&run_id=5201281304231936
Differential Revision: https://phabricator.services.mozilla.com/D213001
Note that the ignore code for subprocess is being ported from the legacy worker watcher.
The Worker Target URL is now correctly set to the Absolute URL,
this has an impact on the context selector as we are displaying it.
Also, this patch highlights some issues around Common JS Loader and the distinct compartment
to be used when debugging privileged page, or when running the browser toolbox.
It caused leaks when running browser toolbox tests in debug builds.
The JS Process Actor is directly loaded in a distinct global and compartment "DevTools global",
thanks to `loadInDevToolsLoader` flag of BrowserToolboxDevToolsProcess JS Process Actor configuration.
There is no need to use `useDistinctSystemPrincipalLoader` helper as Loader.sys.mjs, loaded from
the JS Process Actor will also be loaded in the distinct global.
Then, we only need to ensure that the CommonJS Loader will also pick up the "DevTools global"
when it is loaded in that distinct global.
Things will be significantly easier once we migrate from CommonJS to ESM as the `{ global: "contextual" }`
option passed to `ChromeUtils.importESModule` will do the right thing, as well as static `import` statements.
Differential Revision: https://phabricator.services.mozilla.com/D204874
Note that the ignore code for subprocess is being ported from the legacy worker watcher.
The Worker Target URL is now correctly set to the Absolute URL,
this has an impact on the context selector as we are displaying it.
Also, this patch highlights some issues around Common JS Loader and the distinct compartment
to be used when debugging privileged page, or when running the browser toolbox.
It caused leaks when running browser toolbox tests in debug builds.
The JS Process Actor is directly loaded in a distinct global and compartment "DevTools global",
thanks to `loadInDevToolsLoader` flag of BrowserToolboxDevToolsProcess JS Process Actor configuration.
There is no need to use `useDistinctSystemPrincipalLoader` helper as Loader.sys.mjs, loaded from
the JS Process Actor will also be loaded in the distinct global.
Then, we only need to ensure that the CommonJS Loader will also pick up the "DevTools global"
when it is loaded in that distinct global.
Things will be significantly easier once we migrate from CommonJS to ESM as the `{ global: "contextual" }`
option passed to `ChromeUtils.importESModule` will do the right thing, as well as static `import` statements.
Differential Revision: https://phabricator.services.mozilla.com/D204874
Note that the ignore code for subprocess is being ported from the legacy worker watcher.
Also, this patch highlights some issues around Common JS Loader and the distinct compartment
to be used when debugging privileged page, or when running the browser toolbox.
It caused leaks when running browser toolbox tests in debug builds.
The JS Process Actor is directly loaded in a distinct global and compartment "DevTools global",
thanks to `loadInDevToolsLoader` flag of BrowserToolboxDevToolsProcess JS Process Actor configuration.
There is no need to use `useDistinctSystemPrincipalLoader` helper as Loader.sys.mjs, loaded from
the JS Process Actor will also be loaded in the distinct global.
Then, we only need to ensure that the CommonJS Loader will also pick up the "DevTools global"
when it is loaded in that distinct global.
Things will be significantly easier once we migrate from CommonJS to ESM as the `{ global: "contextual" }`
option passed to `ChromeUtils.importESModule` will do the right thing, as well as static `import` statements.
Differential Revision: https://phabricator.services.mozilla.com/D204874
We seem to never wait for the breakpoint to be actually visibile before calling assertBreakpoint,
but it seems that it is relevant in this particular test, in the uncompressed codepath.
Differential Revision: https://phabricator.services.mozilla.com/D210991
We were waiting for Sources, which are resources, but not the targets,
which are updated with a different logic and timings.
Differential Revision: https://phabricator.services.mozilla.com/D210943
The previous patch explicitly prevents spawning JavaScriptTracer for same-process iframe,
as the JavaScriptTracer can only be spawn once per thread.
But then the JavaScriptTracer should ensure tracking DOM Events for these same-process iframe globals.
`DebuggerNotificationObserver` requires to connect to each individual WindowGlobal.
Connecting to the top WindowGlobal isn't enough to receive DOM Events for children WindowGlobals.
Differential Revision: https://phabricator.services.mozilla.com/D208468
* The formers JSWindow Actors used independently to create Target Actor for WindowGlobals, Web workers and Service workers
are all unified behind a single JSProcess Actor pair which was only used to create target actors for DOM Content Processes.
* The DevToolsProcess JSProcess actor now actively monitor the currently watched target types
in order to start and stop listeners specific to each target type.
We no longer rely on JSWindow Actors to observe WindowGlobal instantiations.
* `watchedByDevTools` is now consistantly set from each WindowGlobal's content process, via the WindowGlobalTargetActor.
With the new setup, the parent process no longer track WindowGlobal/BrowsingContext's and so there is no
natural place to flag them. While, in the content process, the target actor is an obvious place.
There is just one trick in window global target watcher in order to also set this flag on initial about blank documents.
* `browser-element-host` Session Data is now slightly more simple. It works like any other similar session data attribute.
But we have to ignore any pending exception coming up from updateDomainSessionDataForServiceWorkers call as that be still pending
while the toolbox closes, which make the JS Process Actor be unregistered,
and ultimately make the underlying sendQuery promise be rejected.
* The `loader` is made specific to each Watcher/connection and put in the connections map,
so that we can better support content toolbox & browser toolbox usecases
and we have a unique place to define the loader per watcher/connection.
* browser_target_command_detach.js: detach is no longer enough. It wouldn't stop watching and prevent the re-instantiation
of the target actor. We now have to stop watching for targets. This actually better match what happens on toolbox closing.
This test was meant as a unit test for covering remote debugging reusing the same DevToolsClient for debugger the same tab.
* `browser_toolbox_watchedByDevTools`. The management of watchedByDevTools is now driven from the content process.
And because the DevTools Server and especially the watcher actor is destroyed without an explicit RDP request
that the toolbox destruction is waiting for, we can't rely on closeToolbox to know
when the server is fully cleaned up.
Differential Revision: https://phabricator.services.mozilla.com/D203409
* The formers JSWindow Actors used independently to create Target Actor for WindowGlobals, Web workers and Service workers
are all unified behind a single JSProcess Actor pair which was only used to create target actors for DOM Content Processes.
* The DevToolsProcess JSProcess actor now actively monitor the currently watched target types
in order to start and stop listeners specific to each target type.
We no longer rely on JSWindow Actors to observe WindowGlobal instantiations.
* `watchedByDevTools` is now consistantly set from each WindowGlobal's content process, via the WindowGlobalTargetActor.
With the new setup, the parent process no longer track WindowGlobal/BrowsingContext's and so there is no
natural place to flag them. While, in the content process, the target actor is an obvious place.
There is just one trick in window global target watcher in order to also set this flag on initial about blank documents.
* `browser-element-host` Session Data is now slightly more simple. It works like any other similar session data attribute.
But we have to ignore any pending exception coming up from updateDomainSessionDataForServiceWorkers call as that be still pending
while the toolbox closes, which make the JS Process Actor be unregistered,
and ultimately make the underlying sendQuery promise be rejected.
* The `loader` is made specific to each Watcher/connection and put in the connections map,
so that we can better support content toolbox & browser toolbox usecases
and we have a unique place to define the loader per watcher/connection.
* browser_target_command_detach.js: detach is no longer enough. It wouldn't stop watching and prevent the re-instantiation
of the target actor. We now have to stop watching for targets. This actually better match what happens on toolbox closing.
This test was meant as a unit test for covering remote debugging reusing the same DevToolsClient for debugger the same tab.
* `browser_toolbox_watchedByDevTools`. The management of watchedByDevTools is now driven from the content process.
And because the DevTools Server and especially the watcher actor is destroyed without an explicit RDP request
that the toolbox destruction is waiting for, we can't rely on closeToolbox to know
when the server is fully cleaned up.
Differential Revision: https://phabricator.services.mozilla.com/D203409
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
Alexandre Poirot