intent-to-ship is required for Element.openOrClosedShadowRoot?

197 views
Skip to first unread message

myid...@igalia.com

unread,
Jul 30, 2020, 7:50:05 PM7/30/20
to blink-dev
Hi, all,

I'm working on adding Element.openOrClosedShadowRoot to allow access to closed shadow roots from Extensions[1]. As discussed in the bug[2], we referred to openOrClosedShadowRoot already supported by Mozilla[3]. I would like to hear your opinion on whether intent-to-ship is necessary for this case, although it will not be exposed to the general Web API, but only to Extensions.

Thanks,
Miyoung Shin

Chris Harrelson

unread,
Jul 30, 2020, 8:05:25 PM7/30/20
to myid...@igalia.com, blink-dev
Hi,

If openOrClosedShadowRoot will only be exposed to scripts that are in Chrome Extensions, and not a regular web page, then no you don't need an intent-to-ship. We don't consider extensions to be part of the official web platform.

Thanks for asking,
Chris 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b2280099-f9a5-46db-b951-e380728b1bbfo%40chromium.org.

TAMURA, Kent

unread,
Aug 3, 2020, 8:53:01 PM8/3/20
to myid...@igalia.com, blink-dev, Chris Harrelson
I think we had better send a PSA about the API change before landing CLs.  Adding new IDL attributes/functions to a web-exposed interface might affect future enhancements on the interface even if the new IDL attributes/functions are exposed only to the extension context.

For example, we would have troubles if a standard added a web-exposed openOrClosedShadowRoot and it's not compatible with the extension-only openOrClosedShadowRoot. We could suggest to rename it if we knew the extension-only openOrClosedShadowRoot.




--
TAMURA Kent
Software Engineer, Google


Chris Harrelson

unread,
Aug 6, 2020, 12:45:06 PM8/6/20
to myid...@igalia.com, blink-dev
I agree that a PSA would be a good idea. More communication is always better! 

Thanks,
Chris

On Wed, Aug 5, 2020 at 8:03 PM <myid...@igalia.com> wrote:
OK. I will send a PSA about openOrClosedShadowRoot API before landing CL.
Thanks to kent-san and Chris.

Regards,
Miyoung Shin
2020년 8월 4일 화요일 오전 9시 53분 1초 UTC+9, Kent Tamura 님의 말:
I think we had better send a PSA about the API change before landing CLs.  Adding new IDL attributes/functions to a web-exposed interface might affect future enhancements on the interface even if the new IDL attributes/functions are exposed only to the extension context.

For example, we would have troubles if a standard added a web-exposed openOrClosedShadowRoot and it's not compatible with the extension-only openOrClosedShadowRoot. We could suggest to rename it if we knew the extension-only openOrClosedShadowRoot.


On Fri, Jul 31, 2020 at 9:05 AM Chris Harrelson <chri...@chromium.org> wrote:
Hi,

If openOrClosedShadowRoot will only be exposed to scripts that are in Chrome Extensions, and not a regular web page, then no you don't need an intent-to-ship. We don't consider extensions to be part of the official web platform.

Thanks for asking,
Chris 

On Thu, Jul 30, 2020 at 4:50 PM <myid...@igalia.com> wrote:
Hi, all,

I'm working on adding Element.openOrClosedShadowRoot to allow access to closed shadow roots from Extensions[1]. As discussed in the bug[2], we referred to openOrClosedShadowRoot already supported by Mozilla[3]. I would like to hear your opinion on whether intent-to-ship is necessary for this case, although it will not be exposed to the general Web API, but only to Extensions.

Thanks,
Miyoung Shin

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

Yuki Shiino

unread,
Aug 6, 2020, 12:54:02 PM8/6/20
to Kentaro Hara, myid...@igalia.com, blink-dev, Chris Harrelson
Hi team,

I'm sorry that I've not been aware of a Chrome extensions API's policy until recently, but all Chrome extensions-specific APIs seem isolated in chrome.* namespace and carefully introduced not to pollute the regular Web API's namespace.  So, probably we'd like to follow the existing convention and we might want to give the API to a different name such as chrome.xxx.openOrClosedShadowRoot().

+Kentaro Hara should have more insights about the design policy.

Cheers,
Yuki Shiino


2020年8月7日(金) 1:45 Chris Harrelson <chri...@chromium.org>:
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BN6QZvHoVsO37dsH8gkuMhw014oz32HD_o1PUOfaf8RJJA86Q%40mail.gmail.com.

myid...@igalia.com

unread,
Aug 6, 2020, 1:35:41 PM8/6/20
to blink-dev, myid...@igalia.com, chri...@chromium.org
OK. I will send a PSA about openOrClosedShadowRoot API before landing CL.
Thanks to kent-san and Chris.

Regards,
Miyoung Shin
2020년 8월 4일 화요일 오전 9시 53분 1초 UTC+9, Kent Tamura 님의 말:
I think we had better send a PSA about the API change before landing CLs.  Adding new IDL attributes/functions to a web-exposed interface might affect future enhancements on the interface even if the new IDL attributes/functions are exposed only to the extension context.

For example, we would have troubles if a standard added a web-exposed openOrClosedShadowRoot and it's not compatible with the extension-only openOrClosedShadowRoot. We could suggest to rename it if we knew the extension-only openOrClosedShadowRoot.

On Fri, Jul 31, 2020 at 9:05 AM Chris Harrelson <chri...@chromium.org> wrote:
Hi,

If openOrClosedShadowRoot will only be exposed to scripts that are in Chrome Extensions, and not a regular web page, then no you don't need an intent-to-ship. We don't consider extensions to be part of the official web platform.

Thanks for asking,
Chris 

On Thu, Jul 30, 2020 at 4:50 PM <myid...@igalia.com> wrote:
Hi, all,

I'm working on adding Element.openOrClosedShadowRoot to allow access to closed shadow roots from Extensions[1]. As discussed in the bug[2], we referred to openOrClosedShadowRoot already supported by Mozilla[3]. I would like to hear your opinion on whether intent-to-ship is necessary for this case, although it will not be exposed to the general Web API, but only to Extensions.

Thanks,
Miyoung Shin

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

Kentaro Hara

unread,
Aug 6, 2020, 7:29:59 PM8/6/20
to Yuki Shiino, Miyoung Shin, blink-dev, Chris Harrelson
Yeah, I'm a bit concerned about the proposal for two reasons:

- We need to implement an infrastructure to expose Web APIs to extensions only. This is a technically solvable problem but will be an amount of work / complexity in the binding layer.
- The current policy is that extension APIs are added to the chrome.* namespace in a way that doesn't pollute web-exposed APIs.

Is there any reason you cannot go with the chrome.* namespace like other extension APIs?

Thanks!

--
Kentaro Hara, Tokyo, Japan

myid...@igalia.com

unread,
Aug 6, 2020, 9:55:59 PM8/6/20
to blink-dev, yukis...@chromium.org, myid...@igalia.com, chri...@chromium.org, rdevlin...@chromium.org
- We need to implement an infrastructure to expose Web APIs to extensions only. This is a technically solvable problem but will be an amount of work / complexity in the binding layer.
I've updated the binding script to introduce ExposedPerWorld=MainWorld|IsolatedWorld for the attribute only(not method & interface) at a CL[1]. If we need to expand it for method & interface or add test cases, I'm willing to proceed in a follow-up CL. Currently, I need to get a review from the reviewer to see if CL is properly approached, but if there are the extra things I can contribute, I would like to do it.
 
- The current policy is that extension APIs are added to the chrome.* namespace in a way that doesn't pollute web-exposed APIs.
Is there any reason you cannot go with the chrome.* namespace like other extension APIs?
There was this discussion at the bug[2][3], and I guess it could answer your question. (+rdevlin.cronin@)
 

Thanks,
Miyuong Shin

Kentaro Hara

unread,
Aug 7, 2020, 12:45:46 AM8/7/20
to Miyoung Shin, blink-dev, Yuki Shiino, Chris Harrelson, R.Devlin Cronin
Thanks Miyoung!

> - We need to implement an infrastructure to expose Web APIs to extensions only. This is a technically solvable problem but will be an amount of work / complexity in the binding layer.
I've updated the binding script to introduce ExposedPerWorld=MainWorld|IsolatedWorld for the attribute only(not method & interface) at a CL[1]. If we need to expand it for method & interface or add test cases, I'm willing to proceed in a follow-up CL. Currently, I need to get a review from the reviewer to see if CL is properly approached, but if there are the extra things I can contribute, I would like to do it.

Makes sense! (though it's a bit unfortunate we need to add custom bindings)
 
There was this discussion at the bug[2][3], and I guess it could answer your question. (+rdevlin.cronin@)
 
[1] https://crrev.com/c/2319951
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=778816#c10
[3] https://bugs.chromium.org/p/chromium/issues/detail?id=778816#c18

I'll delegate the decision to the API owners but my personal feeling is that it looks strange to add extension-specific APIs to Web IDL. Conceptually, Web IDL is a layer to define APIs exposed to the open web, and not a layer to define embedder-specific APIs. What will happen if Edge, Opera, Brave and other user agents start adding their specific APIs to Web IDLs...?


--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Yuki Shiino

unread,
Aug 7, 2020, 3:10:44 AM8/7/20
to Kentaro Hara, Miyoung Shin, blink-dev, Yuki Shiino, Chris Harrelson, R.Devlin Cronin
I have the same concern with haraken@.  If the reason is just that Firefox already uses the name, it doesn't look like a strong enough reason to pollute the Web API namespace.  If we'd introduce Element.prototype.openOrClosedShadowRoot, I think we'd need an agreement among browser vendors?


2020年8月7日(金) 13:45 Kentaro Hara <har...@chromium.org>:

Devlin Cronin

unread,
Aug 7, 2020, 5:20:35 PM8/7/20
to Yuki Shiino, Kentaro Hara, Miyoung Shin, blink-dev, Chris Harrelson
If we'd introduce Element.prototype.openOrClosedShadowRoot, I think we'd need an agreement among browser vendors?
If we were to expose this outside of extensions, I agree (and I don't think we should do that).  If this is limited to extensions (such that Element.prototype.openOrClosedShadowRoot is undefined for web contexts), I don't think this would require standardization - we standardize the web platform, not the content of the WebIDL files.  Miyoung, is the API only exposed in extension contexts?

Cheers,
- Devlin

Domenic Denicola

unread,
Aug 7, 2020, 5:27:08 PM8/7/20
to Devlin Cronin, Yuki Shiino, Kentaro Hara, Miyoung Shin, blink-dev, Chris Harrelson
From: Devlin Cronin <rdevlin...@chromium.org>

> If we'd introduce Element.prototype.openOrClosedShadowRoot, I think we'd need an agreement among browser vendors?
> If we were to expose this outside of extensions, I agree (and I don't think we should do that).  If this is limited to extensions (such that Element.prototype.openOrClosedShadowRoot is undefined for web contexts), I don't think this would require standardization - we standardize the web platform, not the content of the WebIDL files.  Miyoung, is the API only exposed in extension contexts?

The issue here is that, by exposing this to extensions by modifying Element.prototype in extensions, you are impacting future standardization efforts on the web platform. In particular, by using the same namespace which is normally reserved for specified parts of the web platform, you create the potential for future conflicts.

This is why it's generally better to stick to a quarantined namespace like window.chrome.*, which would be my preference for this API.

myid...@igalia.com

unread,
Aug 9, 2020, 10:35:47 PM8/9/20
to blink-dev, rdevlin...@chromium.org, yukis...@chromium.org, har...@chromium.org, myid...@igalia.com, chri...@chromium.org
Thanks for the feedback!

> Miyoung, is the API only exposed in extension contexts?
Yes, The CL intends to expose the API only to Extension. But we can't avoid polluting the Web API's Namespace as others concern.

I also thought about another way that Element.prototype.shadowRoot allows access of closed shadow root only to Extension, but this can be likely to have future potential standardization conflict on the web platform as well. 
So, using chrome.* could be a good option to avoid this concern. 

Regards,
Miyoung Shin

Devlin Cronin

unread,
Aug 28, 2020, 12:17:21 PM8/28/20
to Miyoung Shin, blink-dev, Yuki Shiino, Kentaro Hara, Chris Harrelson
The issue here is that, by exposing this to extensions by modifying Element.prototype in extensions, you are impacting future standardization efforts on the web platform.

That's a good point; thanks for bringing it up, Domenic.

If we go the route of exposing it on the `chrome` object, there's still a few different approaches we may take.  I've added more details on the bug - interested folks, please chime in there. : )

Cheers,
- Devlin 
Reply all
Reply to author
Forward
0 new messages