Document/ShadowRoot split of pointerLockElement

Document/ShadowRoot split of pointerLockElement

As discussed in
https://github.com/w3c/webcomponents/issues/192

document.pointerLockElement should be now shadow-dom aware,
and it gets adjusted to its node tree.

ShadowRoot.pointerLockElement is also added so it should
work similar to how document/ShadowRoot.activeElement works.

BUG=622584
Committed: https://crrev.com/d148a25d4b552d08fe0971faf9464c17cedc7e8f
Cr-Commit-Position: refs/heads/master@{#402625}

[kochi, 2016-06-23 07:11:06]

Description was changed from

==========
Document/ShadowRoot split of pointerLockElement

BUG=
==========

to

==========
Document/ShadowRoot split of pointerLockElement

As discussed in
https://github.com/w3c/webcomponents/issues/192

document.pointerLockElement should be now shadow-dom aware,
and it gets adjusted to its node tree.

ShadowRoot.pointerLockElement is also added so it should
work similar to how document/ShadowRoot.activeElement works.

BUG=622584
==========

[kochi, 2016-06-23 07:59:46]

Patchset #2 (id:20001) has been deleted

[kochi, 2016-06-23 11:07:01]

The CQ bit was checked by kochi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-23 11:07:08]

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

[commit-bot: I haz the power, 2016-06-23 12:14:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-23 12:14:07]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[kochi, 2016-06-24 05:17:44]

The CQ bit was checked by kochi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-24 05:17:58]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2086293004/80001

[kochi, 2016-06-24 05:42:31]

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

[kochi, 2016-06-24 05:42:31]

PTAL

I'll update chromestatus entry for this and announce
to blink-dev.

[hayato, 2016-06-24 05:57:51]

On 2016/06/24 at 05:42:31, kochi wrote:
> PTAL
> 
> I'll update chromestatus entry for this and announce
> to blink-dev.

No. Adjust only for v1 shadow trees. If it's in a v0 shadow tree, return it as
is.

[kochi, 2016-06-24 06:01:05]

On 2016/06/24 05:57:51, hayato wrote:
> On 2016/06/24 at 05:42:31, kochi wrote:
> > PTAL
> > 
> > I'll update chromestatus entry for this and announce
> > to blink-dev.
> 
> No. Adjust only for v1 shadow trees. If it's in a v0 shadow tree, return it as
> is.

Do we want to hide ShadowRoot.pointerLockElement interface itself if the tree is
v0?

[hayato, 2016-06-24 06:09:25]

On 2016/06/24 at 06:01:05, kochi wrote:
> On 2016/06/24 05:57:51, hayato wrote:
> > On 2016/06/24 at 05:42:31, kochi wrote:
> > > PTAL
> > > 
> > > I'll update chromestatus entry for this and announce
> > > to blink-dev.
> > 
> > No. Adjust only for v1 shadow trees. If it's in a v0 shadow tree, return it
as
> > is.
> 
> Do we want to hide ShadowRoot.pointerLockElement interface itself if the tree
is v0?

I do not care. Hiding sounds safer option to me.

[kochi, 2016-06-24 06:14:49]

On 2016/06/24 06:09:25, hayato wrote:
> On 2016/06/24 at 06:01:05, kochi wrote:
> > On 2016/06/24 05:57:51, hayato wrote:
> > > On 2016/06/24 at 05:42:31, kochi wrote:
> > > > PTAL
> > > > 
> > > > I'll update chromestatus entry for this and announce
> > > > to blink-dev.
> > > 
> > > No. Adjust only for v1 shadow trees. If it's in a v0 shadow tree, return
it
> as
> > > is.
> > 
> > Do we want to hide ShadowRoot.pointerLockElement interface itself if the
tree
> is v0?
> 
> I do not care. Hiding sounds safer option to me.

Okay, I'll try doing that unless it makes the change too complex.

[commit-bot: I haz the power, 2016-06-24 06:40:27]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-24 06:40:28]

Dry run: This issue passed the CQ dry run.

[kochi, 2016-06-24 06:42:26]

On 2016/06/24 06:14:49, kochi wrote:
> On 2016/06/24 06:09:25, hayato wrote:
> > On 2016/06/24 at 06:01:05, kochi wrote:
> > > On 2016/06/24 05:57:51, hayato wrote:
> > > > On 2016/06/24 at 05:42:31, kochi wrote:
> > > > > PTAL
> > > > > 
> > > > > I'll update chromestatus entry for this and announce
> > > > > to blink-dev.
> > > > 
> > > > No. Adjust only for v1 shadow trees. If it's in a v0 shadow tree, return
> it
> > as
> > > > is.
> > > 
> > > Do we want to hide ShadowRoot.pointerLockElement interface itself if the
> tree
> > is v0?
> > 
> > I do not care. Hiding sounds safer option to me.
> 
> Okay, I'll try doing that unless it makes the change too complex.

I'm not sure the following case

(A)
document
  hostV1
   +shadow (V1)
     hostV0
       +shadow (V0)
         +pointer locked element

document.pointerLockElement = pointer locked element
V1root.poitnerLockElement = hostV0 or null?
V0root.poitnerLockElement = undefined

For this case, it will not be any interoperability issue,
V1root.pointerLockElement could be either way - hostV0 should be fine.

(B)
document
  hostV0
   +shadow (V0)
     hostV1
       +shadow (V1)
         +pointer locked element

document.pointerLockElement = hostV0 or hostV1?
V0root.poitnerLockElement = undefined
V1root.poitnerLockElement = pointer locked element

In this case, in terms of encapsulation, document.pointerLockElement
can never be pointer locked element.
Probably for the sake of backward compatibility, returning hostV1,
even though it is in V0 shadow makes sense?
This also ensures document.pointerLockElement.shadowRoot.pointerLockElement
to work in this case.

What do you think?

[hayato, 2016-06-24 07:17:38]

Use you best judge in either cases. There is no risk to break compatibility in
either cases, and we do not need to support these cases in the long term.

[kochi, 2016-06-24 10:41:37]

On 2016/06/24 07:17:38, hayato wrote:
> Use you best judge in either cases. There is no risk to break compatibility in
> either cases, and we do not need to support these cases in the long term.

Okay, so I'd like to go with the following:

Document.pointerLockedElement :=
    pointer locked element if it is in V0 (at any level)
    otherwise: the shallowest shadow host of V1 shadow root if pointer locked
element is in V1 (at any level)

ShadowRoot.pointerLockElement :=
    null if ShadowRoot is V0
    if ShadowRoot is V1:
        null if pointer lock element is neither in the same tree nor in
shadow-including descendant
        pointer locked element if pointer locked element is in the same tree, or
all descendant shadow trees are V0
        otherwise: shadow host of the nearest descendant V1 shadow root

So for the above examples: ((*) indicates diff)

(A)
document
  hostV1
   +shadow (V1)
     hostV0
       +shadow (V0)
         +pointer locked element

document.pointerLockElement = pointer locked element
V1root.poitnerLockElement = pointer locked element (*)
V0root.poitnerLockElement = null (*)

(B)
document
  hostV0
   +shadow (V0)
     hostV1
       +shadow (V1)
         +pointer locked element

document.pointerLockElement = hostV1 (*)
V0root.poitnerLockElement = null (*)
V1root.poitnerLockElement = pointer locked element

[kochi, 2016-06-24 11:00:58]

Patchset #5 (id:100001) has been deleted

[kochi, 2016-06-24 11:01:11]

The CQ bit was checked by kochi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-24 11:01:20]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2086293004/120001

[kochi, 2016-06-24 11:11:08]

Patchset #5 (id:120001) has been deleted

[kochi, 2016-06-24 11:11:15]

The CQ bit was checked by kochi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-24 11:11:26]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2086293004/140001

[kochi, 2016-06-24 11:12:08]

Updated the CL.
PTAL.

[commit-bot: I haz the power, 2016-06-24 12:19:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-24 12:19:02]

Dry run: This issue passed the CQ dry run.

[kochi, 2016-06-27 05:30:55]

The CQ bit was checked by kochi@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-06-27 05:31:24]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[kochi, 2016-06-27 05:34:36]

Split DocumentPointerLockElement to DocumentPointerLockElement and
ShadowRootPointerLockElement.
Also added DocumentPointerLockElementInV0Shadow for deprecation.

And merged https://codereview.chromium.org/2094933002/ (counter for
.requestPointerLock() usage
for elements in shadow tree).

PTAL.

[hayato, 2016-06-27 06:43:13]

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Lay...
File third_party/WebKit/LayoutTests/shadow-dom/v0/pointer-lock-in-shadow.html
(right):

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/shadow-dom/v0/pointer-lock-in-shadow.html:8:
<slot></slot>
slot is invalid in v0 shadow trees.

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Lay...
File third_party/WebKit/LayoutTests/shadow-dom/v0/pointer-lock-in-shadow2.html
(right):

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/shadow-dom/v0/pointer-lock-in-shadow2.html:8:
<slot></slot>
slot is invalid in v0 shadow trees.

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Lay...
File third_party/WebKit/LayoutTests/shadow-dom/v0/pointer-lock-in-shadow3.html
(right):

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/shadow-dom/v0/pointer-lock-in-shadow3.html:8:
<slot></slot>
slot is invalid in v0 shadow trees.

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/Document.idl (right):

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/Document.idl:157: // For pointerLockElement,
see DocumentOrShadowRoot.idl.
Do we need this comment? I do not think other methods defined in
DocumentOrShadowRoot have such a comment in Document.idl.

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h (right):

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:51: static Element*
retargetPointerLockElement(TreeScope& scope, const Element* target)
Make a target a reference: const Element& target

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:52: {
This is not a spec compliant.

Please see the definition of the activeElement carefully. Strictly speaking, it
is not the result of retargeting.
There is one more additional check for activeElement:  

> if the result and the context object are in the same tree.

Thus, this function is actually like emulating the behavior of activeElement,
but not retargeting.

It would be better to add a test to find the difference between
*activeElement-like behavior* and *retargeting*.

e.g.

Put a pointer Locked element in an ancestor tree of a shadow tree.

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:66: const Element*
target = document.pointerLockElement();
Return early if target is null.

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:69: return
const_cast<Element*>(target);
Could you add a comment here so that we can remove this special handling in
confident in the future?

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:76: if
(!shadowRoot.isV1())
Could you add a comment here so that we can remove this special handling in
confident in the future?

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:79: const Element*
target = shadowRoot.document().pointerLockElement();
Return early if target is null.

[kochi, 2016-06-27 06:46:15]

Patchset #7 (id:180001) has been deleted

[kochi, 2016-06-27 07:11:37]

Thanks for the review!
Please hold on further review until I update another patchset to clarify the
difference between activeElement and pointerLockElement.

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Lay...
File third_party/WebKit/LayoutTests/shadow-dom/v0/pointer-lock-in-shadow.html
(right):

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/shadow-dom/v0/pointer-lock-in-shadow.html:8:
<slot></slot>
On 2016/06/27 06:43:13, hayato wrote:
> slot is invalid in v0 shadow trees.

Oops!

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/Document.idl (right):

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/Document.idl:157: // For pointerLockElement,
see DocumentOrShadowRoot.idl.
On 2016/06/27 06:43:13, hayato wrote:
> Do we need this comment? I do not think other methods defined in
> DocumentOrShadowRoot have such a comment in Document.idl.

Removed the comment.

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h (right):

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:51: static Element*
retargetPointerLockElement(TreeScope& scope, const Element* target)
On 2016/06/27 06:43:13, hayato wrote:
> Make a target a reference: const Element& target

Done.

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:52: {
On 2016/06/27 06:43:13, hayato wrote:
> This is not a spec compliant.
> 
> Please see the definition of the activeElement carefully. Strictly speaking,
it
> is not the result of retargeting.
> There is one more additional check for activeElement:  
> 
> > if the result and the context object are in the same tree.
> 
> Thus, this function is actually like emulating the behavior of activeElement,
> but not retargeting.
> 
> It would be better to add a test to find the difference between
> *activeElement-like behavior* and *retargeting*.
> 
> e.g.
> 
> Put a pointer Locked element in an ancestor tree of a shadow tree.

This was intentional because if Shadow V1 hosts V0 shadow, and the real
locked element is in V0 shadow, V1 returns the element as it is.

I'd like to do the same for fullscreenElement, so I think now I'd better
have a design doc for this describing why (not just in the review comment).

I'll add a comment in this function, update the spec patch, and double-check
tests.

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:66: const Element*
target = document.pointerLockElement();
On 2016/06/27 06:43:13, hayato wrote:
> Return early if target is null.

Done.

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:76: if
(!shadowRoot.isV1())
On 2016/06/27 06:43:13, hayato wrote:
> Could you add a comment here so that we can remove this special handling in
> confident in the future?

Done.

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:76: if
(!shadowRoot.isV1())
On 2016/06/27 06:43:13, hayato wrote:
> Could you add a comment here so that we can remove this special handling in
> confident in the future?

Done.

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:79: const Element*
target = shadowRoot.document().pointerLockElement();
On 2016/06/27 06:43:13, hayato wrote:
> Return early if target is null.

Done.

[kochi, 2016-06-28 05:28:03]

Patchset #8 (id:220001) has been deleted

[kochi, 2016-06-28 05:28:16]

Patchset #7 (id:200001) has been deleted

[kochi, 2016-06-28 06:34:07]

PTAL

(I also updated the spec change proposal in
https://github.com/w3c/pointerlock/pull/4 )

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Lay...
File third_party/WebKit/LayoutTests/shadow-dom/v0/pointer-lock-in-shadow2.html
(right):

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/shadow-dom/v0/pointer-lock-in-shadow2.html:8:
<slot></slot>
On 2016/06/27 06:43:13, hayato wrote:
> slot is invalid in v0 shadow trees.

Done.

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Lay...
File third_party/WebKit/LayoutTests/shadow-dom/v0/pointer-lock-in-shadow3.html
(right):

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Lay...
third_party/WebKit/LayoutTests/shadow-dom/v0/pointer-lock-in-shadow3.html:8:
<slot></slot>
On 2016/06/27 06:43:13, hayato wrote:
> slot is invalid in v0 shadow trees.

Done.

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h (right):

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:52: {
This function moved to TreeScope's method.

https://codereview.chromium.org/2086293004/diff/160001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:69: return
const_cast<Element*>(target);
On 2016/06/27 06:43:13, hayato wrote:
> Could you add a comment here so that we can remove this special handling in
> confident in the future?

Done.

[hayato, 2016-06-28 06:54:20]

lgtm

https://codereview.chromium.org/2086293004/diff/240001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h (right):

https://codereview.chromium.org/2086293004/diff/240001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:59: // TODO(kochi):
Once V0 code is deprecated, the following V0 check is unnecessary.
s/deprecated/removed/

https://codereview.chromium.org/2086293004/diff/240001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:69: // As
document.pointerLockElement returns the locked element as is if it is in a V0
shadow
This comment should be for "static Element* pointerLockElement(Document&
document)" ??

https://codereview.chromium.org/2086293004/diff/240001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:71: // TODO(kochi):
Once V0 code is deprecated, the following non-V1 check is unnecessary.
s/deprecated/removed/

https://codereview.chromium.org/2086293004/diff/240001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/TreeScope.cpp (right):

https://codereview.chromium.org/2086293004/diff/240001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/TreeScope.cpp:399: // TODO(kochi): Once V0
code is deprecated, use the same logic as .activeElement for
s/deprecated/removed/

[kochi, 2016-06-28 08:20:24]

Thanks for the reviews!

https://codereview.chromium.org/2086293004/diff/240001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h (right):

https://codereview.chromium.org/2086293004/diff/240001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:59: // TODO(kochi):
Once V0 code is deprecated, the following V0 check is unnecessary.
On 2016/06/28 06:54:19, hayato wrote:
> s/deprecated/removed/

Done.

https://codereview.chromium.org/2086293004/diff/240001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:69: // As
document.pointerLockElement returns the locked element as is if it is in a V0
shadow
On 2016/06/28 06:54:19, hayato wrote:
> This comment should be for "static Element* pointerLockElement(Document&
> document)" ??

Hmm, the comment was confusing, and what it meant to say is mostly written in
the comment of TreeScope::adjustedPointerLockElement(), so this comment is
unnecessary now.

Removed the comment.

https://codereview.chromium.org/2086293004/diff/240001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/DocumentOrShadowRoot.h:71: // TODO(kochi):
Once V0 code is deprecated, the following non-V1 check is unnecessary.
On 2016/06/28 06:54:19, hayato wrote:
> s/deprecated/removed/

Done.

https://codereview.chromium.org/2086293004/diff/240001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/TreeScope.cpp (right):

https://codereview.chromium.org/2086293004/diff/240001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/TreeScope.cpp:399: // TODO(kochi): Once V0
code is deprecated, use the same logic as .activeElement for
On 2016/06/28 06:54:19, hayato wrote:
> s/deprecated/removed/

Done.

[kochi, 2016-06-28 08:30:39]

The CQ bit was checked by kochi@chromium.org

[kochi, 2016-06-28 08:30:40]

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/2086293004/#ps260001
(title: "update comments")

[commit-bot: I haz the power, 2016-06-28 08:30:53]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-28 08:41:29]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-06-28 08:41:31]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[kochi, 2016-06-28 09:27:05]

kochi@chromium.org changed reviewers:
+ isherman@chromium.org, tkent@chromium.org

[kochi, 2016-06-28 09:27:06]

tkent-san, could you review for
LayoutTests/virtual/stable/webexposed/global-interface-listing ?

isherman, could you review histograms.xml?

[tkent, 2016-06-28 09:33:57]

lgtm.  I assume this is a part of Shadow DOM v1, and we may skip intent-to-ship.

[Ilya Sherman, 2016-06-28 20:30:27]

histograms.xml lgtm

[kochi, 2016-06-29 00:41:57]

The CQ bit was checked by kochi@chromium.org

[commit-bot: I haz the power, 2016-06-29 00:44:01]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-06-29 00:53:38]

Description was changed from

==========
Document/ShadowRoot split of pointerLockElement

As discussed in
https://github.com/w3c/webcomponents/issues/192

document.pointerLockElement should be now shadow-dom aware,
and it gets adjusted to its node tree.

ShadowRoot.pointerLockElement is also added so it should
work similar to how document/ShadowRoot.activeElement works.

BUG=622584
==========

to

==========
Document/ShadowRoot split of pointerLockElement

As discussed in
https://github.com/w3c/webcomponents/issues/192

document.pointerLockElement should be now shadow-dom aware,
and it gets adjusted to its node tree.

ShadowRoot.pointerLockElement is also added so it should
work similar to how document/ShadowRoot.activeElement works.

BUG=622584
==========

[commit-bot: I haz the power, 2016-06-29 00:53:40]

Committed patchset #8 (id:260001)

[commit-bot: I haz the power, 2016-06-29 00:56:06]

Description was changed from

==========
Document/ShadowRoot split of pointerLockElement

As discussed in
https://github.com/w3c/webcomponents/issues/192

document.pointerLockElement should be now shadow-dom aware,
and it gets adjusted to its node tree.

ShadowRoot.pointerLockElement is also added so it should
work similar to how document/ShadowRoot.activeElement works.

BUG=622584
==========

to

==========
Document/ShadowRoot split of pointerLockElement

As discussed in
https://github.com/w3c/webcomponents/issues/192

document.pointerLockElement should be now shadow-dom aware,
and it gets adjusted to its node tree.

ShadowRoot.pointerLockElement is also added so it should
work similar to how document/ShadowRoot.activeElement works.

BUG=622584

Committed: https://crrev.com/d148a25d4b552d08fe0971faf9464c17cedc7e8f
Cr-Commit-Position: refs/heads/master@{#402625}
==========

[commit-bot: I haz the power, 2016-06-29 00:56:09]

Patchset 8 (id:??) landed as
https://crrev.com/d148a25d4b552d08fe0971faf9464c17cedc7e8f
Cr-Commit-Position: refs/heads/master@{#402625}