Bug 169570

Summary: Web Inspector: Selecting text in the console does not do what I expect
Product: WebKit Reporter: Saam Barati <sbarati>
Component: Web InspectorAssignee: Devin Rousso <drousso>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, drousso, inspector-bugzilla-changes, joepeck, mattbaker, nvasilyev, timothy
Priority: P2    
Version: WebKit Nightly Build   
Hardware: All   
OS: All   
Attachments:
Description Flags
before selection
none
after selection
none
Patch
none
[Image] title selection
none
[Image] weird selection
none
[Image] Long file name and objects
none
Patch none

Description Saam Barati 2017-03-13 15:25:37 PDT
Created attachment 304312 [details]
before selection

See attached images for more details.

On a Mac, I'm double clicking on my mouse on the number that reads "1174349873" and then copying the text using Cmd+c. However, when I copy it, I realized my selection is prepending the line number that the console.log happened from to the test, and I'm ending up with copied text that is "181174349873"
Comment 1 Saam Barati 2017-03-13 15:26:09 PDT
Created attachment 304313 [details]
after selection
Comment 2 Devin Rousso 2017-03-14 14:57:07 PDT
Created attachment 304433 [details]
Patch
Comment 3 Matt Baker 2017-03-15 12:28:14 PDT
Created attachment 304526 [details]
[Image] title selection

It's a little strange having the location title still be selectable, while the subtitle is not. Especially since it includes the pseudo-element.
Comment 4 Matt Baker 2017-03-15 12:28:56 PDT
Created attachment 304527 [details]
[Image] weird selection

With this patch, it is still possible to get unexpected selection behavior.
Comment 5 Matt Baker 2017-03-15 12:33:11 PDT
r- for now. I think the root of the problem is the ordering of the DOM that makes up the console message:

<div class="console-message">
    <div class="call-frame function-icon console-message-location">...</div>
    <span class="console-top-level-message console-message-text">...</span>
    <ol class="console-message-extra-parameters-container">...</ol>
</div>

The top-level message comes after the location.
Comment 6 Timothy Hatcher 2017-03-15 12:44:40 PDT
The root of the issue here is the DOM order as you mention. That order is needed because the location floats right. So do that it needs to come before the content that it floats beside.
Comment 7 Timothy Hatcher 2017-03-15 12:45:58 PDT
This is why I originally had the location and user-select: none. Nikita (IIRC) argued it should be selectable when he changed it.
Comment 8 Nikita Vasilyev 2017-03-15 13:20:02 PDT
Created attachment 304534 [details]
[Image] Long file name and objects

(In reply to comment #6)
> The root of the issue here is the DOM order as you mention. That order is
> needed because the location floats right. So do that it needs to come before
> the content that it floats beside.

Unfortunately, I don't know how to implement the current layout with the proper DOM elements order.

Consider the attached image.

If we used a two column layout, e.g. [console message | source link], selection would not be a problem. However, we wouldn't be able to display console messages spanning the whole width of the console.
Comment 9 Nikita Vasilyev 2017-03-15 13:21:10 PDT
(In reply to comment #7)
> This is why I originally had the location and user-select: none. Nikita
> (IIRC) argued it should be selectable when he changed it.

`user-select: none` is probably best fix at this point.
Comment 10 Devin Rousso 2017-03-15 16:42:49 PDT
Created attachment 304580 [details]
Patch
Comment 11 WebKit Commit Bot 2017-03-15 19:48:32 PDT
Comment on attachment 304580 [details]
Patch

Clearing flags on attachment: 304580

Committed r214024: <http://trac.webkit.org/changeset/214024>
Comment 12 WebKit Commit Bot 2017-03-15 19:48:36 PDT
All reviewed patches have been landed.  Closing bug.