New issue
Advanced search Search tips

Issue 727609 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug



Sign in to add a comment

Selection API should not consider editing boundary as user-select:contain

Reported by dtoybo...@gmail.com, May 30 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3114.0 Safari/537.36

Steps to reproduce the problem:
1. Load https://jsfiddle.net/d_toybox/w3dqfs3v/
2. Click the buttons with/without the checkbox

What is the expected behavior?
Paragraphs should be selected as described in the button label.

What went wrong?
Chrome selects only one paragraph because it hits editing host boundary. I don't see any reason why selection shouldn't cross editing host boundary, in the Selection API spec.

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 61.0.3114.0  Channel: canary
OS Version: 10.0
Flash Version: Shockwave Flash 25.0 r0
 

Comment 1 by dtoybo...@gmail.com, May 30 2017

Note that Edge works similar only when the start is in an editing host. Otherwise, works fine.

Firefox always works fine.

Comment 2 by dtoybo...@gmail.com, May 30 2017

FYI: Selection.addRange() works similar: https://jsfiddle.net/w3dqfs3v/1/

Comment 3 by yosin@chromium.org, May 31 2017

Labels: -Pri-2 Hotlist-Interop Pri-3
Status: Available (was: Unconfirmed)
Summary: Selection API should not consider editing boundary as user-select:contain (was: Selection.setBaseAndExtent() doesn't select specified range if it crosses editing host boundary)
Blink handles elements with |contentEditable=true| having |user-select:contain| [1].
This should be fixed.

Simply removing |VisbileSelection::AdjustSelectionToAvoidCrossingEditingBoundaries()| 
causes lots of layout test failure, == breaking backward compatibility, we should
figure out how to mitigate this breaking change.


[1] https://drafts.csswg.org/css-ui-4/#propdef-user-select

Comment 4 by dtoybo...@gmail.com, May 31 2017

> Blink handles elements with |contentEditable=true| having |user-select:contain| [1].

Ah, good point. I completely forgot it. Perhaps, Selection API should define each API's behavior with it.

On the other hand, how do you think about this style?

*[contenteditable=true]:focus {
  user-select: contain;
}

(Firefox behaves like this in some Selection API calls.)

Comment 5 by yosin@chromium.org, Jun 1 2017

#c4 >how do you think about this style?
It is good idea to describe current behavior.

Could you file a bug to make into the standard?
https://github.com/w3c/csswg-drafts/labels/css-ui-4

Comment 6 by dtoybo...@gmail.com, Jun 23 2017

Sorry for the delay to reply.

I find an issue in Selection API:
https://github.com/w3c/selection-api/issues/46
Project Member

Comment 7 by sheriffbot@chromium.org, Jun 25 2018

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: Available (was: Untriaged)

Sign in to add a comment