|
| 1 | +# WECG Meetings 2025, Public Notes, Feb 27 |
| 2 | + |
| 3 | + * Chair: Timothy Hatcher |
| 4 | + * Scribes: Rob Wu |
| 5 | + |
| 6 | +Time: 8 AM PST = https://everytimezone.com/?t=67bfab00,384 |
| 7 | +Call-in details: [WebExtensions CG, 27th February 2025](https://www.w3.org/events/meetings/0090c842-271b-4194-b93e-9d401d07af5e/20250227T080000/) |
| 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 #766](https://github.com/w3c/webextensions/issues/766), [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 | + * Berlin Meeting |
| 19 | + * Reminder ([Issue 759](https://github.com/w3c/webextensions/issues/759), [wiki](https://github.com/w3c/webextensions/wiki/2025-Berlin-F2F-Coordination), [sign up form](https://docs.google.com/forms/d/e/1FAIpQLSfTc7PjwQhb7Gzt7Damtf5T_UmnhqLpz3M2OR1PfBtWvQbwoQ/viewform)) |
| 20 | + * State of the Browsers / Extensions |
| 21 | + * Safari Updates |
| 22 | + * **Triage** (15 minutes) |
| 23 | + * [Issue 769](https://github.com/w3c/webextensions/issues/769): Proposal: improve tabs.query API when unexpected property is used |
| 24 | + * [Issue 770](https://github.com/w3c/webextensions/issues/770): Proposal: Perform additional normalization on input URLs to the declarativeNetRequest API |
| 25 | + * **Timely issues** (10 minutes) |
| 26 | + * [PR 767](https://github.com/w3c/webextensions/pull/767): Update specification for loading web extensions in WebDriver Classic |
| 27 | + * [wpt/pull/50648](https://github.com/web-platform-tests/wpt/pull/50648/files): Add the ability to load and test web extensions. |
| 28 | + * **Check-in on existing issues** (12 minutes) |
| 29 | + |
| 30 | + |
| 31 | +## Attendees (sign yourself in) |
| 32 | + |
| 33 | + 1. David Johnson (Apple) |
| 34 | + 2. Rob Wu (Mozilla) |
| 35 | + 3. Tomislav Jovanovic (Mozilla) |
| 36 | + 4. Philippe Le Hegaret (W3C) |
| 37 | + 5. Oliver Dunk (Google) |
| 38 | + 6. Mukul Purohit (Microsoft) |
| 39 | + 7. Krzysztof Modras (Ghostery) |
| 40 | + 8. Timothy Hatcher (Apple) |
| 41 | + 9. Giorgio Maone (Tor, NoScript) |
| 42 | + 10. Kiara Rose (Apple) |
| 43 | + 11. Carlos Jeurissen (Jeurissen Apps) |
| 44 | + 12. Jordan Spivack (Capital One) |
| 45 | + 13. Casey Garland (Capital One) |
| 46 | + 14. Simeon Vincent (Mozilla) |
| 47 | + 15. Aaron Selya (Google) |
| 48 | + |
| 49 | + |
| 50 | +## Meeting notes |
| 51 | + |
| 52 | +(pre start of the meeting) |
| 53 | + |
| 54 | + * (Philippe offering help; discussion on logistics, CG→WG and mention of upcoming Berlin meeting where this topic will be covered) |
| 55 | + |
| 56 | +Announcement: Berlin Meeting |
| 57 | + |
| 58 | + * [timothy] Reminder ([Issue 759](https://github.com/w3c/webextensions/issues/759)) - March 25 - 28 face-to-face meeting in Berlin. Simeon and Timothy discussed last week what we wanted to cover; One of the ideas is a 15-minute mini-presentation from each browser, on the State of the Browsers / Extensions. What's new in the extension ecosystem in the last 6 months since we talked. And since there are multiple extension developer, allow extension developers to chat about pain points, what's new in their extension, etc. |
| 59 | + * [simeon] I'll prepare a wiki page for the Berlin face-to-face 2025, which will contain the primary information, agenda, etc. |
| 60 | + * [simeon] I'll also prepare a sign-up form for logistics. Physical space is limited, so we may need to decline some requests to join. |
| 61 | + * [oliver] Some of the community members join near the end of the week, so would be nice to account for that. |
| 62 | + |
| 63 | +Announcement: Safari Updates |
| 64 | + |
| 65 | + * [timothy] Safari 18.4 beta just went out. Two new features for macOS: We added the ability to install temporary extensions. You can drag a manifest folder or file into Safari, which allows temporary extensions for testing. There is also a button in the developer settings to allow a file picker to select from disk. You can also distribute Safari Web Extensions outside the App Store if they have been notarized. |
| 66 | + * [rob] Is there a blog post or something I can link from the meeting notes? |
| 67 | + * [david] [Temporarily install a web extension folder in macOS Safari](https://developer.apple.com/documentation/safariservices/running-your-safari-web-extension?language=objc#Temporarily-install-a-web-extension-folder-in-macOS-Safari) |
| 68 | + * [david] [Distribute your Developer ID–signed and notarized extension outside the Mac App Store](https://developer.apple.com/documentation/safariservices/distributing-your-safari-web-extension?language=objc#Distribute-your-Developer-ID-signed-and-notarized-extension-outside-the-Mac-App-Store) |
| 69 | + * [simeon] Is an Apple Developer Account required for participation in the notarization process? |
| 70 | + * [timothy] Yes. |
| 71 | + |
| 72 | +[Issue 769](https://github.com/w3c/webextensions/issues/769): Proposal: improve tabs.query API when unexpected property is used |
| 73 | + |
| 74 | + * [timothy] We ignore unknown properties and don't throw. This is probably something we should change, and I'll get a bug filed for this. Especially for a query() API this is not ideal behavior. |
| 75 | + * [oliver] The issue mentions that the alternatives are also trade-offs that are not necessarily better. E.g. returning tabs that does not have the unrecognized property may be unexpected. |
| 76 | + * [timothy] Agreed. E.g. if an extension queries pinned tabs, and pinned tabs are not supported, then an extension could retrieve all tabs and unexpectedly do strange stuff to all tabs. |
| 77 | + * [timothy] Carlos also pointed out that this was discussed during the San Diego meeting last year. |
| 78 | + * [rob] That topic was about feature detection. In this case, query() is read-only, so an extension could try catching errors and omitting properties until they encounter a supported set of properties. |
| 79 | + * [patrick] Context here is frozen tabs, would it make sense to return an empty list by default since there are no frozen tabs? |
| 80 | + * [rob] That works for properties that are false by default, but not otherwise. Throwing would still make most sense because extensions can detect the situation and handle it. |
| 81 | + * [patrick] Maybe some sort of strict mode? Throwing like we do today, and otherwise logging a warning in the console. |
| 82 | + * [krzysztof] As an extension developer, feature detection is important. Also to prepare for upcoming features. Having any way to detect feature support is needed, and currently catching errors is the only way to do that. |
| 83 | + * [simeon] For the use case that Patrick is describing, would an opt-in like silence errors be useful? |
| 84 | + * [patrick] As a developer coming to extensions world, this seems weird to me, since I would expect errors to be an opt-in. I know we discussed a kind of supports() idea before. |
| 85 | + * [simeon] That was the direction we were going with at TPAC. |
| 86 | + * [timothy] Designing a general mechanism is tricky for us in the implementation. |
| 87 | + * [] We need some standard-ish way to identify methods. |
| 88 | + * [tomislav] The MDN documentation has some structured data. |
| 89 | + * [timothy] It needs to be something we do as an API. |
| 90 | + * [rob] Every implementation knows which methods and properties it recognizes; exposing just that information is already helpful and would address the use case from this issue. |
| 91 | + * [patrick] Some APIs have enums. |
| 92 | + * [krzysztof] The detection mechanism should be synchronous. E.g. there is currently no way to detect availability of the blocking webRequest feature in Chrome. |
| 93 | + * [oliver] Wondering whether `management.getSelf()` could be synchronous to allow extensions to detect policy-installed extensions. |
| 94 | + * (context: in Chrome's MV3, extensions cannot use blocking webRequests, except for policy-installed extensions) |
| 95 | + * [rob] Let's save that discussion for later. There is implementation complexity involved in making async APIs synchronous. |
| 96 | + |
| 97 | +[Issue 770](https://github.com/w3c/webextensions/issues/770): Proposal: Perform additional normalization on input URLs to the declarativeNetRequest API |
| 98 | + |
| 99 | + * [oliver] I opened this on behalf of Martin. |
| 100 | + * [martin] This came up in Chrome, where we worked on the internal implementation of DNR. What I am proposing is to remove trailing periods from fully-qualified domain names, and to also percent-decode additional characters, such as slashes. Wondering whether this makes sense in the DNR API. |
| 101 | + * [rob] Can you enumerate the normalizations you have in mind? Fully qualified domain names (FQDN) are not directly equivalent to the URL with the trailing period stripped. Chrome treats them as equivalent in the extension APIs, Firefox considers them different, because servers can treat them differently. |
| 102 | + * [oliver] For the use case of blocking, if the intent is to block `example.com`, then `example.com.` should probably be blocked too. |
| 103 | + * [krzysztof] Normalization is just part of the issue, we lack tooling to detect issues. Normalization would make it harder for developers to debug issues. |
| 104 | + * [krzysztof] As content blockers, we have to account for rules from many other community members. Some browsers have normalization, some don't, etc. |
| 105 | + * [rob] Is Google thinking of making this the only behavior, or an opt-in/opt-out? |
| 106 | + * [martin] We could make it optional. |
| 107 | + * [rob] And the next question is, what should be the default behavior? |
| 108 | + * [alexei] If you think of the case where an extension wants to disable it from the site, we might register an allowAllRequests rule with DNR, update our scripts/scripting API to toggle all scripts, and have our own “disable” logic. If browsers make a change to how the DNR API functions, then would there be a difference between how DNR works and match patterns work? |
| 109 | + * [rob] In this case, urlFilter is DNR-specific. Match patterns are already normalized in Chrome, FQDN are separate from non-FQDN match patterns in Firefox. |
| 110 | + * [timothy] Concerns about inconsistencies. Should be specified for interoperability. |
| 111 | + * [oliver] Willing to accept the changes to urlFilter? |
| 112 | + * [rob] Willing to consider normalization, if specified properly and if extension developer use cases are covered. |
| 113 | + * [timothy] Agreed on need to be precise. Issue speaks about GURL(), we implement things differently. |
| 114 | + * [oliver] Action item for us to be more precise. |
| 115 | + |
| 116 | +[PR 767](https://github.com/w3c/webextensions/pull/767): Update specification for loading web extensions in WebDriver Classic |
| 117 | + |
| 118 | + * [kiara] Updated PR to put archivePath and base64 in a format to match the bidi spec. |
| 119 | + * [timothy] Tomislav has approved, should be good to merge. |
| 120 | + |
| 121 | +[wpt/pull/50648](https://github.com/web-platform-tests/wpt/pull/50648/files): Add the ability to load and test web extensions. |
| 122 | + |
| 123 | + * [timothy] Lots of back and forth here. |
| 124 | + * [tomislav] We have had discussions with wpt folks etc where the logic should live; I am not interested in that path, but I am interested in the actual API exposed to tests (browser.test exposed to extensions) and page that is running the test. |
| 125 | + * [tomislav] In the current proposal, browser.test.assertTrue (etc.) functions forward the assertions to the test runner. Should We specify that they throw? |
| 126 | + * [rob] In Firefox, browser.test.assertTrue, etc. do not throw in Firefox. |
| 127 | + * [timothy] In Safari, they don't throw either. |
| 128 | + * [oliver] I'll have to check what Chrome does. |
| 129 | + * [tomislav] And then we should specify that. |
| 130 | + * [tomislav] In Firefox we have an utility that allows the test runner to communicate with the extension. We could either update all methods to take an extension ID, or return an object/handle that allows methods to be associated with an extension instance. |
| 131 | + * [krzysztof] Doesn't that belong to the webdriver spec? |
| 132 | + * [rob] Just to make sure that we are all on the same page: Krzysztof is talking about the protocol, but Tomislav is talking about the higher level API exposed to the tests themselves. |
| 133 | + * [tomislav] That is right. |
| 134 | + * [tomislav] Example of loadExtension returning an “extension” wrapper that offers sendMessage etc, https://searchfox.org/mozilla-central/rev/80ae03d93e/browser/components/extensions/test/browser/browser_ext_tabs_executeScript_good.js#29-45,47-48,54,56,62 |
| 135 | + * [timothy] I can see that working, but wonder whether there are issues between mixing wpt and browser test APIs. |
| 136 | + * [tomislav] It is part of the machinery to run tests, but not part of the RFC. |
| 137 | + * [kiara] I can add that. |
| 138 | + * [timothy] Multiple extensions are currently not handled well. We either need an extension ID to be included in the message (sending and receiving). A live object is a possibility too. |
| 139 | + * [krzysztof] Why is the browser.test namespace used? |
| 140 | + * [rob] All browsers here already use browser.test, using that same namespace eases porting of existing tests to wpt. |
| 141 | + * [timothy] Another reason is that including the test harness everywhere in the extension is complicated, which would require lots of boilerplate. |
| 142 | + |
| 143 | +The next meeting will be on [Thursday, March 13th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=67d22000,384). Warning: Daylight saving time changed in the US. Meeting time is now at 3 PM UTC instead of 4 PM UTC. |
0 commit comments