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
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
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
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 take this opportunity to remove Pool.get as well,
which was doing exactly the same thing as Pool.actor
This highlighted a couple issues in Reps:
- LongString were relying on the isGrip function, which was only checking that
the actor property was truthy. So it was matching LongStringFront which had
the actor method. This is modified by using the isLongString helper instead.
- The Object rep was building all the reps for the object properties, even in
TINY mode, where the result was only used to check the length. In the Accessibility
panel, it can happen that an plain object containing front properties is passed
to Rep. It was fine before because this was short-circuited by the Accessor rep
which was only checking the truthiness of a `get` property. With `get` being
removed, the default Rep was used, which is Object, and we were hitting a
recursion loop, as some of the properties of fronts are cycle references.
There should be a fix in the Accessibility panel to _not_ pass fronts, but we
also "fix" it from here by simply not building sub-properties for the object
when we're in TINY mode.
Differential Revision: https://phabricator.services.mozilla.com/D81971
It used to take an object with only 1 property, a function. The way it was
called in the webconsole actor made it harder to follow than it actually need.
We take that as an opportunity to convert the function to a class.
Differential Revision: https://phabricator.services.mozilla.com/D79294
It used to take an object with only 1 property, a function. The way it was
called in the webconsole actor made it harder to follow than it actually need.
We take that as an opportunity to convert the function to a class.
Differential Revision: https://phabricator.services.mozilla.com/D79252
It used to take an object with only 1 property, a function. The way it was
called in the webconsole actor made it harder to follow than it actually need.
We take that as an opportunity to convert the function to a class.
Differential Revision: https://phabricator.services.mozilla.com/D79249
In order to retrieve the list of impacted element for a given CSS warning,
we are evaluating a document.querySelector expression,
using the cssSelector we get from the error itself.
But if the warning message comes from an iframe, we are not retrieving the
impacted elements, only items from the top-level document.
By storing the target actor id a message is emitted from directly in the message
itself, we can retrieve the target front, and use it to do the evaluation against
the right target.
This is not enough though, as non-remote frame don't have a dedicated target,
and we'll be back at square one, using the top-level document to do the evaluation.
In order to fix that, we're passing the innerWindowID to the evaluateJSAsync method,
so it can be used on the server to retrieve the window instance we need.
A test is added to ensure this feature works as expected for iframes, and it
passes with or without fission enabled.
Differential Revision: https://phabricator.services.mozilla.com/D75811
This is cheaper than calling Element::GetGridFragments as it does not need to
to construct an entire array of results. Most uses of GetGridFragments in the
devtools are only testing for the existence of grid fragments, and can be
changed to this cheaper method instead.
Differential Revision: https://phabricator.services.mozilla.com/D71674
The primary issue here is that the intended usecase for `onNativeCall` is to
allow aborting execution in cases where we certain native functions are called.
Given that intended usecase, the issue here is that execution of Debugger
hooks themselves may trigger native functions or other cases where execution
will be terminated.
To avoid this issue, we've decided that the presence of an onNativeCall hook
should cause all Debugger hooks to be ignored other than those associated
with the Debugger object that is performing the evaluation.
In reality, we may want to make this even stricter in the future by
moving the implementation of "eager eval" to C++, making `onNativeCall` a
callback passed to the Debugger's eval-like APIs, and then disallowing _all_
hook execution during eager evaluation, but that would be a much larger task.
Differential Revision: https://phabricator.services.mozilla.com/D67110
--HG--
extra : moz-landing-system : lando
The WebConsoleActor extends the Actor class, which extends the
Pool class. This means we don't need to create an extra Pool
to hold actors created by the WebConsoleActor.
We take this as an opportunity to remove the getActorFromID method,
which was only an alias for Pool#actor.
Depends on D66780
Differential Revision: https://phabricator.services.mozilla.com/D67290
--HG--
extra : moz-landing-system : lando
Treating as many realms as we can as debuggee makes us much less likely to
accidentally cause side-effects during eager-evaluation of code in the console.
Differential Revision: https://phabricator.services.mozilla.com/D65445
--HG--
extra : source : 9e09d30270d6cc660fabb406e132e2e09db870a5
I've run into this a couple times now, where as I'm tweaking things, I
accidentally introduce something that throws. The code as it was defaulted
to allowing calls to any native function that throws, which seems like a
bad idea, so this now defaults to termination when an error is encountered.
Depends on D65466
Differential Revision: https://phabricator.services.mozilla.com/D65467
--HG--
extra : source : a6efc9fb5e12dcda1254cb2773a4b3234a3944ba
Splitting this list into its own file reduces the chances of accidentally
referencing incorrect globals.
The implementation's original placement in eval-with-debugger for instance
was accidentally pulling Reflect from resource://gre/modules/reflect.jsm
because that file also makes use of `Reflect.parse`. Rather than try to
keep it in that file and rename things, placing the list in its own
lazy-loaded file seems like the easiest and most future-proof approach.
Differential Revision: https://phabricator.services.mozilla.com/D65466
--HG--
extra : source : 62d4008a089add58a8688af4220a07134d3a05ca
Treating as many realms as we can as debuggee makes us much less likely to
accidentally cause side-effects during eager-evaluation of code in the console.
Differential Revision: https://phabricator.services.mozilla.com/D65445
--HG--
extra : moz-landing-system : lando
I've run into this a couple times now, where as I'm tweaking things, I
accidentally introduce something that throws. The code as it was defaulted
to allowing calls to any native function that throws, which seems like a
bad idea, so this now defaults to termination when an error is encountered.
Depends on D65466
Differential Revision: https://phabricator.services.mozilla.com/D65467
--HG--
extra : moz-landing-system : lando
Splitting this list into its own file reduces the chances of accidentally
referencing incorrect globals.
The implementation's original placement in eval-with-debugger for instance
was accidentally pulling Reflect from resource://gre/modules/reflect.jsm
because that file also makes use of `Reflect.parse`. Rather than try to
keep it in that file and rename things, placing the list in its own
lazy-loaded file seems like the easiest and most future-proof approach.
Differential Revision: https://phabricator.services.mozilla.com/D65466
--HG--
extra : moz-landing-system : lando
This patch is in 2 folds:
- The first one sets a specific url option in evalWithDebugger when an eager evaluation is requested.
- Then in console-service, we block any message that has this specific sourceName, as it indicates it was triggered by the eager evaluation.
A test is added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D63663
--HG--
extra : moz-landing-system : lando
The SpiderMonkey Debugger API maintains a flag per-debuggee that tracks whether
the SpiderMonkey should notify the debugger when new frames are entered, and
whether the JIT scripts associated with the debuggee realm have been compiled
with debug instrumentation. To avoid constantly needing to clear and regenerate
JIT scripts, the flag is permanently enabled once "onEnterFrame" has been used
with a given Debugger instance, and when the flag is enabled, there is a
runtime performance cost.
This runtime cost is what is causing the performance regression here, so to
ensure that the flag is cleared at the end of a given instant-eval, we only
set "onEnterFrame" on a new temporary Debugger instance, instead of setting
it on th existing persistent Debugger instance.
Differential Revision: https://phabricator.services.mozilla.com/D64912
--HG--
extra : moz-landing-system : lando
renamed the console-progress.js/ConsoleProgressListener file and class to
console-file-activity.js/ConsoleFileActivityListener.
Differential Revision: https://phabricator.services.mozilla.com/D63672
--HG--
rename : devtools/server/actors/webconsole/listeners/console-progress.js => devtools/server/actors/webconsole/listeners/console-file-activity.js
extra : moz-landing-system : lando
This alsmo removes WebConsoleUtils.getPropertyDescriptor which
was only used in the pprint helper.
Differential Revision: https://phabricator.services.mozilla.com/D61985
--HG--
extra : moz-landing-system : lando
Julian Descottes
Kris Maglione
Nicolas Chevobbe
Daisuke Akatsuka
Dorel Luca
Samarjeet
Logan Smyth
Tooru Fujisawa
Alexandre Poirot
Csoregi Natalia
Oriol Brufau
Emily McDonough
Daniel Varga
Jason Laster
Ed Lee
Ciure Andrei
Surya Shankar