This happens specifically with the contenteditable flag set on the parent element, with it disabled, double and triple clicks work as expected.

Thanks for the issue...

Tried to reproduce the issue on latest chrome stable 70.0.3538.110 using Mac 10.14.0. Attaching screencast for reference.
Steps: 
---------
1. Launched chrome 
2. Opened https://mirror-porcupine.glitch.me/
3. Tried to Highlight the first line with a cursor >Not selected whole line and second line with a cursor > got selected(see attached screencast) 
4. Double clicked "bold" and Triple clicked the paragraph
As we have observed that When highlighting the line with a cursor, all text can be selected.(second line)

@Reporter: Could you please review the attached screen-cast and confirm if anything being missed here and if possible provide screencast for better triaging it also confirm the chrome version that you are facing the issue.

Thanks.!

Deleted: 906410.mp4 1.2 MB

	906410.mp4 1.2 MB View Download

phanindra.mandapaka@ you already reproduced the bug at 0:16-0:19 in your video: the selection stops at "th" - this is the reported bug.

All the bugs are reproduced in the video- I don't believe anything else is missing. Thanks for attaching the screencast!

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on reported chrome version 70.0.3538.110 also on latest chrome 72.0.3617.0 using Mac 10.14.0, Ubuntu 17.10 and Windows 10.  
 
Same behavior is seen on M60(60.0.3112.113) hence considering it as non-regression and marking it as Untriaged.

Thanks..!

Mark WontFix since it works as expected.

Because of content editaiblity doesn't crossing tree boundary, contents in customer elements are uneditable.

See below demo page which uses contentEditable=false for each text decoration elements which works as custom element version.

Demo for contenteditable=false: https://jsfiddle.net/39fmqs5k/

Could you explain an approach for getting custom components to have the behavior that I was expecting?

If this "works as expected" then it is literally impossible for 3rd party developers to build a web-based text editor that supports triple-clicking (i.e. "select paragraph") without implementing that in custom javascript code.

Unfortunately, implementing that behaviour is complex and browser/OS-dependent. Can you point to the specification that states that content editable doesn't cross the tree boundary? That seems like a broken assumption (from the perspective of someone who has been building web-based text editors for many years), and perhaps it's something for the web component / text editing task forces to take up?

I've been researching techniques around this for a good 6 months and never thought to try selections in Chrome with the pointer "since they worked fine with the keyboard and I assumed chrome would naturally excel on web component matters like this" until I did.

I have not tracked if this worked previously, but since my work is all open source, I have a repo with a minimal example using slots inside a contenteditable custom element which clearly shows how chrome excels on web component matters except when it comes to selections with the pointer.

https://smotaal.github.io/components/code-editor/examples/code-editor-alpha/

You can find 90% of the source code inside this sub folder: https://github.com/SMotaal/components/tree/master/code-editor/examples/code-editor-alpha (some helpers.js imports spill out a bit - experimental and all)

My two cents, chrome's text selection in custom elements should be taken seriously, unless we are really not planning to take web components seriously after all.

Please look further into this issue, and I apologize if I am not doing a good job figuring out how to report the issue.

Thank you :)

The image shows you can make a proper selection with the keyboard (try the pointer)

Deleted: Screen Shot 2019-01-14 at 5.46.00 AM.png 642 KB

	Screen Shot 2019-01-14 at 5.46.00 AM.png 642 KB View Download