After the previous commit, we're now starting network listening at a different
point in toolbox startup. We need to rework some test expectations to account
for the new timing.
MozReview-Commit-ID: 1lNDE51uVPS
--HG--
extra : rebase_source : 331c2c5ce411f2f11152a5d80935bcc3b65154bd
Once upon a time (bug 862341), we decided to enable network listening by
default in DevTools.
In a general sense, that's fine. When you open a toolbox, we listen to that
tab and stop listening when the toolbox closes.
GCLI / Developer Toolbar is quite different, though. It connects to the whole
browser. This meant that enabling GCLI would start listening to network
activity in *every* tab (even though it doesn't have any way to even use that
data). This of course will slow down performance with all the extra tracking
and eat up memory with the tracked request data.
In this change, we move the step to enable network listening into the toolbox,
which seems more like what we intended anyway.
MozReview-Commit-ID: 2UYoQtWCAE1
--HG--
extra : rebase_source : 22545d1b47d73e43eec3407ce25f056bc8ef200f
The call to scrollToBottom could take a good amount of time if there were
already logged messages in the console. This might be related to the fact that
componentDidMount is called although there is some layout or paint work.
Delaying the first call to scrollToBottom in the component greatly reduced the
time spent in scrollToBottom.
MozReview-Commit-ID: F3cRYV4OFhm
--HG--
extra : rebase_source : 7be84aeadd33e5c57131b35da2dea5e7bc3611b0
Removes support for old versions of ADB Helper which haven't been in use for
years.
It also removes `test_telemetry` because it referenced this code and is also
disabled for all configurations in a product we intend to remove.
MozReview-Commit-ID: AUAbwxVczWb
--HG--
extra : rebase_source : 9c6de560a08c97b7a1bca7b2c52e111bf78fe5e4
Tests custom styles on both console.group and console.groupCollapsed messages.
Update the stubs to match what the server now returns.
MozReview-Commit-ID: KHhU8Ki0YUz
--HG--
extra : rebase_source : 6f3766f9bb49d677a8f90adc0e8db7c34fa9e8bb
Because we now enable custom styling on console.group, we can't rely solely on groupName
to output the group. We can have multiple pieces on which to apply different styles, like
for console.log, so we use the same properties to have the same behavior for custom styles.
MozReview-Commit-ID: 7IKl919Dg7a
--HG--
extra : rebase_source : 770af4e62eaa779cab75179ed9789c4b102cb4d6
The inspector's DocumentWalker had several issues when trying to retrieve
children for a given node, especially if the starting node was filtered
out by the filter function of the walker.
If the starting node was provided by options.center or options.start
and if this starting node was filtered out by the walker's filter
then the walker would fallback to the first valid parent of this node.
eg with
parent1 > parent2 > [valid-node, invalid-node, valid-node]
When asking for the children of parent2, if the walker started on
"invalid-node", then the walker would instead use parent2 and in turn
we would retrieve the children of parent 1
To fix that we can either tell the walker wether it should fallback to a
sibling of the starting node or to a parent, or make sure that the nodes
provided to the walker are valid.
A second issue was with the utility methods _readForward and _readBackward.
They both use the next/previousSibling() methods of a walker in order to
collect all the valid siblings of the walker's current node. But they were
always including the current node of the walker in their return array. And
there is no guarantee that the walker's currentNode is actually valid for it's
filter.
eg with a walker containing [invalid-node-1, invalid-node-2, valid-node].
Let's say the walker is currently on valid-node and we call previousSibling
The walker will do 3 steps:
- this.walker.previousSibling() > returns invalid-node-2, fails filtering
- this.walker.previousSibling() > returns invalid-node-1, fails filtering
- this.walker.previousSibling() > returns null, stop looping and return null
But at this stage the internal walker still points to the last visited node
(invalid-node-1). So if _readForward/Backward blindly add the current node
of the walker, we might be returning invalid nodes.
MozReview-Commit-ID: 72Be7DP5ky6
--HG--
extra : rebase_source : 31e7d3321abef04243b741196d4ca6279cefd53a
Fred Lin
Jan Odvarko
Sebastian Hengst
Iris Hsiao
Wes Kocher
Ricky Chien
Vangelis Katsikaros
J. Ryan Stinnett
Eugen Sawin
Gabriel Luong
nchevobbe
Julian Descottes
Patrick Brosset
Locke Chen
sole
Alessio Placitelli
ehmpee
Xidorn Quan
Ryan VanderMeulen
Christoph Kerschbaumer
Ruturaj K. Vartak
Phil Ringnalda
Mark Striemer
Micah Tigley
Jonathan Hao