Open Bug 1017407 Opened 11 years ago Updated 5 years ago

triple-clicking a block of text selects non-rendered whitespace at its edges

Categories

(Core :: DOM: Selection, defect, P5)

Product:
Core
Component:
DOM: Selection
Type:
defect

Tracking

()

People

(Reporter: grobinson, Unassigned)

Details

Attachments

(1 file)

testcase 1
464 bytes, text/html
Details
Test case: http://people.mozilla.org/~grobinson/span_copy.html STR: 1. Double-click a <span> element to select the whole thing 2. Copy it via any mechanism (Ctrl-c, context menu, Edit menu) 3. Paste it elsewhere Result: You will notice that the pasted selection has additional leading and/or trailing spaces that were not present in the original copied selection. Expected result: The pasted text is exactly the text that was visibly highlighted before the copy. This is especially annoying when copying generated passwords, reset passwords, or similar values where the exact value is important. The highlighted text, and only the highlighted text, should be copied to the system clipboard.
> 1. Double-click a <span> element to select the whole thing On your test page, the selected content after I triple-click (since double-click selects a single word on Mac) is "all the descendants of <body>". That includes the visible text, the <span>, and the whitespace before/after the <span>. In general, I believe a multiple-click will select all the kids of the nearest ancestor block. So it sounds like you actually want to change exactly what multiple-click selects... what do you think it should select?
Component: Layout → Selection
(In reply to Boris Zbarsky [:bz] from comment #1) > On your test page, the selected content after I triple-click (since > double-click selects a single word on Mac) I have the same results as bz, FWIW, on Linux in my case -- double-click selects a single word, triple-click selects more & gets some padding. Do you perhaps have some extension or tool installed that changes the double-click behavior? (For the use cases you mentioned in comment 0 -- copypasting passwords -- as long as the password doesn't contain space characters, double-click should just select it as a "word" and do the right thing, I'd expect.) > [...] is "all the descendants of <body>". From tweaking the testcase a bit, it actually looks like triple-click selects all of the content up to the next forced linebreak (the next <br> or block-level element boundary), or something like that. And this includes any whitespace at the edges (collapsed to a single space character).
Version: 29 Branch → Trunk
Attached file testcase 1 —
Here's a testcase with four divs, with various combinations of whitespace, to illustrate what currently happens. Any whitespace at the edges of a particular <div> is selected when that <div> is triple-clicked, and shows up in copypaste. (collapsed to a single space character, as you'd expect from whitespace in HTML)
> double-click selects a single word, triple-click selects more & gets some padding. Do you perhaps have some extension or tool installed that changes the double-click behavior? Apologies, I meant triple-click, not double-click. > So it sounds like you actually want to change exactly what multiple-click selects... what do you think it should select? I'm arguing that the "collapse adjacent whitespace into a single space" is counterintuitive, because it is not visible in the selection. > (For the use cases you mentioned in comment 0 -- copypasting passwords -- as long as the password doesn't contain space characters, double-click should just select it as a "word" and do the right thing, I'd expect.) Unless it is a passphrase, and contains spaces :)
(In reply to Garrett Robinson [:grobinson] from comment #4) > I'm arguing that the "collapse adjacent whitespace into a single space" is > counterintuitive, because it is not visible in the selection. I suspect what you're *really* arguing is whether non-rendered whitespace at the edges of blocks should be selected by triple-click. The collapsing itself isn't problematic -- that is required by the spec, from the default value of the CSS "white-space" property.[1] The real problem here seems to be that this whitespace at the edges is selected by triple-click, despite the fact that it's not rendered. (Note that it not-rendering is per-spec, too[2].) [1] http://www.w3.org/TR/CSS21/text.html#white-space-prop [2] see steps 1 and 3 under "As each line is laid out" at http://www.w3.org/TR/CSS21/text.html#white-space-model > > (For the use cases you mentioned in comment 0 -- copypasting passwords -- as long as the password doesn't contain space characters, double-click should just select it as a "word" and do the right thing, I'd expect.) > > Unless it is a passphrase, and contains spaces :) Sure. (Note that I was talking about double-click. Agreed that triple-click could have issues in that use-case.)
Summary: Extra spaces are added to a copied span → triple-clicking a run of text selects non-rendered whitespace at its edges
OS: Linux → All
Hardware: x86_64 → All
Summary: triple-clicking a run of text selects non-rendered whitespace at its edges → triple-clicking a block of text selects non-rendered whitespace at its edges
> I suspect what you're *really* arguing is whether non-rendered whitespace at the edges of blocks should be selected by triple-click. That's exactly right. Thanks for helping me clarify :)

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: