Don't clone the whole message we receive as a result of a console API call, but select
properties that are being used on the client.
As a result, we're not sending some properties anymore (`functionName`, `addonId`, `workerType`),
and we also don't include some properties when they are falsy and wouldn't bring
any benefit (`counter`,`timer`, `private`, `prefix`, `stacktrace`)
Hopefully this helps save some cycle since we're not cloning an object, but also in the
JSActor communication since the packet we need to send is smaller.
We do similar changes to the webconsoleActor method, which is still used in non
fission scenarios, and remove WebConsoleUtils.cloneObject which is no longer used.
Differential Revision: https://phabricator.services.mozilla.com/D139686
This new method is being used in DevTools code to replace the usage
that was made of `getOwnPropertyNames` only to retrieve the length
property of the returned array.
Differential Revision: https://phabricator.services.mozilla.com/D139709
This test does a bunch of assertions for a series of events which
is complex and not reliable. It also becomes overly complicated when
Fission is enabled. Looks like this test isn't really needed, so
we are removing it.
Differential Revision: https://phabricator.services.mozilla.com/D139604
This patch is introducing the machinery to automatically generate/check some
stubs used by Reps.
We're focusing on stubs that shouldn't be represented by a front as it's easier
to deal with; we should then have follow up and incremental patches for each
stubs.
Some data can't be retrieved after being serialized/deserialized (`-0`, unsafe int, …),
and in such case the associated test was modified to directly pass the object.
Differential Revision: https://phabricator.services.mozilla.com/D139933
This patch is introducing the machinery to automatically generate/check some
stubs used by Reps.
We're focusing on stubs that shouldn't be represented by a front as it's easier
to deal with; we should then have follow up and incremental patches for each
stubs.
Some data can't be retrieved after being serialized/deserialized (`-0`, unsafe int, …),
and in such case the associated test was modified to directly pass the object.
Differential Revision: https://phabricator.services.mozilla.com/D139933
This version is as simple as I can make it. It simply expects the JS
debugger to stop on the breakpoint added automatically by the
backgroundtask debugger command line processing (using
`setBreakpointOnLoad`) and disconnects, expecting the task to continue
execution and exit with exit code 0.
In the future, we'd like to interact with the task environment, for example to:
1. stop on the automatic breakpoint
2. continue
3. stop on a `debugger;`
4. set the task's exit code from a failure code to exit code 0
5. continue
6. verifies the tasks's exit code is 0.
Sadly my attempts to do this fail intermittently in automation.
Differential Revision: https://phabricator.services.mozilla.com/D139156
Background task mode is roughly equivalent to `xpcshell`, but inside
the regular browser startup flow. There is no browser window (no
`Window` at all) and there should be no content processes. It's
sufficient to treat it like `xpcshell`, with its own stripped-down
actor and a few tweaks to the integration points.
The structural changes in this commit keep `--backgroundtask` mode
slim in the regular case when the Devtools are *not* requested. This
is reflected in the small changes needed to the
`browser_xpcom_graph_wait.js` test: loading the Devtools
unconditionally causes a huge amount of code to be loaded. In order
to load the Devtools framework conditionally, we check for
Devtools-specific command line flags and delegate to Devtools when
appropriate. In order to check the command line flags, we turn the
`BackgroundTasksManager` into an XPCOM service, which allows it to be
instantiated by XPCOM in order to handle the command line.
One final note: this leaves two XPCOM components, "backgroundtasks"
and "backgroundtasksmanager". Why not combine them? This is
technically possible but not attractive: we really do want a natural
place for native/C++ code ("backgroundtasks") and JavaScript code
("backgroundtasksmanager").
Differential Revision: https://phabricator.services.mozilla.com/D129771
We may get multiple lines or incomplete lines from the pipe, so we
need to split the data and keep the leftover. This simply makes
debugging a little more pleasant.
Differential Revision: https://phabricator.services.mozilla.com/D139155
We do create dedicated targets for frame documents, but
in isFrameWithChildTarget, we were only checking if the
passed element was an iframe, making some area of the code
not behaving correctly (e.g. using the node picker, or
the Inspect Element context menu entry).
This patch fixes this and add a test case to make sure we
don't regress.
Differential Revision: https://phabricator.services.mozilla.com/D140041
No significant gain to expect as we are mostly moving things around, but this could reduce the confusion around the debugger.
Differential Revision: https://phabricator.services.mozilla.com/D138759
This test does a bunch of assertions for a series of events which
is complex and not reliable. It also becomes overly complicated when
Fission is enabled. Looks like this test isn't really needed, so
we are removing it.
Differential Revision: https://phabricator.services.mozilla.com/D139604
We only need to store the id and status of the selected browsers
for the inspector.
Functions from compatibility-user-settings are renamed to better
convey what they are actually doing, and JSDoc is added to make
everything more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D139394
A number of tests (and expectations) are updated here to either avoid
accidentally relying on the size of Courier New on Windows, or to
explicitly use Courier New instead of monospace, where it's harder to
work out how to rewrite the test correctly.
Differential Revision: https://phabricator.services.mozilla.com/D87222
This changeset adds a NotificationBox to the ResponsePanel that notifies
users that a XSSI string was removed. This NotificationBox is only
displayed when the user is viewing parsed JSON using properties view.
Furthermore, when XSSI stripped characters are detected the ResponsePanel
will default to raw view.
Depends on D115442
Differential Revision: https://phabricator.services.mozilla.com/D115573
This fix makes sure that only valid XSSI prevention sequences are removed
from JSON payloads. Before, any string prepending the JSON payload was
removed which meant malformed JSON could still be displayed in properties
view as if it was valid which confused users.
Differential Revision: https://phabricator.services.mozilla.com/D115442
This adds thread information to sources (generated, original and pretty-printed-original), tabs and breakpoints
as its already done with source actors. This will make it easy to apply retrieve and cleanup these resources
based on their thread info without having to do a lot of work. Might help improve perfomance is some of
the complex selectors.
Differential Revision: https://phabricator.services.mozilla.com/D139810
We only need to store the id and status of the selected browsers
for the inspector.
Functions from compatibility-user-settings are renamed to better
convey what they are actually doing, and JSDoc is added to make
everything more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D139394
We only need to store the id and status of the selected browsers
for the inspector.
Functions from compatibility-user-settings are renamed to better
convey what they are actually doing, and JSDoc is added to make
everything more explicit.
Differential Revision: https://phabricator.services.mozilla.com/D139394
There was this unique check against non-breakable lines.
browser_dbg-breakable-lines.js now test this much more in depth.
This old unique assertion is not worth keeping.
Differential Revision: https://phabricator.services.mozilla.com/D139481