Add the CustomElementsRegistry interface behind the flag

Add the CustomElementsRegistry interface behind the flag

This patch adds the CustomElementsRegistry interface defined in the
custom elements spec[1] behind the runtime flag.

The actual logic is not included in this patch.

[1] http://w3c.github.io/webcomponents/spec/custom/#custom-elements-api

BUG=594918
Committed: https://crrev.com/68afca08701383ce31d01bac172e90e01b149dc1
Cr-Commit-Position: refs/heads/master@{#385499}

[kojii, 2016-03-18 04:21:17]

kojii@chromium.org changed reviewers:
+ hayato@chromium.org, tkent@chromium.org

[kojii, 2016-03-18 04:21:17]

PTAL.

[hayato, 2016-03-18 04:25:43]

The CQ bit was checked by hayato@chromium.org

[hayato, 2016-03-18 04:25:43]

lgtm

[commit-bot: I haz the power, 2016-03-18 04:25:55]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1810973004/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1810973004/1

[tkent, 2016-03-18 04:28:12]

lgtm, but "experimental" status without any implementation doesn't make much
sense.  Do you have a plan to make a workable implementation in a single CL?

[kojii, 2016-03-18 04:40:28]

On 2016/03/18 at 04:28:12, tkent wrote:
> lgtm, but "experimental" status without any implementation doesn't make much
sense.  Do you have a plan to make a workable implementation in a single CL?

Can I confirm, I should add a flag when working impl is ready?

Steps I'm thinking:
1. Add IDL for registration to support the current syntax, with empty body.
2. Share or split current v0 code to make them callable from the IDL.
createElement() should be supported at the same level.
3. Parser, constructor, upgrade, etc.

1 should be small, but 2 could be large and may need to split.

Should I add the flag when I'm ready for 2?

[tkent, 2016-03-18 04:44:02]

On 2016/03/18 at 04:40:28, kojii wrote:
> On 2016/03/18 at 04:28:12, tkent wrote:
> > lgtm, but "experimental" status without any implementation doesn't make much
sense.  Do you have a plan to make a workable implementation in a single CL?
> 
> Can I confirm, I should add a flag when working impl is ready?
> 
> Steps I'm thinking:
> 1. Add IDL for registration to support the current syntax, with empty body.
> 2. Share or split current v0 code to make them callable from the IDL.
createElement() should be supported at the same level.
> 3. Parser, constructor, upgrade, etc.
> 
> 1 should be small, but 2 could be large and may need to split.
> 
> Should I add the flag when I'm ready for 2?

Adding a flag is ok now.  But incomplete implementation should not be visible
for users. If I were you, I would add the flag with status=test in the 1, then
make it status=experimental when the feature is workable.

[kojii, 2016-03-18 05:08:04]

On 2016/03/18 at 04:44:02, tkent wrote:
> 
> Adding a flag is ok now.  But incomplete implementation should not be visible
for users. If I were you, I would add the flag with status=test in the 1, then
make it status=experimental when the feature is workable.

Makes perfect sense, changed to status=test, thank you for your advice.

[kojii, 2016-03-18 08:36:13]

Description was changed from

==========
Add the runtime feature flag for Custom Elements v1

BUG=594918
==========

to

==========
Add the CustomElementsRegistry interface behind the flag

This patch adds the CustomElementsRegistry interface defined in the
custom elements spec[1] behind the runtime flag.

The logic for the "define" is not included in this patch.

[1] http://w3c.github.io/webcomponents/spec/custom/#custom-elements-api

BUG=594918
==========

[kojii, 2016-03-18 09:12:50]

Description was changed from

==========
Add the CustomElementsRegistry interface behind the flag

This patch adds the CustomElementsRegistry interface defined in the
custom elements spec[1] behind the runtime flag.

The logic for the "define" is not included in this patch.

[1] http://w3c.github.io/webcomponents/spec/custom/#custom-elements-api

BUG=594918
==========

to

==========
Add the CustomElementsRegistry interface behind the flag

This patch adds the CustomElementsRegistry interface defined in the
custom elements spec[1] behind the runtime flag.

The actual logic is not included in this patch.

[1] http://w3c.github.io/webcomponents/spec/custom/#custom-elements-api

BUG=594918
==========

[kojii, 2016-03-18 09:27:09]

Patchset #5 (id:70001) has been deleted

[kojii, 2016-03-22 00:41:51]

PTAL.

Removed "WillBe" because that is required for PersistentWillBeMember IIUC to fix
the non-oilpan build.

[hayato, 2016-03-22 08:00:14]

https://codereview.chromium.org/1810973004/diff/150001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/custom/CustomElementsRegistry.h (right):

https://codereview.chromium.org/1810973004/diff/150001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/custom/CustomElementsRegistry.h:35: explicit
CustomElementsRegistry();
explicit is not required here.

https://codereview.chromium.org/1810973004/diff/150001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/RemoteDOMWindow.cpp (right):

https://codereview.chromium.org/1810973004/diff/150001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/RemoteDOMWindow.cpp:336:
CustomElementsRegistry* RemoteDOMWindow::customElements() const
I am not familiar with the difference between LocalDOMWindow and
RemoteDOMWindow.
Could you explain briefly why RemoteDOMWindow does not support customElements
for the record?

[kojii, 2016-03-22 09:49:28]

Thank you for the prompt review. Please see inline.

https://codereview.chromium.org/1810973004/diff/150001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/dom/custom/CustomElementsRegistry.h (right):

https://codereview.chromium.org/1810973004/diff/150001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/dom/custom/CustomElementsRegistry.h:35: explicit
CustomElementsRegistry();
On 2016/03/22 08:00:14, hayato wrote:
> explicit is not required here.

Done, thank you. Forgot to remove when I removed the argument.

https://codereview.chromium.org/1810973004/diff/150001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/RemoteDOMWindow.cpp (right):

https://codereview.chromium.org/1810973004/diff/150001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/RemoteDOMWindow.cpp:336:
CustomElementsRegistry* RemoteDOMWindow::customElements() const
On 2016/03/22 08:00:14, hayato wrote:
> I am not familiar with the difference between LocalDOMWindow and
> RemoteDOMWindow.
> Could you explain briefly why RemoteDOMWindow does not support customElements
> for the record?

Hm, my understanding quite shallow too, but IIUC RemoteDOMWindow is for OOPIF,
and I followed the pattern for other interfaces such as document(), console(),
navigator(), etc. that RemoteDOMWindow shuts out all accesses except frame().

When document() returns nullptr, I can't find good reasons to return
customElements.

Do you think I should get better understanding of RemoteDOMWindow?

[tkent, 2016-03-23 00:58:32]

https://codereview.chromium.org/1810973004/diff/150001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/RemoteDOMWindow.cpp (right):

https://codereview.chromium.org/1810973004/diff/150001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/RemoteDOMWindow.cpp:336:
CustomElementsRegistry* RemoteDOMWindow::customElements() const
On 2016/03/22 at 09:49:28, kojii wrote:
> On 2016/03/22 08:00:14, hayato wrote:
> > I am not familiar with the difference between LocalDOMWindow and
> > RemoteDOMWindow.
> > Could you explain briefly why RemoteDOMWindow does not support
customElements
> > for the record?
> 
> Hm, my understanding quite shallow too, but IIUC RemoteDOMWindow is for OOPIF,
and I followed the pattern for other interfaces such as document(), console(),
navigator(), etc. that RemoteDOMWindow shuts out all accesses except frame().
> 
> When document() returns nullptr, I can't find good reasons to return
customElements.
> 
> Do you think I should get better understanding of RemoteDOMWindow?

We should find sentences like "Cross-origin access to customElements IDL
attribute is not allowed" or "Cross-origin access to window attributes are
allowed only for frame structure attributes" in related specifications.

[kojii, 2016-03-23 06:17:35]

On 2016/03/23 00:58:32, tkent wrote:
> We should find sentences like "Cross-origin access to customElements IDL
> attribute is not allowed" or "Cross-origin access to window attributes are
> allowed only for frame structure attributes" in related specifications.

HTML standard has a list of cross-origin properties:
https://html.spec.whatwg.org/multipage/browsers.html#crossoriginproperties-(-o-)

and properties not listed here are ASSERT_NOT_REACHED() in RemoteDOMWindow.
Haven't figured out how it's done...

[kojii, 2016-03-23 06:21:20]

On 2016/03/23 06:17:35, kojii wrote:
> On 2016/03/23 00:58:32, tkent wrote:
> > We should find sentences like "Cross-origin access to customElements IDL
> > attribute is not allowed" or "Cross-origin access to window attributes are
> > allowed only for frame structure attributes" in related specifications.
> 
> HTML standard has a list of cross-origin properties:
>
https://html.spec.whatwg.org/multipage/browsers.html#crossoriginproperties-(-o-)
> 
> and properties not listed here are ASSERT_NOT_REACHED() in RemoteDOMWindow.
> Haven't figured out how it's done...

Cross-origin properties have [DoNotCheckSecurity] in IDL, so my understanding
atm is that the methods in RemoteDOMWindow will not be called unless it has
[DoNotCheckSecurity].

According to the current spec, it will not be accessible unless it's in the
white-list. Should I file a bug asking whether it should be in the white-list or
not?

[tkent, 2016-03-23 06:21:34]

On 2016/03/23 at 06:17:35, kojii wrote:
> On 2016/03/23 00:58:32, tkent wrote:
> > We should find sentences like "Cross-origin access to customElements IDL
> > attribute is not allowed" or "Cross-origin access to window attributes are
> > allowed only for frame structure attributes" in related specifications.
> 
> HTML standard has a list of cross-origin properties:
>
https://html.spec.whatwg.org/multipage/browsers.html#crossoriginproperties-(-o-)
> 
> and properties not listed here are ASSERT_NOT_REACHED() in RemoteDOMWindow.
Haven't figured out how it's done...

It's done by binding generator and "CheckSecurity=Receiver" and
"DoNotCheckSecurity" in our Window.idl.  So, this CL is correct.

[kojii, 2016-04-05 04:23:50]

hayato@, PTAL?

[hayato, 2016-04-05 04:32:33]

lgtm

[kojii, 2016-04-05 04:45:51]

The CQ bit was checked by kojii@chromium.org

[kojii, 2016-04-05 04:45:51]

The patchset sent to the CQ was uploaded after l-g-t-m from tkent@chromium.org
Link to the patchset: https://codereview.chromium.org/1810973004/#ps170001
(title: "Remove explicit from the constructor")

[commit-bot: I haz the power, 2016-04-05 04:46:07]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1810973004/170001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1810973004/170001

[commit-bot: I haz the power, 2016-04-05 04:49:29]

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

[commit-bot: I haz the power, 2016-04-05 04:49:29]

Try jobs failed on following builders:
  linux_chromium_compile_dbg_32_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)
  ios_rel_device_gn on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_gn...)
  ios_rel_device_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_rel_device_ni...)
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_gn_rel on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_gn_r...)

[kojii, 2016-04-06 16:25:13]

The CQ bit was checked by kojii@chromium.org

[kojii, 2016-04-06 16:25:13]

The patchset sent to the CQ was uploaded after l-g-t-m from tkent@chromium.org,
hayato@chromium.org
Link to the patchset: https://codereview.chromium.org/1810973004/#ps210001
(title: "Rebase (merge conflict)")

[commit-bot: I haz the power, 2016-04-06 16:25:32]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1810973004/210001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1810973004/210001

[commit-bot: I haz the power, 2016-04-06 17:43:13]

Committed patchset #11 (id:210001)

[commit-bot: I haz the power, 2016-04-06 17:45:39]

Description was changed from

==========
Add the CustomElementsRegistry interface behind the flag

This patch adds the CustomElementsRegistry interface defined in the
custom elements spec[1] behind the runtime flag.

The actual logic is not included in this patch.

[1] http://w3c.github.io/webcomponents/spec/custom/#custom-elements-api

BUG=594918
==========

to

==========
Add the CustomElementsRegistry interface behind the flag

This patch adds the CustomElementsRegistry interface defined in the
custom elements spec[1] behind the runtime flag.

The actual logic is not included in this patch.

[1] http://w3c.github.io/webcomponents/spec/custom/#custom-elements-api

BUG=594918

Committed: https://crrev.com/68afca08701383ce31d01bac172e90e01b149dc1
Cr-Commit-Position: refs/heads/master@{#385499}
==========

[commit-bot: I haz the power, 2016-04-06 17:45:40]

Patchset 11 (id:??) landed as
https://crrev.com/68afca08701383ce31d01bac172e90e01b149dc1
Cr-Commit-Position: refs/heads/master@{#385499}