Add specification for externally_connectable.
#873
Conversation
kiaraarose
requested review from
Rob--W,
dotproto,
oliverdunk,
xeenon and
zombie
|
|
||
| #### Key `matches` | ||
|
|
||
| A [=list=] of [=match patterns=] that specifies which web pages can communicate with the extension. If left empty or omitted, no web pages can connect. |
There was a problem hiding this comment.
There is an edge case where document URLs cannot be described by a match pattern. For these cases, we specified an algorithm to determine the URL to use for matching content scripts, at specification/index.bs: "Determine the URL for matching a document".
Can we point to this?
@oliverdunk Could you confirm that this is what Chrome does (or intends to use)?
There was a problem hiding this comment.
I'm not sure pointing to that algorithm would be helpful, since it is more about content_scripts and match_origin_as_fallback and match_about_blank which don't exist for externally_connectable .
There was a problem hiding this comment.
I checked Chrome's source code for relevant behavior, which is at https://source.chromium.org/chromium/chromium/src/+/main:extensions/browser/api/messaging/message_service.cc;l=538-540;drc=373d7fdb08be061501a27cf72cb0ff846fbd0899
So it looks like these APIs can only be used from documents whose URL matches the match pattern. In practice, http(s): and file:-URLs. Not URLs like about:blank, blob:-, etc.
So let's resolve this thread by editing the section to emphasize that the match pattern should match the document's URL.
|
|
||
| A [=list=] of [=match patterns=] that specifies which web pages can communicate with the extension. If left empty or omitted, no web pages can connect. | ||
|
|
||
| Any [=match patterns=] that include wildcard domains, or wildcard subdomains of a top-level domain, must be ignored. |
There was a problem hiding this comment.
Wildcard domains is, arguably, the most important thing that externally_connectable should support, and people have been asking for it for ~8 years. See https://bugzilla.mozilla.org/show_bug.cgi?id=1319168 for a long history, but the TL;DR is:
An extension can extend the built-in browser API via externall_connectable by enabling a wildcard externally_connectable. Websites can then probe to see if APIs of interest are exposed by any installed extensions and communicate with the extension without the extension needing to inject content scripts into the page which is currently the only way to achieve this behavior.
There was a problem hiding this comment.
This is inaccurate today (for Chrome) -- we allow wildcard domains / wildcard subdomains.
|
Existing issue requesting specification: #22 |
…extension. Also highlight runtime.onConnectExternal and runtime.onMessageExternal
| This key may be present. | ||
| The <a href="#key-externally_connectable">`externally_connectable`</a> key declares which extensions and web pages can establish connections to the extension using [=runtime.connect()=] and [=runtime.sendMessage()=]. If omitted, all extensions may connect, but no web pages can connect. | ||
|
|
||
| A connection from an external web page or extension triggers the [=runtime.onConnectExternal=] event listener to fire. Similarly, a message sent by an external web page or extension triggers the [=runtime.onMessageExternal=] event listener to fire. |
There was a problem hiding this comment.
| A connection from an external web page or extension triggers the [=runtime.onConnectExternal=] event listener to fire. Similarly, a message sent by an external web page or extension triggers the [=runtime.onMessageExternal=] event listener to fire. | |
| A connection from an external web page or extension triggers the [=runtime.onConnectExternal=] event listener to fire. Similarly, a message sent by an external web page or extension triggers the [=runtime.onMessageExternal=] event listener to fire. | |
| These events are not available to web pages, only in privileged extension contexts. |
6 participants
Here's a first draft of a spec for
externally_connectable. I'm not sure if the way it's written is spec-y enough so open to all feedback for improvements