New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 647287 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Sep 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug

Blocking:
issue 505177



Sign in to add a comment

DevTools: selecting stack trace text in console incorrectly captures next line

Project Member Reported by l...@chromium.org, Sep 15 2016

Issue description

Version: 53.0.2785.101

What steps will reproduce the problem?
(1) Open the Console in DevTools
(2) Type and evaluate 'throw 123'
(3) Type and evaluate any text (e.g. 'abc') to generate another log
(4) Expand the 'Uncaught 123' to reveal '(anonymous) @ WM:DD'
(5) Select the '(anonymous) @ WM:DD' by starting a drag from the right of the text to the left
(6) Paste the result somewhere

What is the expected output?
Copied text should be the '(anonymous) @ WM:DD' line

What do you see instead?
DevTools copies a '\n' + the next line instead (e.g. 'abc')


My guess is that ViewportControl's _selectedText() has a bug.
 
Project Member

Comment 1 by bugdroid1@chromium.org, Sep 16 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/1aee657f2d27df3cad42453428b527f592d29885

commit 1aee657f2d27df3cad42453428b527f592d29885
Author: luoe <luoe@chromium.org>
Date: Fri Sep 16 18:35:43 2016

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 

Review-Url: https://codereview.chromium.org/2340223002
Cr-Commit-Position: refs/heads/master@{#419227}

[modify] https://crrev.com/1aee657f2d27df3cad42453428b527f592d29885/third_party/WebKit/LayoutTests/inspector/console/console-viewport-selection-expected.txt
[modify] https://crrev.com/1aee657f2d27df3cad42453428b527f592d29885/third_party/WebKit/LayoutTests/inspector/console/console-viewport-selection.html
[modify] https://crrev.com/1aee657f2d27df3cad42453428b527f592d29885/third_party/WebKit/Source/devtools/front_end/ui/ViewportControl.js

Comment 2 by l...@chromium.org, Sep 21 2016

Blocking: 505177

Comment 3 by l...@chromium.org, Sep 21 2016

Status: Fixed (was: Started)

Sign in to add a comment