The context menu action was freezing because of an infinite
loop in getRect: since we weren't passing a boundary window,
the function uses the top window, which can be the windowRoot.
But then, we walk up through the window using window.parent,
which would never get us the windowRoot, hence the infinite loop.
We fix this by providing the boundary window to getReact.
A test is added to ensure we don't regress in the future.
Differential Revision: https://phabricator.services.mozilla.com/D104388
The current implementation of the eyedropper was using drawWindow, which does
not handle remote frames.
To make the tool fission compatible, we re-use the screenshot-content actor which
do support remote frames. We had to do a few modification on it though so the
eyedropper would work the same as it does at the moment:
- add a `disableFlash` property to the screenshot options, so we don't play the
flash animation for the eyedropper
- retrieve the page current zoom level from the screenshot-content actor so we
can adjust the size of the resulting image
- split the `dpr` screenshot option into 2 distinct ones:
- `snapshotScale`, which will be the scale passed to `drawSnapshot`. By default,
this will be the dpr of the window, so the screenshot is as crisp as it can be.
- `fileScale`, which will be the scale of the resulting file.
- we control the fileScale that is sent to the server with the `ignoreDprForFileScale`
on the client. This is needed by the eyedropper so it doesn't draw images that are
too big when the dpr is > 1.
With all those changes, browser_inspector_highlighter-eyedropper-frames.js is passing
with fission enabled, so we can remove the `fail-if` annotation it had.
Differential Revision: https://phabricator.services.mozilla.com/D103879
The behaviour of the eyedropper is impacted when the page is zoomed-in, but we
didn't have a test for that, so we're adding one here.
Differential Revision: https://phabricator.services.mozilla.com/D103878
This adds a test that checks that the eyedropper displays the expected
colors when hovering iframes (same origin and remote).
Since we're going to do extra work from the client in Bug 1568831 to
actually get the screenshot, we can't simply use the regular inspector
test highlighter helper, as it spawns an eyedropper eyelighter on its
own, without calling the inspector client code.
And since we can't use the helper, we can't use the testActor method
that the other tests use, as we don't have an highlighter front for
the eyedropper.
We create new methods on the testActor which will retrieve the eyedropper
instance that is created by the inspector actor.
The new test expectedly fails on fission and is tagged as fail-if.
We take this as an opportunity to enhance the simple eyedropper test
so we actually uses the button in the ui instead of only manipulating it
through the test actor.
Differential Revision: https://phabricator.services.mozilla.com/D103746
In order to enable screenshots from the browser console and browser toolbox, we
make a small change in the `simulateCameraFlash`, as the browsing context we
pass to it does not have a `topFrameElement` property (so we use the top chrome window
document element instead).
We also have to register browser actors when starting the browser console so it
can have access to the screenshot actor.
A simple test is added for `:screenshot` in the Browser Console.
Differential Revision: https://phabricator.services.mozilla.com/D104004
This is done by using the `WindowGlobal#drawSnapshot` function that, unlike `Canvas#drawWindow`,
handles remote frame.
Since drawSnapshot is only available on the parent process, we re-purpose the
current ScreenshotActor to a parent process one, that only calls drawSnapshot
with a passed rect on a given browsing context, and return a data url of the
screenshot.
A new target-scoped actor, ScreenshotContentActor, is added so we can retrieve
the information of the window needed to take the screenshot (the relative area
to the browsing context, the dpr), but also run pre and post screenshot tasks,
like scrolling to the top and then resettting the scroll position once the screenshot
is taken.
On the client, we add an helper function that handles all the client/server communication
and actually save the screenshot. All previous consumers of the screenshot front
use that function, that also handles backward compatibility, when connection to a server
where the screenshot actor is still living in the content process.
This allows us to remove the captureScreenshot method from the responsive actor
and its reference to the screenshot actor.
Some tests that were failing on Fission now pass, so we can remove their fail-if
annotation.
Differential Revision: https://phabricator.services.mozilla.com/D103613
I think we were only trying to assert the URL of the selected source. That's what I'm doing here.
Using findSource, which picks the first matching source by URL breaks
the support of the debugger with many targets.
With many targets, the debugger will start spawning one source per URL, per target.
Leading to many sources with the same URL.
Differential Revision: https://phabricator.services.mozilla.com/D103933
This code was designed for when the debugger was only supporting service workers as additional target.
Now that we can have many: regular workers, content process, addons...
We should ensure that each target type gets its own source set.
Differential Revision: https://phabricator.services.mozilla.com/D103868
We keep mMedium in nsPresContext rather than just looking it up in the
browsing context because that's used quite more frequently.
Differential Revision: https://phabricator.services.mozilla.com/D103782
Depends on D103325
When we stop watching for resources, if there are no other watchers currently in activity, we will unregister the JSWindowActors, with following stack:
```
unregisterJSWindowActor@resource://devtools/server/actors/watcher/WatcherRegistry.jsm:344:17
maybeUnregisteringJSWindowActor@resource://devtools/server/actors/watcher/WatcherRegistry.jsm:280:7
unwatchTargets@resource://devtools/server/actors/watcher.js:199:21
handler@resource://devtools/shared/protocol/Actor.js:172:37
onPacket@resource://devtools/server/devtools-server-connection.js:379:58
send/<@resource://devtools/shared/transport/local-transport.js:68:25
exports.makeInfallible/<@resource://devtools/shared/ThreadSafeDevToolsUtils.js:103:22
DevToolsUtils.executeSoon*exports.executeSoon@resource://devtools/shared/DevToolsUtils.js:54:21
send@resource://devtools/shared/transport/local-transport.js:56:21
send@resource://devtools/shared/protocol/Front.js:272:30
generateRequestMethods/</frontProto[name]@resource://devtools/shared/protocol/Front/FrontClassWithSpec.js:42:14
stopListening@resource://devtools/shared/resources/target-list.js:363:29
destroy@resource://devtools/shared/resources/target-list.js:612:10
```
This will lead to destroy all the currently created JSWindowActors, which will also destroy the corresponding target actors.
However RDM will still try to perform some cleanups on the current target after destroying the target-list. These calls will fail as soon as RDM uses a JSWindowActor based target.
This will only start happening in Bug 1644397, but then it will make the test browser_tab_remoteness_change_fission_switch_target.js fail on shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D103326
RDM uses a dedicated client, target-list etc. Which means that we can use a local tab descriptor and remove the target switching logic from RDM.
New test is added in D103688
Differential Revision: https://phabricator.services.mozilla.com/D103325
This was causing _priorPause to be reset unexpectedly,
leading to lastPausedPacket being null and missing "paused" THREAD_STATE resource.
Differential Revision: https://phabricator.services.mozilla.com/D103068
I'm also cleaning up things in debugger tests in order to reuse the same helper to check for breakpoints info in the gutter.
Differential Revision: https://phabricator.services.mozilla.com/D103201
This patch fixes everything in order to be able to toggle NETWORK_EVENT
and NETWORK_EVENT_STACKTRACE resources for all target types.
But this doesn't change the trait as CSP blocked request would no longer appear.
Before being able to toggle the trait, we have to implement bug 1689644.
Differential Revision: https://phabricator.services.mozilla.com/D103451
Tim Nguyen
Butkovits Atila
Nicolas Chevobbe
smolnar
Dorel Luca
Jan Varga
Yura Zenevich
Alexandre Poirot
Mihai Alexandru Michis
Julian Descottes
Daisuke Akatsuka
Sylvestre Ledru
Sebastian Zartner
Hubert Boma Manilla
Emilio Cobos Álvarez