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 is generated by the following sed script:
find . ! -wholename '*/.hg*' -type f \( -iname '*.html' -o -iname '*.xhtml' -o -iname '*.xul' -o -iname '*.js' \) -exec sed -i -e 's/\(\(text\|application\)\/javascript\);version=1.[0-9]/\1/g' {} \;
MozReview-Commit-ID: AzhtdwJwVNg
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
Add package.json to devtools/client/inspector
Integration with devtools-local-toolbox:
- provides development server
- default webpack config
- landing page to select a tab
In this patch:
- bin/dev-server-js contains the inspector specific routes
- webpack/*-sham.js : inspector dependencies that had to be mocked
ideally, decoupling work should continue and the inspector client
should only ever require files that require no chrome priviledged
APIs.
- toolbox.js contains the interface with devtools-local-toolbox bootstrap
and the inspector panel initialization
- configs/development.json is the inspector config for the devtools-local-toolbox
MozReview-Commit-ID: 7YQLUlgSyDX
This changes the behavior of the element picker so that when it is
cancelled the previously selected DOM node is re-scrolled into view.
Additionally the existing behavior of the keyboard shortcuts for the
element picker was broken when the devtools toolbox was docked. The main
content area was not being focused, so the keyboard shortcuts for the
element picker were not being used. When the toolbox is detached, the
focus event is still not fired, as it's not desirable to have the
content pop into view over the devtools.
Finally there is now an additional implementation of the Escape shortcut
when the devtools are focused. The console Escape shortcut is ignored
until the element picker has been disabled making disabling the element
picker consistent irrelevant of the context.
MozReview-Commit-ID: HxENmPBoTcD
