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 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
Adds a new `getRoot` request to the root actor which lists the global actors
only (leaving out the tabs). This is a much better fit for callers who want to
access some global actor only, since it avoids visiting every tab, which could
be a very expensive operation.
MozReview-Commit-ID: 1lIAuaV7zoF
--HG--
extra : rebase_source : bf64ee1298591f26ffa4c6a660cca52145084b66
node.isConnected (see https://dom.spec.whatwg.org/#dom-node-isconnected) returns true if the node is
in the DOM tree (including in a shadowDOM tree), which can be used in the frontend to display additional
tools and information.
MozReview-Commit-ID: LjUbkc7VPcB
--HG--
extra : rebase_source : b43644cf869663412a9ed6b956093e7a41afb01f
This adds higher level protection to ignore exited browser actors, so we don't
end up triggering methods like `form` on them, since they won't make much sense
anyway.
MozReview-Commit-ID: KgUCA04N2fY
--HG--
extra : rebase_source : 4dbf0dfe0a21755796625106840209bed0f9db82
A virtual canvas is basically a canvas that seems bigger than is actually is.
The technique consists in moving a fixed sized canvas during the scrolling, when
is needed, to give the illusion that it always covers the entire document.
MozReview-Commit-ID: Hp4cUZaBdm8
--HG--
extra : rebase_source : 536891732a6247103734d60f9d8720dc2131815f
This adds a new highlighter to our collection of highlighters.
This one is a simple overlay on top of the page and a message at the
top.
It will be used by the debugger to signal to users that script execution
is paused.
In later versions, the message at the top will also contain stepping and
resuming buttons.
MozReview-Commit-ID: JNGWrVjMzkm
--HG--
extra : rebase_source : 2006068b82f808c284aebe9f1f364970bda428c5
- Added `getViewportDimensions`
- Added `getComputedStylePropertyValue` to `CanvasFrameAnonymousContentHelper`
- Refactored totally `moveInfobar` to works with both APZ enabled and new
positioned absolutely highlighters
- Updated `AutoRefreshHighlighter` for having a `scrollUpdate` method.
- Updated tests
MozReview-Commit-ID: 5m31ZzRzLXr
--HG--
extra : rebase_source : c5abac64217ee0b86413594461fb6a50d5df655e
- Added `getViewportDimensions`
- Added `getComputedStylePropertyValue` to `CanvasFrameAnonymousContentHelper`
- Refactored totally `moveInfobar` to works with both APZ enabled and new
positioned absolutely highlighters
- Updated `AutoRefreshHighlighter` for having a `scrollUpdate` method.
- Updated tests
MozReview-Commit-ID: 5m31ZzRzLXr
--HG--
extra : rebase_source : 8c599a323ff51f1e032405fae47674b695c75b86
The display density is basically the line size, but we have to calculate the
`offest` for translation accordingly.
MozReview-Commit-ID: LVAWL8ZtkrU
--HG--
extra : rebase_source : 175a7aef06036856e2dfd52ac76e02c049608b6f
Added also a `getDisplayPixelRatio` method, since we're probably going to use it
more often, instead of doing this math all the time in the code, it will be more
clear.
MozReview-Commit-ID: HLtbwDBvbF6
--HG--
extra : rebase_source : aca60ea8c57e175c2cca5ff7ed478796c5b6c53f