Closed
Bug 1258177
Opened 8 years ago
Closed 8 years ago
Clicking on the "display: list-item" markers selects the text in the element
Categories
(Core :: Layout: Block and Inline, defect)
Core
Layout: Block and Inline
Tracking
()
RESOLVED
FIXED
mozilla48
Tracking | Status | |
---|---|---|
firefox48 | --- | fixed |
People
(Reporter: TYLin, Assigned: TYLin)
References
(Depends on 1 open bug, )
Details
Attachments
(1 file)
This bug is filed per https://lists.w3.org/Archives/Public/www-style/2016Feb/0322.html 1. Open data:text/html,<li>123</li> 2. Single click on the list marker (the disc) before '123' Actual result: '123' is selected. Expected result: '123' is NOT selected.
Assignee | ||
Updated•8 years ago
|
Summary: Clicking on the "display: list-item" markers select the text in the element → Clicking on the "display: list-item" markers selects the text in the element
Assignee | ||
Comment 1•8 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/41253/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/41253/
Attachment #8732609 -
Flags: review?(bzbarsky)
Comment on attachment 8732609 [details] MozReview Request: Bug 1258177 - Make the list-item markers non-selectable. r?bz Does this change what gets copied (or what gets shown as selected) when a user selects text that includes list markers, for either bulleted or ordered lists?
Assignee | ||
Comment 3•8 years ago
|
||
(In reply to David Baron [:dbaron] ⌚️UTC-4 (less responsive until April 4) from comment #2) > Comment on attachment 8732609 [details] > MozReview Request: Bug 1258177 - Make the list-item markers non-selectable. > r?bz > > Does this change what gets copied (or what gets shown as selected) when a > user selects text that includes list markers, for either bulleted or ordered > lists? Currently, we do not allow a user to extend the select highlight to either the bulleted or ordered list markers, so adding '-moz-user-select: none' to ::-moz-list-bullet doesn't change what the user could select or copied. For example, on the test case in comment 0, if a user drag a selection over the bulleted list marker, the selection highlight will cover only "123", and only "123" will be copied into the clipboard.
Assignee | ||
Comment 4•8 years ago
|
||
Boris, NI you to put this review request onto your radar :)
Flags: needinfo?(bzbarsky)
Comment 5•8 years ago
|
||
The review request is on my radar. But so are about 15 others (literally), most of them older than this one, so....
Flags: needinfo?(bzbarsky)
Comment 6•8 years ago
|
||
Comment on attachment 8732609 [details] MozReview Request: Bug 1258177 - Make the list-item markers non-selectable. r?bz https://reviewboard.mozilla.org/r/41253/#review38599 r=me, but can we remove some of that code that was preventing extending selection into the marker, then?
Attachment #8732609 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 7•8 years ago
|
||
https://reviewboard.mozilla.org/r/41253/#review38599 Boris, could you elaborate a bit about where the code is? The marker is a nsBulletFrame, and the selection highlight might not be able to extend to it like text frames. I've searched nsSelection and found nothing special about preventing nsBulletFrame being selected. BTW, here is the reason why single clicking on the marker selects the entire li content. When clicking on a nsBulletFrame, the data at [1] is offset.content == HTMLSharedListElement, offsets.StartOffset() == 0, and offsets.EndOffset() == 1. Later down to the stack, [2] will extend the selection to cover the entire element. [1] https://dxr.mozilla.org/mozilla-central/rev/6202ade0e6d688ffb67932398e56cfc6fa04ceb3/layout/generic/nsFrame.cpp#3009 [2] https://dxr.mozilla.org/mozilla-central/rev/6202ade0e6d688ffb67932398e56cfc6fa04ceb3/layout/generic/nsSelection.cpp#1695
Comment 8•8 years ago
|
||
> Boris, could you elaborate a bit about where the code is?
I have no idea, sorry. I assumed it exists because we're not extending the selection into the bullet, but if it's not obvious what it is, don't worry about it.
Assignee | ||
Comment 9•8 years ago
|
||
(In reply to Boris Zbarsky [:bz] from comment #8) > I have no idea, sorry. I assumed it exists because we're not extending the > selection into the bullet, but if it's not obvious what it is, don't worry > about it. OK. Thank you for the heads up and the review :)
Comment 10•8 years ago
|
||
(In reply to Boris Zbarsky [:bz] from comment #8) > > Boris, could you elaborate a bit about where the code is? > > I have no idea, sorry. I assumed it exists because we're not extending the > selection into the bullet, but if it's not obvious what it is, don't worry > about it. I think the bullet is natively unselectable. nsBulletFrame does not use text frame to draw its content even if it is text inside. It draws text via nsLayoutUtils::DrawString() directly.
Comment 11•8 years ago
|
||
https://reviewboard.mozilla.org/r/41253/#review38599 It doesn't seem to me your [1] is code normally triggered. browser.ignoreNativeFrameTextSelection is false by default, which means this branch is just ignored for a normal install.
Assignee | ||
Comment 12•8 years ago
|
||
https://reviewboard.mozilla.org/r/41253/#review38599 Ah. I must select the wrong HandleClick() from dxr. The correct one is https://dxr.mozilla.org/mozilla-central/rev/6202ade0e6d688ffb67932398e56cfc6fa04ceb3/layout/generic/nsFrame.cpp#3083
Assignee | ||
Comment 13•8 years ago
|
||
Strange. Pulsebot didn't come here to post my push from autoland... https://hg.mozilla.org/integration/mozilla-inbound/rev/e302d8d2af8b
Comment 14•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/e302d8d2af8b
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox48:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Assignee | ||
Comment 15•8 years ago
|
||
I didn't follow the w3c thread closely, but I found Daniel think single clicking on the marker to select the whole content is actually the correct behavior in [1]. Later I found Apple Pages has the same behavior. Now I don't have a strong opinion about whether this is a feature or a bug. One minor draw back to apply "-moz-user-select: none" to the marker is that we now forbid even double-click or triple-click on the marker to select a word or whole content after the marker like Chrome or OpenOffice. However, user could still do the double or triple clicks on the text to select though. [1] https://lists.w3.org/Archives/Public/www-style/2016Mar/0080.html
Updated•8 years ago
|
QA Whiteboard: [good first verify]
You need to log in
before you can comment on or make changes to this bug.
Description
•