| Summary: | Web Inspector: Selecting text in the console does not do what I expect | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Saam Barati <saam> | ||||||||||||||||
| Component: | Web Inspector | Assignee: | Devin Rousso <hi> | ||||||||||||||||
| Status: | RESOLVED FIXED | ||||||||||||||||||
| Severity: | Normal | CC: | commit-queue, hi, inspector-bugzilla-changes, joepeck, mattbaker, nvasilyev, timothy | ||||||||||||||||
| Priority: | P2 | ||||||||||||||||||
| Version: | WebKit Nightly Build | ||||||||||||||||||
| Hardware: | All | ||||||||||||||||||
| OS: | All | ||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
Created attachment 304313 [details]
after selection
Created attachment 304433 [details]
Patch
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.
Created attachment 304527 [details]
[Image] weird selection
With this patch, it is still possible to get unexpected selection behavior.
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.
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. This is why I originally had the location and user-select: none. Nikita (IIRC) argued it should be selectable when he changed it. 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. (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. Created attachment 304580 [details]
Patch
Comment on attachment 304580 [details] Patch Clearing flags on attachment: 304580 Committed r214024: <http://trac.webkit.org/changeset/214024> All reviewed patches have been landed. Closing bug. |
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"