Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Selection APIs for Shadow DOM #79

Open
hayatoito opened this issue May 25, 2015 · 13 comments
Open

Selection APIs for Shadow DOM #79

hayatoito opened this issue May 25, 2015 · 13 comments

Comments

@hayatoito
Copy link
Member

@hayatoito hayatoito commented May 25, 2015

Title: [Shadow]: Find a way for selection to work across shadow DOM subtrees (bugzilla: 15444)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15444


comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15444#c0
Dimitri Glazkov wrote on 2012-01-06 18:40:35 +0000.

As specified in http://dvcs.w3.org/hg/webcomponents/rev/3fb19f98bead, window.getSelection() may never retrieve content from shadow DOM subtrees. Also, a user can't select content from both document tree and shadow DOM tree. We must fix that somehow.


comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15444#c1
Dimitri Glazkov wrote on 2012-01-06 20:29:06 +0000.

Should we allow shadow DOM subtrees to specify whether they want to be treated as part of "as-rendered" structure or as a separate subtree?

Currently, for getSelection(), the WebKit implementation returns serialized value of the Selection object inside of a shadow DOM subtree, but node values are adjusted to avoid leaking shadow DOM nodes.


comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15444#c2
Steve Orvell wrote on 2013-09-05 01:50:34 +0000.

This is an important UX concern. I think it's fine to limit access to selection data as defined by the spec. However, users expect to be able to select and copy text in a web page. To have that limited by invisible ShadowDOM boundaries would be very annoying. Ideally, this just always works and is separate from the encapsulation provided via ShadowDOM.


comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15444#c3
Dimitri Glazkov wrote on 2014-03-06 00:11:06 +0000.

One thing that Jonas suggested at the recent spec review is to make our selection language non-normative. It's a tough subject, so we shouldn't freeze this into the spec. The suggestion was to have the language along these lines:

"Selection is not defined. Implementation should do their best to do what's best for them. Here's one possible, admittedly naive way: <insert current normative wording, but make it informative>"


comment: 4
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15444#c4
Hayato Ito wrote on 2014-03-10 06:09:43 +0000.

(In reply to Dimitri Glazkov from comment #3)

One thing that Jonas suggested at the recent spec review is to make our
selection language non-normative. It's a tough subject, so we shouldn't
freeze this into the spec. The suggestion was to have the language along
these lines:

"Selection is not defined. Implementation should do their best to do what's
best for them. Here's one possible, admittedly naive way: <insert current
normative wording, but make it informative>"

Done at
25bd518.

I'll keep this bug open until we have a better model, that is a tough issue for us.


comment: 5
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15444#c5
Dimitri Glazkov wrote on 2014-03-10 16:07:28 +0000.

(In reply to Hayato Ito from comment #4)

(In reply to Dimitri Glazkov from comment #3)

One thing that Jonas suggested at the recent spec review is to make our
selection language non-normative. It's a tough subject, so we shouldn't
freeze this into the spec. The suggestion was to have the language along
these lines:

"Selection is not defined. Implementation should do their best to do what's
best for them. Here's one possible, admittedly naive way: <insert current
normative wording, but make it informative>"

Done at
https://github.com/w3c/webcomponents/commit/
25bd518.

I'll keep this bug open until we have a better model, that is a tough issue
for us.

Maybe kill the 6.1.1 section title and remove the musty language from the non-normative parts?


comment: 6
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15444#c6
Hayato Ito wrote on 2014-03-11 07:45:41 +0000.

(In reply to Dimitri Glazkov from comment #5)

Maybe kill the 6.1.1 section title and remove the musty language from the
non-normative parts?

Sure. Done at
0887618


comment: 7
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15444#c7
Hayato Ito wrote on 2014-11-19 05:06:12 +0000.

*** Bug 25038 has been marked as a duplicate of this bug. ***


comment: 8
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15444#c8
Hayato Ito wrote on 2015-04-22 21:31:06 +0000.

Status Update: This bug is still on our radar, but we couldn't spend much time on this issue in terms of the spec.

FYI. In Blink, we are working on supporting selection across shadow boundaries 1. However, there is no update on API in the spec yet.

@hayatoito hayatoito added the v2 label May 25, 2015
@hayatoito hayatoito changed the title [Shadow]: Find a way for selection to work across shadow DOM subtrees (bugzilla: 15444) Selection APIs for Shadow DOM Mar 16, 2016
@yoichio

This comment has been minimized.

Copy link

@yoichio yoichio commented Nov 11, 2017

I proposed updating Selection API for Shadow in TPAC:
https://github.com/yoichio/public-documents/blob/master/selectionapiforshadow.md
Discussion log:
https://www.w3.org/2017/11/10-webplat-minutes.html#item05

@smaug----, do you have any opinion?

@annevk

This comment has been minimized.

Copy link
Member

@annevk annevk commented Nov 13, 2017

I suspect @rniwa is also interested in this as I believe he was working on the Selection API last.

(It's encouraging to read that it attempts to preserve the encapsulation boundary.)

@TakayoshiKochi

This comment has been minimized.

Copy link
Member

@TakayoshiKochi TakayoshiKochi commented Nov 14, 2017

@yoichio and @rniwa (and others) discussed the topic off-meeting-room, which is not captured in the meeting notes. In a nutshell, I understand @rniwa's idea is to preserve the both ends of selection via opaque handles to point somewhere in the whole tree, not explicit node + offset pairs. Lots of details to be fleshed out, but sounded a feasible idea.

@rniwa

This comment has been minimized.

Copy link
Contributor

@rniwa rniwa commented Nov 14, 2017

Basically, the idea is to provide a mechanism to refer to a specific position within a shadow DOM with a mechanism that can be also used to refer to a specific position in pseudo element, SVG use element's shadow tree, etc...

It's probably sensible to introduce an interface on ShadowRoot to see the boundary points within a specific shadow tree but that shouldn't be Selection interface since that interface has a bunch of methods like collapse and extend which don't make sense to have it for every shadow root.

We also discussed that we need a mechanism to pick a mode between having a separate selection & having a selection that's shared with the parent tree. e.g. if you're creating an editor, you may want to have its own selection whereas if you're just an article, you probably want the selection to be shared with the rest of the document.

@TakayoshiKochi

This comment has been minimized.

Copy link
Member

@TakayoshiKochi TakayoshiKochi commented Nov 14, 2017

Also discussed there that saving / restoring selection states (ie. serializable selection) was the biggest request from web-based editor authors.

@smaug----

This comment has been minimized.

Copy link

@smaug---- smaug---- commented Nov 14, 2017

How would serializable selection work with closed ShadowRoots? I guess some proposal will explain that?

@rniwa

This comment has been minimized.

Copy link
Contributor

@rniwa rniwa commented Nov 15, 2017

So the idea is to use (shadowHost, position identifier) pair for selection start & end where position identifier is an author-script defined location within each shadow tree. If a position lies within another shadow tree, then the identifier (some integer) should be able to distinguish any selection end points within the inner shadow tree (recursively).

For pseudo element, textarea, input, SVG use element, etc... UA defines this identifier (probably needs to be spec'ed).

kisg pushed a commit to paul99/webkit-mips that referenced this issue Sep 26, 2018
…e drag

https://bugs.webkit.org/show_bug.cgi?id=151380
<rdar://problem/24363872>

Source/WebCore:

Reviewed by Antti Koivisto and Wenson Hsieh.

This patch adds the basic support for selecting content across shadow DOM boundaries to VisibleSelection,
which is enough to allow users to select content across shadow DOM boundaries via a mouse drag.

This is the first step in allowing users to select, copy and paste content across shadow DOM boundaries,
which is a serious user experience regression right now. The new behavior is disabled by default under
an interal debug feature flag: selectionAcrossShadowBoundariesEnabled.

Like Chrome, we are not going to support selecting editable content across shadow DOM boundaries since
we'd have to generalize every editing commands to make that work, and there aren't any HTML editors that
use shadow DOM boundaries within an editable region yet. For simplicity, we also don't support extending
a selection out of a shadow root which resides inside an editing region.

The keyboard based navigation & manipulation of selection as well as allowing copy & paste of content
across shadow DOM boundaries will be implemented by separate patches. DOMSelection will not expose this new
behavior either. This is tracked in the spec as w3c/webcomponents#79

Tests: editing/selection/selection-across-shadow-boundaries-mixed-editability-1.html
       editing/selection/selection-across-shadow-boundaries-mixed-editability-2.html
       editing/selection/selection-across-shadow-boundaries-mixed-editability-3.html
       editing/selection/selection-across-shadow-boundaries-mixed-editability-4.html
       editing/selection/selection-across-shadow-boundaries-mixed-editability-5.html
       editing/selection/selection-across-shadow-boundaries-readonly-1.html
       editing/selection/selection-across-shadow-boundaries-readonly-2.html
       editing/selection/selection-across-shadow-boundaries-readonly-3.html
       editing/selection/selection-across-shadow-boundaries-user-select-all-1.html

* editing/VisibleSelection.cpp:
(WebCore::isInUserAgentShadowRootOrHasEditableShadowAncestor): Added.
(WebCore::VisibleSelection::adjustSelectionToAvoidCrossingShadowBoundaries): When the feature is enabled,
allow crossing shadow DOM boundaries except when either end is inside an user agent shadow root, or one of
its shadow includign ancestor is inside an editable region. The latter check is needed to disallow
an extension of a selection starting in a shadow tree inside a non-editable region inside an editable region
to outside the editable region. The rest of the editing code is not ready to deal with selection like that.
* page/Settings.yaml: Added an internal debug feature to enable this new behavior.

Source/WebKit:

Reviewed by Antti Koivisto.

Added SelectionAcrossShadowBoundariesEnabled as an internal debug feature,
and moved CSSCustomPropertiesAndValuesEnabled to where other experimental features are located.

* Shared/WebPreferences.yaml:

Source/WebKitLegacy/mac:

Reviewed by Wenson Hsieh.

Added selectionAcrossShadowBoundariesEnabled as a preference to be used in DumpRenderTree.

* WebView/WebPreferenceKeysPrivate.h:
* WebView/WebPreferences.mm:
(+[WebPreferences initialize]):
(-[WebPreferences selectionAcrossShadowBoundariesEnabled]):
(-[WebPreferences setSelectionAcrossShadowBoundariesEnabled:]):
* WebView/WebPreferencesPrivate.h:
* WebView/WebView.mm:
(-[WebView _preferencesChanged:]):

Tools:

Reviewed by Wenson Hsieh.

Added the support for internal:selectionAcrossShadowBoundariesEnabled test option.

* DumpRenderTree/TestOptions.cpp:
(TestOptions::TestOptions):
* DumpRenderTree/TestOptions.h:
* DumpRenderTree/mac/DumpRenderTree.mm:
(resetWebPreferencesToConsistentValues):
(setWebPreferencesForTestOptions):

LayoutTests:

Reviewed by Antti Koivisto and Wenson Hsieh.

Added regression tests using ref tests since getSelection() doesn't expose any node inside a shadow tree.

* editing/selection/selection-across-shadow-boundaries-mixed-editability-1-expected.html: Added.
* editing/selection/selection-across-shadow-boundaries-mixed-editability-1.html: Added.
* editing/selection/selection-across-shadow-boundaries-mixed-editability-2-expected.html: Added.
* editing/selection/selection-across-shadow-boundaries-mixed-editability-2.html: Added.
* editing/selection/selection-across-shadow-boundaries-mixed-editability-3-expected.html: Added.
* editing/selection/selection-across-shadow-boundaries-mixed-editability-3.html: Added.
* editing/selection/selection-across-shadow-boundaries-mixed-editability-4-expected.html: Added.
* editing/selection/selection-across-shadow-boundaries-mixed-editability-4.html: Added.
* editing/selection/selection-across-shadow-boundaries-mixed-editability-5-expected.html: Added.
* editing/selection/selection-across-shadow-boundaries-mixed-editability-5.html: Added.
* editing/selection/selection-across-shadow-boundaries-readonly-1-expected.html: Added.
* editing/selection/selection-across-shadow-boundaries-readonly-1.html: Added.
* editing/selection/selection-across-shadow-boundaries-readonly-2-expected.html: Added.
* editing/selection/selection-across-shadow-boundaries-readonly-2.html: Added.
* editing/selection/selection-across-shadow-boundaries-readonly-3-expected.html: Added.
* editing/selection/selection-across-shadow-boundaries-readonly-3.html: Added.
* editing/selection/selection-across-shadow-boundaries-user-select-all-1-expected.html: Added.
* editing/selection/selection-across-shadow-boundaries-user-select-all-1.html: Added.


git-svn-id: http://svn.webkit.org/repository/webkit/trunk@236519 268f45cc-cd09-0410-ab3c-d52691b4dbfc
@web-padawan

This comment has been minimized.

Copy link

@web-padawan web-padawan commented Oct 4, 2018

Recently did some research on practical aspects while trying to get a WYSIWYG editor working in Shadow DOM, submitted the report to the polyfill repo: https://github.com/webcomponents/shadydom/issues/113#issuecomment-427066346

Hope to see some progress on this topic after F2F in October.

@aadamsx

This comment has been minimized.

Copy link

@aadamsx aadamsx commented Oct 4, 2018

You'll find an example of it not working here: https://github.com/ckeditor/ckeditor5-engine/issues/692#issuecomment-427027745

@yoichio

This comment has been minimized.

Copy link

@yoichio yoichio commented Oct 5, 2018

Thank you for investigation! Pain points from web authors are great motivation for us to move this forward:)

@yoichio

This comment has been minimized.

Copy link

@yoichio yoichio commented Oct 19, 2018

I wrote up new ComposedSelection API Explainer: http://bit.ly/2yPAd5h.
I'm going to propose this on this TPAC next week.
Any comment, especially from web developers, is welcome(you also can comment on the doc).

@rniwa

This comment has been minimized.

Copy link
Contributor

@rniwa rniwa commented Oct 25, 2018

Rough consensus at TPAC F2F:

  • Add getComposedRange, which takes a list of closed trees, to Selection.
  • Instead of adding a new setBaseAndExtent variant, update the existing methods to support setting selection which crosses shadow boundaries.

Action Item: Figure out what happens to each method in Selection.

@smaug----

This comment has been minimized.

Copy link

@smaug---- smaug---- commented Oct 25, 2018

and getComposedRange would return a StaticRange

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
9 participants
You can’t perform that action at this time.