user-select: none on table data cell within selection emits multiple HTML tables
Categories
(Core :: DOM: Selection, defect, P3)
Tracking
()
People
(Reporter: hello, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
|
(deleted),
text/html
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.3 Safari/605.1.15
Steps to reproduce:
We run a CI platform which emits console log in HTML form, at the moment it uses HTML tables to keep these organised, with a column set aside for line numbers whose td elements have user-select: none applied in order to exclude it when copying.
Actual results:
In Firefox, the user-select: none elements cause the HTML copied to the clipboard to contain separate tables for each non-user-select: none td that was in the selection, and the final selection line outside a table, rather than one contiguous table:
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body><table><tbody><tr><td colspan="2" style="white-space: pre-wrap;">- group: "hello there"</td>
</tr>
<tr>
</tr></tbody></table><table><tbody><tr><td colspan="2" style="white-space: pre-wrap;"> steps:</td>
</tr>
<tr>
</tr></tbody></table> - command: echo "success!"</body></html>
Expected results:
In Edge and Chrome, selecting a set of lines in this file copies just fine, resulting in a single table element with several rows and columns:
<meta charset='utf-8'><table style="font-family: Times; letter-spacing: normal; orphans: 2; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;"><tbody><tr><td colspan="2" style="white-space: pre-wrap;">- group: "hello there"</td></tr><tr><td style="user-select: none; text-align: right; width: 20px;">3</td><td colspan="2" style="white-space: pre-wrap;"> steps:</td></tr><tr><td style="user-select: none; text-align: right; width: 20px;">4</td><td colspan="2" style="white-space: pre-wrap;"> - command: echo "success!"</td></tr></tbody></table>
In Safari, the formatting is slightly different, but the outcome is essentially the same:
<table style="caret-color: rgb(0, 0, 0); font-family: -webkit-standard; letter-spacing: normal; orphans: auto; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; text-decoration: none;"><tbody><tr><td colspan="2" style="white-space: pre-wrap;">- group: "hello there"</td></tr><tr><td style="-webkit-user-select: none; text-align: right; width: 20px;">3</td><td colspan="2" style="white-space: pre-wrap;"> steps:</td></tr><tr><td style="-webkit-user-select: none; text-align: right; width: 20px;">4</td><td colspan="2" style="white-space: pre-wrap;"> - command: echo "success!"</td></tr></tbody></table>
|
||
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
|
||
Comment 2•4 years ago
|
||
Doesn't really seem like a Core:Layout issue, more like DOM:Selection (or maybe Serializers?).
Mirko, can you, please, take a look?
|
||
Updated•4 years ago
|
|
|
||
Comment 4•4 years ago
|
||
Reproducible on Ubuntu 20.04 too.
The specification for user-select: none makes no normative requirement for the behavior:
This specification makes no normative requirement about the behavior of the clipboard. however, UAs are encouraged to keep the visual selection consistent with what would get copied to the clipboard when copying. Copying text that does not appear to be selected, or vice versa, is highly confusing to users.
Therefore, Chrome's behavior isn't ideal either. However, the following exception applies, because Chrome doesn't support multiple ranges:
The UA must allow selections to extend across this element, and must exclude this element from such a selection. An exception is made for UAs which do not support multiple ranges per selection, and they may include this element.
That is, Firefox respects the spec too and fulfills the non-normative ideal stated above. However, generating multiple <table>s indeed seems undesirable. Presumably, fixing this is not trivial, because the related code is an unowned mess.
|
|
||
Updated•4 years ago
|
Description
•