|
| 1 | +# WECG Meetings 2025, Public Notes, Sep 25 |
| 2 | + |
| 3 | + * Chair: Simeon Vincent |
| 4 | + * Scribes: Rob Wu |
| 5 | + |
| 6 | +Time: 8 AM PDT = https://everytimezone.com/?t=68d5d780,384 |
| 7 | +Call-in details: [WebExtensions CG, 25th September 2025](https://www.w3.org/events/meetings/43e4fb8e-4736-445c-b051-2383ffeef033/20250925T080000/) |
| 8 | +Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) |
| 9 | + |
| 10 | + |
| 11 | +## Agenda: [discussion in #871](https://github.com/w3c/webextensions/issues/871), [github issues](https://github.com/w3c/webextensions/issues) |
| 12 | + |
| 13 | +The meeting will start at 3 minutes after the hour. |
| 14 | + |
| 15 | +See [issue 531](https://github.com/w3c/webextensions/issues/531) for an explanation of this agenda format. |
| 16 | + |
| 17 | + * **Announcements** (2 minutes) |
| 18 | + * **Triage** (15 minutes) |
| 19 | + * [Issue 872](https://github.com/w3c/webextensions/issues/872): Make the order of scripts across content_scripts entries deterministic |
| 20 | + * [PR 873](https://github.com/w3c/webextensions/pull/873): Add specification for `externally_connectable` |
| 21 | + * **Timely issues** (10 minutes) |
| 22 | + * **Check-in on existing issues** (20 minutes) |
| 23 | + * [Issue 400](https://github.com/w3c/webextensions/issues/400): Inconsistency: runtime.getManifest() and missing keys |
| 24 | + * **Action**: Seems this issue has never been triaged. Seems the main problematic issue of the inconsistencies is the lack of chrome.runtime.getManifest() in content scripts in Safari. |
| 25 | + * [PR 837](https://github.com/w3c/webextensions/pull/837): Proposal: close() Method for the sidePanel API |
| 26 | + * [PR 837 kiara comment](https://github.com/w3c/webextensions/pull/837#issuecomment-3187114759): Proposal: close() Method for the sidePanel API |
| 27 | + * **Action item**: Discuss if we want to throw on a close AND open call (as suggested by Oliver) with unmet filters (tabids/windowids) |
| 28 | + * WPT checkin, next steps |
| 29 | + |
| 30 | + |
| 31 | +## Attendees (sign yourself in) |
| 32 | + |
| 33 | + 1. Rob Wu (Mozilla) |
| 34 | + 2. Giorgio Maone (Tor, NoScript) |
| 35 | + 3. Simeon Vincent (Mozilla) |
| 36 | + 4. David Johnson (Apple) |
| 37 | + 5. Mukul Purohit (Microsoft) |
| 38 | + 6. Kiara Rose (Apple) |
| 39 | + 7. Carlos Jeurissen (Jeurissen Apps) |
| 40 | + 8. Simeon Vincent (Mozilla) |
| 41 | + 9. Timothy Hatcher (Apple) |
| 42 | + 10. Tim Pillard (Dashlane) |
| 43 | + 11. Nick Steele (1Password) |
| 44 | + 12. Oliver Dunk (Google) |
| 45 | + 13. Tomislav Jovanovic (Mozilla) |
| 46 | + 14. Oleksii Levzhynskyi (Grammarly) |
| 47 | + |
| 48 | + |
| 49 | +## Meeting notes |
| 50 | + |
| 51 | +Reminder: TPAC happening in November |
| 52 | + |
| 53 | + * [simeon] TPAC happening in November, see [issue 843](https://github.com/w3c/webextensions/issues/843). |
| 54 | + |
| 55 | +[Issue 872](https://github.com/w3c/webextensions/issues/872): Make the order of scripts across content_scripts entries deterministic |
| 56 | + |
| 57 | + * [simeon] Request to specify a deterministic order of content scripts. Carlos also called out differences in de-duplication. |
| 58 | + * [rob] Until a few releases ago behavior in Firefox was not fully deterministic. I addressed that recently and updated the MDN docs. I also looked at Chrome's implementation and they seemed to be deterministic, so I'm somewhat surprised to see this. |
| 59 | + * https://bugzilla.mozilla.org/show_bug.cgi?id=1792685 |
| 60 | + * https://bugzilla.mozilla.org/show_bug.cgi?id=1792685#c16 |
| 61 | + * [carlos] There's a difference between determinism in the content script object declaration order and across injections. |
| 62 | + * [rob] Shared links above that contain link for what I saw in Chrome. In Safari, content scripts are executed in a deterministic order. |
| 63 | + * [timothy] Confirmed. |
| 64 | + * [oliver] Not sure what the behavior is offhand. Will need to investigate. |
| 65 | + * [rob] On the Chrome side, would you be open to deterministic ordering? |
| 66 | + * [oliver] Can't commit at the moment, need to make sure there's no reason we wouldn't want to. Do we want to align on deduplication? |
| 67 | + * [rob] We don't currently deduplicate. Chrome has a bug where deduplication doesn't take worlds into account. Not sure if we'd want to adopt deduplication. In manifest.json it could make sense, but with tabs.executeScript / scripting.executeScript extensions expect repeated execution. For consistency, not deduplicating makes sense to me. |
| 68 | + * [timothy] On board with deduplication in manifest.json. Not with scripting.executeScript with a file, because the extension is in control. We do not currently deduplicate in Safari. |
| 69 | + * [simeon] I'm also leaning towards deduplication as I can imagine scenarios where content scripts block |
| 70 | + * [rob] Let's wait for input from Google's tech lead on this, and then we can see how we can converge. |
| 71 | + |
| 72 | +[PR 873](https://github.com/w3c/webextensions/pull/873): Add specification for `externally_connectable` |
| 73 | + |
| 74 | + * [kiara] Early draft, to request feedback. Question is how we document APIs; should we use separate files or one? |
| 75 | + * [simeon] Currently one file, for simplicity we can continue that. Eventually we will probably split it. I have an agenda item for the WG discussion on structuring deliverables. |
| 76 | + * [tomislav] CSS spec was split in order to deliver specific modules separately; I think that we can take the living standards approach like HTML. |
| 77 | + * [timothy] I'm for a single doc, at least initially, until it gets unwieldy. |
| 78 | + * [simeon] What I saw in specs is organization by capabilities, and sections with descriptions of operations. Separate from IDL descriptions of the APIs. Were you thinking of manifest.json or also covering the APIs? |
| 79 | + * [kiara] Just the manifest.json piece. |
| 80 | + * [oliver] Happy to provide an initial review from the Chrome side. |
| 81 | + * [oliver] Out of curiosity, does Safari support externally_connectable? |
| 82 | + * [kiara] We support externally_connectable, but not the ids key. |
| 83 | + * [timothy] One of the complications is the ID passed on the website differs between Chrome and Safari. That has to be documented differently, but that can be part of the sendMessage spec. |
| 84 | + * [tomislav] Is the value of the ID in Safari an object? String?. |
| 85 | + * [timothy] A string, parentheses, spaces. An opaque string. |
| 86 | + * [mukul] Is there a length limit of the ID? |
| 87 | + * [timothy] No imposed limit, perhaps a limit on the bundle ID length; we don't have a limit. Typically 30-40 characters. |
| 88 | + * [simeon] Firefox supports communications between extensions, not websites. Does Safari plan to support sendMessage between extensions? |
| 89 | + * [timothy] Permissions issues. In theory we could add it, but it is not on our roadmap. |
| 90 | + * [oleksii] Is there a way to abuse externally_connectable? What if my extension allows connecting for a specific ID, is there any way for a bad actor to impersonate? |
| 91 | + * [rob] onMessageExternal and onConnectExternal do expose the source, so the extension can check where the message is coming from. On the website side, a malicious extension could replace sendMessage in a web page in order to impersonate or intercept communication with another well known extension. |
| 92 | + * [tomislav] On the extensions side you have certainty (for signed extensions), but on the public web page you do not have that certainty. |
| 93 | + * [oliver] Last time I looked into it on Firefox; someone can upload arbitrary add-ons to AMO to claim an ID. Is that still true? |
| 94 | + * [rob] Yes. Some ID formats are restricted, but generally any unused ID can be claimed. |
| 95 | + |
| 96 | +[Issue 400](https://github.com/w3c/webextensions/issues/400): Inconsistency: runtime.getManifest() and missing keys |
| 97 | + |
| 98 | + * [carlos] Seems this issue has never been triaged. Seems the main problematic issue of the inconsistencies is the lack of chrome.runtime.getManifest() in content scripts in Safari. |
| 99 | + * [oliver] I recall discussing this on the Chrome side; the intention is returning the parsed version of the manifest, which can result in values being localized. We also used to return a current_locale key that is internal and should not be part of the API result but we do return it. |
| 100 | + * [rob] What about URLs? In Firefox we normalize the provided URLs. |
| 101 | + * [carlos] Chrome does not normalize relative URLs, resulting in issues when used in APIs such as action.setIcon. |
| 102 | + * [timothy] In Safari it is the same; other than localization, it is exactly what the developer puts there. We do not even prune keys. |
| 103 | + * [simeon] In some cases I've needed to use a combination of runtime.getManifest() and a fetch() of the manifest file to make sure I'm working with the data I expect. |
| 104 | + * [tomislav] I think that there is value in knowing what the browser's interpretation of the manifest is. If extensions care they can fetch manifest.json. |
| 105 | + * [timothy] What is the actual usage of getManifest() for this? |
| 106 | + * [rob] I've seen a few use cases. One is trying to do something generic where you want to conditionally inject based on the declaration. I've also had some libraries that check which manifest version is being used and injecting based on that. |
| 107 | + * [carlos] Generic stuff, like getting options page and version number from the extension. |
| 108 | + * [oliver] The most common use I've seen is getting the manifest and extracting the version field. |
| 109 | + * [rob] Important that it's synchronous: every process needs the representation of it since getManifest() is available in content scripts. I expect some extensions will break if we stop returning the normalized manifest. Currently, if there's a relative path in the manifest we normalize to the full extension URL. If we stopped doing that, extensions could try to inject resources using a relative path URL instead and that could break things. |
| 110 | + * [timothy] I see, so it's like creating a script tag. I guess that would be a Firefox-specific behavior, though, as Chrome and Safari don't do that. |
| 111 | + * [rob] Possibly, yes. We may need to collect telemetry to gauge usage. |
| 112 | + * [oliver] My feeling is also that normalizing URLs feels very verbose. I'm inclined to leave it inconsistent until we see that it's causing issues. |
| 113 | + * [rob] … I think we can note in a spec that there's some level of normalization going on and use a non-normative note to provide some examples. At the top level we include unknown keys. That's the main question for this issue: how should we handle those? |
| 114 | + * [tomislav] Safari indicated they don't remove them. We (Firefox) leave top level keys but prune some sub-keys. |
| 115 | + * [timothy] Confirmed. Getting back to the use cases, if most people are just getting the version or manifest version number, I wonder how much it matters that normalization or removing unknown keys matters. |
| 116 | + * [simeon] An example I can think of is browser_specific_settings.gecko.data_collection_permissions in Firefox; If someone wanted to shim the behavior in older/other browser versions, they'd have to read the manifest. |
| 117 | + * [oliver] Would there be appetite if I were to provide a `runtime.getVersion()` method? Feels like a case where you shouldn't have to request the full manifest. |
| 118 | + * [simeon] Is there substantially more overhead from a browser engineering perspective for exposing the object vs. the number? |
| 119 | + * [rob] Most overhead is in having to send the manifest to all processes; after that there is little gain between returning the full manifest vs just the version. |
| 120 | + * [timothy] Yes. I suppose that it would only make a difference if we ever consider deprecating getManifest(). |
| 121 | + * [rob] Which I don't see happening. |
| 122 | + * [rob] If the use case is to return specific values, why wouldn't we expand `runtime.getManifest()` with a parameter that specifies the key the developer is interested in? |
| 123 | + * [tomislav] That would require the implementation to keep track of the full manifest indefinitely. |
| 124 | + * [oliver] Then it does not show up in the documentation as getVersion(). |
| 125 | + * [timothy] I think it makes sense to have a `getVersion` method, as it opens the path to get rid of `getManifest()` in the future. Saves on having to pass and parse a potentially large blob of JSON data. |
| 126 | + |
| 127 | +[PR 837](https://github.com/w3c/webextensions/pull/837): Proposal: close() Method for the sidePanel API |
| 128 | + |
| 129 | + * [oliver] We have an initial implementation on this in Chrome in Beta. Open question around what happens if you provide a tabId and a windowId. In Chrome, if you just provide a tabId we will close the global sidepanel for that tab. I believe Kiara [suggested](https://github.com/w3c/webextensions/pull/837#issuecomment-3187114759) we throw an error. |
| 130 | + * [kiara] Yes, that's correct. For `open()`, I think being consistent would make sense. |
| 131 | + * [oliver] If there's a tab-specific side panel, would you provide just the tabId or also require the windowId? Currently we only require tabId. |
| 132 | + * [kiara] That makes sense. |
| 133 | + * [timothy] Also makes sense to me. |
| 134 | + * [oliver] How about when we have just a tabId for `open()`? In Chrome if you provide both a windowId and tabId we verify that the tab is part of the window. |
| 135 | + * [carlos] If designed from scratch now, I think we should throw an error. But I don't know how much breakage making this behavior change would create. |
| 136 | + * [oliver] We would have to collect metrics to get data on breakage. |
| 137 | + * [oleksii] We have a content script and a tab specific sidepanel that we'd like to open. |
| 138 | + * [oliver] the `open` method is only available in trusted contexts. Can't invoke directly from content script. In that case you'd have to make the hop to the background. |
| 139 | + * [rob] With the current direction, if an extension wanted to close the sidebar in all windows, it would have to enumerate all tabs and call close, correct? |
| 140 | + * [oliver] Yes, but they would also need to enumerate all windows if we take this proposal. |
| 141 | + * [carlos] `sidepanel.closeAll()` |
| 142 | + |
| 143 | +WPT checkin, next steps |
| 144 | + |
| 145 | + * [tomislav] what kind of tests would we want to write next |
| 146 | + * [tomislav] Kiara, do you have any other changes you'd like to make or can we just ping for approval? |
| 147 | + * [kiara] I have to update the PR in response to jgraham's feedback. |
| 148 | + * [tomislav] What are your interests for the next set of tests that we write? When I was working on this with Rob he suggested more `runtime` method tests to help verify cross-browser behavior. |
| 149 | + * [kiara] I can think about this. |
| 150 | + |
| 151 | +The next meeting will be on [Thursday, October 9th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=68e84c80,384). |
0 commit comments