DevTools: fix ViewportControl's text selection logic

DevTools: fix ViewportControl's text selection logic

ViewportControl's _selectedText currently does this:
1 - get a selection+range with native window/shadowRoot.getSelection()
2 - calculate first and last viewport items that are part of the selection
3 - get the deepTextContent() of all those items
4 - trim out text based on the offsets provided by the selection

Step 4 is done by _textOffsetInNode(), which takes an itemElement, container,
and offset. Beforethis CL, it would start at the item and traverse all text
nodes until it stops at the container (node !== container). In this logic, it
assumes that the container is a text node itself so that (node !== container)
will be false and we will stop before counting the container's text length. In
reality, a user can drag to create a selection where the
range.start/endContainer can be an element that is not a text node (e.g. <span>
containing a text node). Then, _textOffsetInNode() would continue to traverse
and node.traverseNextTextNode() will never return a node that is === container.
This results in extra text length being counted which breaks the offset logic.

This CL makes sure that in those cases where the range.start/endContainer is not
a text node, such as a <span> containing the boundary text, we will stop
traversing when we hit a text node that is the end or is a descendant.

BUG=647287
Committed: https://crrev.com/1aee657f2d27df3cad42453428b527f592d29885
Cr-Commit-Position: refs/heads/master@{#419227}

[luoe, 2016-09-15 17:00:40]

Description was changed from

==========
fix selection text

BUG=
==========

to

==========
DevTools: fix ViewportControl's text selection logic

ViewportControl's _selectedText currently does this:
1 - get a selection+range with native window/shadowRoot.getSelection()
2 - calculate first and last viewport items that are part of the selection
3 - get the deepTextContent() of all those items
4 - trim out text based on the offsets provided by the selection

Step 4 is done by _textOffsetInNode(), which takes an itemElement, container,
and offset. Beforethis CL, it would start at the item and traverse all text
nodes until it stops at the container (node !== container). In this logic, it
assumes that the container is a text node itself so that (node !== container)
will be false and we will stop before counting the container's text length. In
reality, a user can drag to create a selection where the
range.start/endContainer can be an element that is not a text node (e.g. <span>
containing a text node). Then, _textOffsetInNode() would continue to traverse
and node.traverseNextTextNode() will never return a node that is === container.
This results in extra text length being counted which breaks the offset logic.

This CL makes sure that in those cases where the range.start/endContainer is not
a text node, such as a <span> containing the boundary text, we will stop
traversing when we hit a text node that is the end or is a descendant.

BUG=647287
==========

[luoe, 2016-09-15 17:01:24]

luoe@chromium.org changed reviewers:
+ lushnikov@chromium.org

[luoe, 2016-09-15 17:01:25]

PTAL

[lushnikov, 2016-09-15 17:38:19]

can we add a few tests for this?

[luoe, 2016-09-16 01:10:32]

Test added for selection when the base/extent is not a text node.

[luoe, 2016-09-16 01:10:44]

PTAL

[lushnikov, 2016-09-16 16:43:53]

lgtm

please, make sure the test fails without your fix

[luoe, 2016-09-16 17:22:51]

Thanks!  Yes, on the old node !== container, running the test selects 2 full
lines instead.

[luoe, 2016-09-16 17:22:58]

The CQ bit was checked by luoe@chromium.org

[commit-bot: I haz the power, 2016-09-16 17:23:36]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-16 18:36:05]

Description was changed from

==========
DevTools: fix ViewportControl's text selection logic

ViewportControl's _selectedText currently does this:
1 - get a selection+range with native window/shadowRoot.getSelection()
2 - calculate first and last viewport items that are part of the selection
3 - get the deepTextContent() of all those items
4 - trim out text based on the offsets provided by the selection

Step 4 is done by _textOffsetInNode(), which takes an itemElement, container,
and offset. Beforethis CL, it would start at the item and traverse all text
nodes until it stops at the container (node !== container). In this logic, it
assumes that the container is a text node itself so that (node !== container)
will be false and we will stop before counting the container's text length. In
reality, a user can drag to create a selection where the
range.start/endContainer can be an element that is not a text node (e.g. <span>
containing a text node). Then, _textOffsetInNode() would continue to traverse
and node.traverseNextTextNode() will never return a node that is === container.
This results in extra text length being counted which breaks the offset logic.

This CL makes sure that in those cases where the range.start/endContainer is not
a text node, such as a <span> containing the boundary text, we will stop
traversing when we hit a text node that is the end or is a descendant.

BUG=647287
==========

to

==========
DevTools: fix ViewportControl's text selection logic

ViewportControl's _selectedText currently does this:
1 - get a selection+range with native window/shadowRoot.getSelection()
2 - calculate first and last viewport items that are part of the selection
3 - get the deepTextContent() of all those items
4 - trim out text based on the offsets provided by the selection

Step 4 is done by _textOffsetInNode(), which takes an itemElement, container,
and offset. Beforethis CL, it would start at the item and traverse all text
nodes until it stops at the container (node !== container). In this logic, it
assumes that the container is a text node itself so that (node !== container)
will be false and we will stop before counting the container's text length. In
reality, a user can drag to create a selection where the
range.start/endContainer can be an element that is not a text node (e.g. <span>
containing a text node). Then, _textOffsetInNode() would continue to traverse
and node.traverseNextTextNode() will never return a node that is === container.
This results in extra text length being counted which breaks the offset logic.

This CL makes sure that in those cases where the range.start/endContainer is not
a text node, such as a <span> containing the boundary text, we will stop
traversing when we hit a text node that is the end or is a descendant.

BUG=647287
==========

[commit-bot: I haz the power, 2016-09-16 18:36:06]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-09-16 18:38:33]

Description was changed from

==========
DevTools: fix ViewportControl's text selection logic

ViewportControl's _selectedText currently does this:
1 - get a selection+range with native window/shadowRoot.getSelection()
2 - calculate first and last viewport items that are part of the selection
3 - get the deepTextContent() of all those items
4 - trim out text based on the offsets provided by the selection

Step 4 is done by _textOffsetInNode(), which takes an itemElement, container,
and offset. Beforethis CL, it would start at the item and traverse all text
nodes until it stops at the container (node !== container). In this logic, it
assumes that the container is a text node itself so that (node !== container)
will be false and we will stop before counting the container's text length. In
reality, a user can drag to create a selection where the
range.start/endContainer can be an element that is not a text node (e.g. <span>
containing a text node). Then, _textOffsetInNode() would continue to traverse
and node.traverseNextTextNode() will never return a node that is === container.
This results in extra text length being counted which breaks the offset logic.

This CL makes sure that in those cases where the range.start/endContainer is not
a text node, such as a <span> containing the boundary text, we will stop
traversing when we hit a text node that is the end or is a descendant.

BUG=647287
==========

to

==========
DevTools: fix ViewportControl's text selection logic

ViewportControl's _selectedText currently does this:
1 - get a selection+range with native window/shadowRoot.getSelection()
2 - calculate first and last viewport items that are part of the selection
3 - get the deepTextContent() of all those items
4 - trim out text based on the offsets provided by the selection

Step 4 is done by _textOffsetInNode(), which takes an itemElement, container,
and offset. Beforethis CL, it would start at the item and traverse all text
nodes until it stops at the container (node !== container). In this logic, it
assumes that the container is a text node itself so that (node !== container)
will be false and we will stop before counting the container's text length. In
reality, a user can drag to create a selection where the
range.start/endContainer can be an element that is not a text node (e.g. <span>
containing a text node). Then, _textOffsetInNode() would continue to traverse
and node.traverseNextTextNode() will never return a node that is === container.
This results in extra text length being counted which breaks the offset logic.

This CL makes sure that in those cases where the range.start/endContainer is not
a text node, such as a <span> containing the boundary text, we will stop
traversing when we hit a text node that is the end or is a descendant.

BUG=647287

Committed: https://crrev.com/1aee657f2d27df3cad42453428b527f592d29885
Cr-Commit-Position: refs/heads/master@{#419227}
==========

[commit-bot: I haz the power, 2016-09-16 18:38:34]

Patchset 3 (id:??) landed as
https://crrev.com/1aee657f2d27df3cad42453428b527f592d29885
Cr-Commit-Position: refs/heads/master@{#419227}