The patch of bug 1353005 removed by mistake a leading dot in a css class, and
the `encodeURIComponent` calls (so the # in the color definition was considered
the hash part in the url).
Also, it appears autoland rejected the last commit from Bug 1353005, so this
patch includes those changes as well.
MozReview-Commit-ID: 2aVW3hYHhSr
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
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
This patch doesn't currently work. The test fails in two test cases. Right now the styles for a 'locked-off' psuedo class are still being applied.
MozReview-Commit-ID: DppYTmILpwy
* * *
[mq]: temp
MozReview-Commit-ID: 74iIOQumfrw
DevRel have made it clear that one of the number one complaints they hear is that we are not supporting React in our tools.
So how about we have our event bubbles include React events and allow people to go to the event listener source in the debugger?
I don't believe that any other tool does this so it is totally worth doing... and in time for Christmas as well ;)
Works just fine in development and production versions of React.
It also works in the browser toolbox so it can be used to debug events in our own tools e.g. The Debugger.
The files under devtools/client/inspector/markup/test/ are either test or React library files so they only really need a cursory glance.
This means that you should focus on the following files when reviewing:
- devtools/client/locales/en-US/inspector.properties
- devtools/client/shared/widgets/tooltip/EventTooltipHelper.js
- devtools/server/actors/inspector.js
- devtools/server/event-parsers.js
Now allowed the use of JSX in mochitests and fixed all eslint errors.
MozReview-Commit-ID: AtxhainieQe
Ever since protocol.js was added as a way to create DevTools actors, we've had
lots of confusion about the correct way to implement actor destruction. If your
actor's _parent_ was the legacy kind, you had to use `disconnect`. If it was
protocol.js, you had to use `destroy`.
There is no reason for this madness, which makes reasoning about destruction
quite hard. Here we rename `disconnect` to `destroy` so there is only one name
for every destruction path.
MozReview-Commit-ID: C1Yw9NfUUR2
When the inspector actor walks the DOM in order to find nodes to be
displayed in the inspector panel, it ignores text nodes that contain
only whitespace characters (in order to avoid cluttering the panel with
useless information).
This commit changes this logic so that whitespace text nodes are only
ignored when the node in fact has no layout at all (all text collapsed).
Inside inline formatting contexts, whitespace text nodes may have layout
and therefore push elements further apart. So seeing these nodes in the
panel actually help debugging issues.
MozReview-Commit-ID: GvNMsqsT3w6
