We still need to keep the page error stubs because they're used in other tests,
but we remove all the ones that were solely used in pageError.js
Differential Revision: https://phabricator.services.mozilla.com/D230517
This should allow the number of hidden messages to be notified to
screen reader users.
We update the Console FilterBar behavior to always show the "X hidden" message
when the input is focused, so screen reader can also pick up when no messages
are hidden.
Differential Revision: https://phabricator.services.mozilla.com/D213181
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
Instead of rendering the cropped URL, we split the URL in 3 parts, so the full
URL text will be in the DOM, but we visually hide the middle part and replace
it with an ellipsis.
This way copying the message will still put the full URL in the clipboard.
A test case is added to ensure this works as expected.
Differential Revision: https://phabricator.services.mozilla.com/D165805
This makes the console behave like the other React panels.
We can also get rid of the specific bits for mocha in devtools-node-test-runner.js
Differential Revision: https://phabricator.services.mozilla.com/D167233
This was only _not_ rendering when `terminalEagerResult` was `null`, but with
Bug 1776376, we're getting `undefined` results in some case, which was crashing
the component.
While this should be fixed at an upper level, this patch makes the component a bit
more robust so we don't crash the whole console client.
A node test is added for basic rendering with various result values, and proper
mochitest will be added in follow-up patches in this queue.
Differential Revision: https://phabricator.services.mozilla.com/D152161
This should be ready to review. However, I will include a big caveat that I
tried to do things the Reacty way, and it felt really awkward. Notably, I used
a React functional component, because they seem to be recommended as the
Right Way to do things, but because of all the state we need to keep track of,
as well as just the props that we don't want to lexically access because then
they can be stale, it felt really wrong. Guidance is welcome.
However, the core logic should be ready for review, so focus on that, and let
me know if I need to move anything around to make it more palatable.
Depends on D138030
Differential Revision: https://phabricator.services.mozilla.com/D138031
In order to store the matching elements of a CSS warnings, we were having a quite
generic `MESSAGE_UPDATE_PAYLOAD` action and `messagesPayloadById` property in the store.
This was used at some point to also store console.table data (which was retrieved
asynchronously), but is no longer true.
In this patch, we rename the action, property, selector, props and variable that
were using this to make it more specific to the CSS warning matching elements.
We also, directly pass message to messageGetMatchingElements as the component
calling the action already had access to it.
Tests that were using the action are updated so they're about CSS warnings (and
not console.table).
Differential Revision: https://phabricator.services.mozilla.com/D138412
The error message seems to be different in Nighly and Beta,
but I wasn't able to find any pref that is driving this.
Since the error message itself isn't super relevant, and given
that we're at the end of the cycle, this patch is only modifying
the expression so we get a different error.
Differential Revision: https://phabricator.services.mozilla.com/D119520
Surprisingly, there is no issue with ResourceWatcher cache,
but only with the WebConsoleWrapper which gets its inner cache purged.
Differential Revision: https://phabricator.services.mozilla.com/D112232
This way we ensure that any microtask created by the evaluated expression are
run, which can impact what we send to the client (e.g. `Promise.resolve().then(() => 246)`
will show a resolved promise instead of a pending one).
Some stubs and node tests are added to ensure this does fix the issue.
Differential Revision: https://phabricator.services.mozilla.com/D100979
Now that the l10n module handles node environment, we no
longer need the existing fixtures for the mocha tests.
A couple tests needed to be updated to pass.
Depends on D94570
Differential Revision: https://phabricator.services.mozilla.com/D94571
This patch migrates to using the Resource Watcher API to handle Network events, it adds a legacy listeners for the network events
Differential Revision: https://phabricator.services.mozilla.com/D71543
This patch migrates to using the Resource Watcher API to handle Network events, it adds a legacy listeners for the network events
Differential Revision: https://phabricator.services.mozilla.com/D71543
This patch adds a mochitest that will be responsible to
generate and update platform messages stubs, which is what
we already have for all the other type of resources we handle
in the console.
This means the mocha test asserting the rendering of platform
messages can use those stubs instead of hand-written stubs we
have at the moment.
This patch also adds a `getCurrentTestFilePath` function in shared-head.js,
which we then use in the different stub generators.
We also use CHROME_URL_ROOT to require the stub-generator-helpers file.
Differential Revision: https://phabricator.services.mozilla.com/D77216
Now that nsIScriptError have a `isPromiseRejection` flag, we can consume it
in the console to indicate to the user that we're dealing with a promise rejection.
The exception message is then: "Uncaught (in promise) XXX".
A few tests needed to be updated, and we take this as an opportunity to
ensure we have a stacktrace for uncaught promise rejection.
Differential Revision: https://phabricator.services.mozilla.com/D75780
There was no benefit of having cached messages being different from the "live" ones,
so in this patch we make the message packet consistent.
A few tests had to be modified, and we still handle old-style cached
messages for backward compatibility.
Differential Revision: https://phabricator.services.mozilla.com/D75089
This patch use the new `exception` and `hasException` field from nsIScriptError
so we can render the actual object in the message error instead of a stringified
version.
Error object are still displayed using the `customFormat` prop, so we display
only the type + message + stacktrace (but we'll have a way to inspect them
in the sidebar soon).
Existing tests were updated to fix failures, and some tests/test cases were
added to make sure we cover all the different kind of errors we can display
in the console.
Differential Revision: https://phabricator.services.mozilla.com/D71288
This patch use the new `exception` and `hasException` field from nsIScriptError
so we can render the actual object in the message error instead of a stringified
version.
Error object are still displayed using the `customFormat` prop, so we display
only the type + message + stacktrace (but we'll have a way to inspect them
in the sidebar soon).
Existing tests were updated to fix failures, and some tests/test cases were
added to make sure we cover all the different kind of errors we can display
in the console.
Differential Revision: https://phabricator.services.mozilla.com/D71288
Since we're going to re-order the packets in the webconsole messages
reducer based on the messages timestamps, the node tests are going
to fail, as stubs timeStamps are generated and we don't have much
control on them.
Assigning the same timestamp means we'll defer to order based on the
message id, which should follow the order of insertion. The only exception
is network messages, where the id needs to be the actor, which is a string.
For the tests that are using network messages and assert some order, we
simply reassign the timestamps so we can guarantee the order.
Differential Revision: https://phabricator.services.mozilla.com/D69966
Alexandra Borovova