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)

defect
Not set
normal

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.
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
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?
(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.
Boris, NI you to put this review request onto your radar :)
Flags: needinfo?(bzbarsky)
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 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+
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
> 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.
(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 :)
(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.
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.
Strange. Pulsebot didn't come here to post my push from autoland...

https://hg.mozilla.org/integration/mozilla-inbound/rev/e302d8d2af8b
https://hg.mozilla.org/mozilla-central/rev/e302d8d2af8b
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
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
QA Whiteboard: [good first verify]
Depends on: 1489842
You need to log in before you can comment on or make changes to this bug.