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

[myid...@igalia.com]

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

[1] https://crrev.com/c/2319951

[2] https://crbug.com/778816

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1439153#c13

[Chris Harrelson]

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9yOznCKQmARoMznuhaq5EdMjF0pYxTx5BF%2BZg0DSSKjA%40mail.gmail.com.

--

TAMURA Kent
Software Engineer, Google

[Chris Harrelson]

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

[1] https://crrev.com/c/2319951

[2] https://crbug.com/778816

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1439153#c13

--
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.

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.

--
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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9yOznCKQmARoMznuhaq5EdMjF0pYxTx5BF%2BZg0DSSKjA%40mail.gmail.com.

[Yuki Shiino]

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]

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

[1] https://crrev.com/c/2319951

[2] https://crbug.com/778816

[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1439153#c13

--
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.

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.

--
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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw9yOznCKQmARoMznuhaq5EdMjF0pYxTx5BF%2BZg0DSSKjA%40mail.gmail.com.

[Kentaro Hara]

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]

- 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@)

 

[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

Thanks,

Miyuong Shin

[Kentaro Hara]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b7b646af-c9f2-4362-b452-823c25f055ffo%40chromium.org.

[Yuki Shiino]

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]

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]

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]

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]

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