Bug 15444 - [Shadow]: Find a way for selection to work across shadow DOM subtrees
Summary: [Shadow]: Find a way for selection to work across shadow DOM subtrees
Status: RESOLVED MOVED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 major
Target Milestone: ---
Assignee: Hayato Ito
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
: 25038 (view as bug list)
Depends on:
Blocks: 15480
  Show dependency treegraph
 
Reported: 2012-01-06 18:40 UTC by Dimitri Glazkov
Modified: 2015-05-27 02:37 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitri Glazkov 2012-01-06 18:40:35 UTC
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 Dimitri Glazkov 2012-01-06 20:29:06 UTC
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 Steve Orvell 2013-09-05 01:50:34 UTC
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 Dimitri Glazkov 2014-03-06 00:11:06 UTC
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 Hayato Ito 2014-03-10 06:09:43 UTC
(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/25bd518701866866a26d9d7e3e50d90a45f62d93.

I'll keep this bug open until we have a better model, that is a tough issue for us.
Comment 5 Dimitri Glazkov 2014-03-10 16:07:28 UTC
(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/
> 25bd518701866866a26d9d7e3e50d90a45f62d93.
> 
> 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 Hayato Ito 2014-03-11 07:45:41 UTC
(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 
https://github.com/w3c/webcomponents/commit/0887618b6f247d1d59f37fbc474313014d81f227
Comment 7 Hayato Ito 2014-11-19 05:06:12 UTC
*** Bug 25038 has been marked as a duplicate of this bug. ***
Comment 8 Hayato Ito 2015-04-22 21:31:06 UTC
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.

[1]: https://code.google.com/p/chromium/issues/detail?id=275851
Comment 9 Hayato Ito 2015-05-27 02:37:48 UTC
Moved to https://github.com/w3c/webcomponents/issues/79