The existing setting was added to control grouping similar warning messages.
Due to the wording of the setting, users were also thinking it could control
repeated messages (the small badge/bubble we put next to messages when successibe
messages have the same text).
This patch renames the warning group pref into something that can drive both of
these, and we make the repeat mechanism check the value of the pref befor repeating.
Note that for repeated message, unlike warning groups, this doesn't "ungroup"
the messages, but that should be fine like this.
A node test case is added, as well as a mochitest (event though the test was already
checking repeated messages in a specific context, it's still nice to have
some basic actual coverage)
Differential Revision: https://phabricator.services.mozilla.com/D257841
Lets start triggering updates at certain keypoint in the cycle instead
batching into one update at the end.
This should depend on mechanisim for throttling resources so as not to spam the
frontend with lots of updates
Differential Revision: https://phabricator.services.mozilla.com/D247424
The enhancer was brittle as nothing was waiting for its completion.
We should rather do such work from the action layer. At least this can delay the action completion,
which the test header (setFilterState) already wait for.
Differential Revision: https://phabricator.services.mozilla.com/D205602
The enhancer was brittle as nothing was waiting for its completion.
We should rather do such work from the action layer. At least this can delay the action completion,
which the test header (setFilterState) already wait for.
Differential Revision: https://phabricator.services.mozilla.com/D205602
The enhancer was brittle as nothing was waiting for its completion.
We should rather do such work from the action layer. At least this can delay the action completion,
which the test header (setFilterState) already wait for.
Differential Revision: https://phabricator.services.mozilla.com/D205602
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
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 introduces functionality to support disabling weconsole messages.
Also introduces code to disable all network messages, which would be
used by the netmonitor.
You'll probably need the fullstack of patches to test easily
Will add mochitest in a followup
Differential Revision: https://phabricator.services.mozilla.com/D149753
In the console we might receive messages that need to be inserted at a specific
position in the output to respect the chronological order.
This is very visible when evaluating an expression in the console while we are
fetching cached messages, or when the expression is logging lots of messages, since
the evaluation result doesn't go through the ResourceCommand itself.
Since we were relying on the order of insertion in `mutableMessagesById` for the
order of messages in the output, we had no choice but clone the Map to insert
the new message at the specific position.
With lots of messages, this can be utterly slow, and is something people are experiencing.
To fix this, we're adding a new state property, `mutableMessagesOrder`, which holds
message ids in the chronological order. It's then used to compute `visibleMessages`.
As we don't have to clone the Map anymore, it makes reordering as fast as looking
for an index in the array and splicing it (which is fast).
We also take this opportunity to switch away from our `findIndex` usage; most often
than not, the messages will be reinserted at the end of the array, so we can loop
through it backward to find the index faster.
We still keep `mutableMessagesById` as a Map so lookup are fast, and we don't have
to deal with impacts we'd have if we'd switch to an object.
The existing node test helper to get a message at a specific index are migrated
to make use of `mutableMessagesOrder`, and a few test cases and assertions are
added to check that the new property is handled correctly.
Differential Revision: https://phabricator.services.mozilla.com/D148658
The property is renamed, prefixed with `mutable` to better highlight that it is
special; the associated selector is renamed as well.
The only change necessary was adding a `messageCount` prop to the `ConsoleOutput`
component so its lifecycle method could check if the number of messages changed.
Differential Revision: https://phabricator.services.mozilla.com/D138293
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
It could happen that 2 warning group messages could be added successively, before
the navigation message was emitted.
In the reducer, the second message would be seen the same as the first one, and
we'd try to increment the repeat count for the first one.
Unfortunately, the code was expecting a warning group to be created, and there
was an exception thrown as we couldn't retrieve it.
This is fixed by not allowing warning groups to be repeated.
A mocha test is added instead of a mochitest, as the issue would have been tricky
to trigger properly.
Differential Revision: https://phabricator.services.mozilla.com/D113276
Bug 1440068 - Fix filtering on console groups.
implement more thorough check of collapsed group messages
expand test suite
Differential Revision: https://phabricator.services.mozilla.com/D91065
This help modifying redux state only once and prevent many uncesarry copies of the whole messages/network events Maps.
This will also later help getting rid of WebConsoleWrapper throttling in favor of upcoming ResourceWatcher one,
as we could call only one action from onResourceAvailable/Updated.
Differential Revision: https://phabricator.services.mozilla.com/D90367
This help modifying redux state only once and prevent many uncesarry copies of the whole messages/network events Maps.
This will also later help getting rid of WebConsoleWrapper throttling in favor of upcoming ResourceWatcher one,
as we could call only one action from onResourceAvailable/Updated.
Differential Revision: https://phabricator.services.mozilla.com/D90367
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
When remote-debugging a device, it might happen that the device clock
is not exactly at the same time as the client clock. In such case, we
may end up in cases where the result of a command as an older timestamp,
which means we could have in the console output a result that was displayed
before the command message that triggered it.
In order to fix this, we add a `startTime` property on the evaluateJSAsync
response, that we can then check on the client. If the server time is
older than the client time, then we remove the existing command message
and add a new one, with the server timestamp.
We could have waited the result of the command before displaying the
command message (so we don't have to add a message, and then remove it
when the timestamps don't match), but the UI wouldn't feel snappy, and
even worse in case of long execution times (e.g. a top-level await fetch command).
Differential Revision: https://phabricator.services.mozilla.com/D72705
When remote-debugging a device, it might happen that the device clock
is not exactly at the same time as the client clock. In such case, we
may end up in cases where the result of a command as an older timestamp,
which means we could have in the console output a result that was displayed
before the command message that triggered it.
In order to fix this, we add a `startTime` property on the evaluateJSAsync
response, that we can then check on the client. If the server time is
older than the client time, then we remove the existing command message
and add a new one, with the server timestamp.
We could have waited the result of the command before displaying the
command message (so we don't have to add a message, and then remove it
when the timestamps don't match), but the UI wouldn't feel snappy, and
even worse in case of long execution times (e.g. a top-level await fetch command).
Differential Revision: https://phabricator.services.mozilla.com/D72705
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
Lorenz A