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
The legacy performance path supports servers running Firefox 42 and earlier.
Now that Firefox OS is no longer supported, there's no reason to keep this
around.
MozReview-Commit-ID: K40e93VUjj9
--HG--
extra : rebase_source : ec2fbe68b7fe2f4d8e53b30d194dc026294b5f53
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 : 6230899f57b624ad8dd374f8f9e712f430acf9df
Wes Kocher
Ryan VanderMeulen
Christoph Kerschbaumer
nchevobbe
Ruturaj K. Vartak
Iris Hsiao
Phil Ringnalda
Mark Striemer
Micah Tigley
Gabriel Luong
Sebastian Hengst
Jonathan Hao
Julian Descottes
Ricky Chien
Fred Lin
J. Ryan Stinnett
Vangelis Katsikaros
Tim Nguyen
Mayank Srivastav
Florian Scholz