Plumb whether or not a frame is in shadow DOM to the embedder.

Plumb whether or not a frame is in shadow DOM to the embedder.

The shadow DOM spec states that a frame in a shadow tree should
not appear in the Window object's indexed and named getters.
Today, this check is done with TreeScope: however, a remote Window
has no DOM tree, and thus, no TreeScope. As a result, these checks
cannot currently be enforced on a remote Window.

Since whether or not a frame is in a shadow tree cannot change
without a frame detach and attach, this patch adds a bit to track
what type of DOM tree a frame is in.  Once the embedder is updated
to replicate this bit on child frame creation and child frame
mirroring, the code in FrameTree can be rewritten to use this
state rather than using TreeScope.

BUG=473518
Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=195450

[dcheng, 2015-05-16 12:49:01]

dcheng@chromium.org changed reviewers:
+ hayato@chromium.org

[dcheng, 2015-05-18 03:14:43]

hayato@, mind taking a look? Based on kojii@'s observations at the Shadow DOM
session at BlinkOn, and followup conversations with dominicc@, I realized that I
was interpreting the previous spec (and code) incorrectly.

As a result, we can take a much simpler approach: nested browsing contexts in
shadow trees will just never show up in window's indexed/named getters, so we
just need to store whether or not they are in a shadow tree when the frame is
created.

[dcheng, 2015-05-18 03:15:25]

Also, an initial Chrome-side patch is at
https://codereview.chromium.org/1141283002, though I need to run some design
questions by the content OWNERS before it's ready for review.

[hayato, 2015-05-18 05:08:51]

LGTM

https://codereview.chromium.org/1132133009/diff/40001/Source/web/RemoteFrameC...
File Source/web/RemoteFrameClientImpl.h (right):

https://codereview.chromium.org/1132133009/diff/40001/Source/web/RemoteFrameC...
Source/web/RemoteFrameClientImpl.h:19: 
Remove this empty line? The comment L17 applies to L20-L21?

https://codereview.chromium.org/1132133009/diff/40001/public/web/WebTreeScope...
File public/web/WebTreeScopeType.h (right):

https://codereview.chromium.org/1132133009/diff/40001/public/web/WebTreeScope...
public/web/WebTreeScopeType.h:11: // the Shadow DOM spec at
http://www.w3.org/TR/shadow-dom/#shadow-trees.
Could you refer to the editor's draft,
http://w3c.github.io/webcomponents/spec/shadow/?

We discourage the link to any published version of the Shadow DOM spec.

[dcheng, 2015-05-18 05:19:14]

https://codereview.chromium.org/1132133009/diff/40001/Source/web/RemoteFrameC...
File Source/web/RemoteFrameClientImpl.h (right):

https://codereview.chromium.org/1132133009/diff/40001/Source/web/RemoteFrameC...
Source/web/RemoteFrameClientImpl.h:19: 
On 2015/05/18 05:08:50, hayato wrote:
> Remove this empty line? The comment L17 applies to L20-L21?

Done.

https://codereview.chromium.org/1132133009/diff/40001/public/web/WebTreeScope...
File public/web/WebTreeScopeType.h (right):

https://codereview.chromium.org/1132133009/diff/40001/public/web/WebTreeScope...
public/web/WebTreeScopeType.h:11: // the Shadow DOM spec at
http://www.w3.org/TR/shadow-dom/#shadow-trees.
On 2015/05/18 05:08:50, hayato wrote:
> Could you refer to the editor's draft,
> http://w3c.github.io/webcomponents/spec/shadow/
> 
> We discourage the link to any published version of the Shadow DOM spec.

Done.

[dcheng, 2015-05-18 05:19:19]

The CQ bit was checked by dcheng@chromium.org

[dcheng, 2015-05-18 05:19:19]

The patchset sent to the CQ was uploaded after l-g-t-m from hayato@chromium.org
Link to the patchset: https://codereview.chromium.org/1132133009/#ps60001
(title: "Address review comments")

[commit-bot: I haz the power, 2015-05-18 05:19:37]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1132133009/60001

[commit-bot: I haz the power, 2015-05-18 06:37:06]

Committed patchset #4 (id:60001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=195450