|
| 1 | +# WECG Meetings 2025, Public Notes, Apr 10 |
| 2 | + |
| 3 | + * Chair: Timothy Hatcher |
| 4 | + * Scribes: Rob Wu |
| 5 | + |
| 6 | +Time: 8 AM PDT = https://everytimezone.com/?t=67f70a00,384 |
| 7 | +Call-in details: [WebExtensions CG, 10th April 2025](https://www.w3.org/events/meetings/0090c842-271b-4194-b93e-9d401d07af5e/20250410T080000/) |
| 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 #797](https://github.com/w3c/webextensions/issues/797), [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** (5 minutes) |
| 18 | + * Recap Berlin F2F |
| 19 | + * **Triage** (15 minutes) |
| 20 | + * [Issue 795](https://github.com/w3c/webextensions/issues/795): Proposal: opt-out to transformations of extension icons |
| 21 | + * [Issue 800](https://github.com/w3c/webextensions/issues/800): Proposal: browser.runtime.getDocumentId() |
| 22 | + * [Issue 803](https://github.com/w3c/webextensions/issues/803): Proposal: Added Sync management APIs |
| 23 | + * [Issue 805](https://github.com/w3c/webextensions/issues/805): Proposal: Add once as an option in API addListener |
| 24 | + * [Issue 806](https://github.com/w3c/webextensions/issues/806): Proposal: extension specific CSS env() variables |
| 25 | + * [Issue 807](https://github.com/w3c/webextensions/issues/807): Proposal: add OPTIONS_UI as ContextType |
| 26 | + * **Timely issues** (10 minutes) |
| 27 | + * [Issue 698](https://github.com/w3c/webextensions/issues/698): MessageFormat 2 support |
| 28 | + * **Check-in on existing issues** (15 minutes) |
| 29 | + * [PR 791](https://github.com/w3c/webextensions/pull/791): Add trial_tokens key to specification |
| 30 | + * [PR 792](https://github.com/w3c/webextensions/pull/792): Proposal: runtime.onInvalidated event |
| 31 | + * [PR 798](https://github.com/w3c/webextensions/pull/798): WIP: Proposal "Allow to change permissions behavior on extension's update" |
| 32 | + * [PR 799](https://github.com/w3c/webextensions/pull/799): Add browser.permissions.canAccess() proposal |
| 33 | + * [PR 802](https://github.com/w3c/webextensions/pull/802): Add proposal for topFrameMatches and excludeTopFrameMatches |
| 34 | + |
| 35 | + |
| 36 | +## Attendees (sign yourself in) |
| 37 | + |
| 38 | + 1. Rob Wu (Mozilla) |
| 39 | + 2. Giorgio Maone (NoScript, Tor) |
| 40 | + 3. Timothy Hatcher (Apple) |
| 41 | + 4. Simeon Vincent (Mozilla) |
| 42 | + 5. Oliver Dunk (Google) |
| 43 | + 6. Tomislav Jovanovic (Mozilla) |
| 44 | + 7. Aaron Selya (Google) |
| 45 | + 8. David Johnson (Apple) |
| 46 | + 9. Eemeli Aro (Mozilla L10n) |
| 47 | + 10. Carlos Jeurissen (Jeurissen Apps) |
| 48 | + 11. Casey Garland (Capital One) |
| 49 | + 12. Mukul Purohit (Microsoft) |
| 50 | + 13. Maxim Topciu (AdGuard) |
| 51 | + |
| 52 | + |
| 53 | +## Meeting notes |
| 54 | + |
| 55 | +Recap Berlin F2F |
| 56 | + |
| 57 | + * [timothy] 2 weeks ago we met face-to-face. Four fully packed days, including issue triage and in depth discussions. DNR, cosmetic rules, future direction, etc. Looking forward to the next face-to-face. Plan is to have it be later than usual because we try to meet every 6 months or so, and the next TPAC is later than usual this year (November). Probably closer to April 2026. |
| 58 | + * [rob] Still curating the meeting notes, am at ⅓ or the 81 pages. Will publish once finished. |
| 59 | + |
| 60 | +[Issue 795](https://github.com/w3c/webextensions/issues/795): Proposal: opt-out to transformations of extension icons |
| 61 | + |
| 62 | + * [timothy] Probably Safari only, will let Carlos introduce. |
| 63 | + * [carlos] Safari transforms icons to account for developers who are not designed with Safari in mind; would be nice if there is an opt-out for extension developers who are willing to do the work and be good citizens. |
| 64 | + * [timothy] For context, we currently crop some icons because extension icons were rendered with a lot of padding because they were designed for older versions. So we trim whitespace and do transformations on colors - that is a security feature that we don't want extension authors to opt out of. We're supportive of allowing control over the whitespace trimming. |
| 65 | + * [rob] Is this just a Safari issue? Can it be generalized? |
| 66 | + * [timothy] Good question, I don't know. |
| 67 | + * [timothy] We could also check if this is still needed, and potentially drop the behavior. |
| 68 | + |
| 69 | +[Issue 800](https://github.com/w3c/webextensions/issues/800): Proposal: browser.runtime.getDocumentId() |
| 70 | + |
| 71 | + * [carlos] During the Berlin F2F, Google expressed concerns with getFrameId() for information leakage, that issue is not present with documentId. So this is a proposal to implement documentId getter. |
| 72 | + * [timothy] Supportive and willing to support. |
| 73 | + * [oliver] Supportive. Note that we are willing to implement getFrameId too, but there is no clear path to an implementation. getDocumentId is more feasible in the shorter term. |
| 74 | + * [rob] Firefox is also supportive of runtime.getDocumentId. |
| 75 | + * [timothy] Carlos willing to create proposal doc? |
| 76 | + * [carlos] Thought that it was simple enough and maybe not needing a doc. getFrameId does not have a doc either. |
| 77 | + * [rob] getFrameId predates the current proposal process. The desired behavior is well documented in [issue 12](https://github.com/w3c/webextensions/issues/12) though. |
| 78 | + * [timothy] Unfortunate that we didn't have a broader getDocumentId proposal. Would have been useful when implementing this concept in WebKit. |
| 79 | + * [carlos] alternative api design is the runtime.getTarget as proposed in [issue 469](https://github.com/w3c/webextensions/issues/469) |
| 80 | + |
| 81 | +[Issue 803](https://github.com/w3c/webextensions/issues/803): Proposal: Added Sync management APIs |
| 82 | + |
| 83 | + * [rob] Need a bit more time to read the issue, shall we revisit this later? |
| 84 | + * [timothy] Sounds good. |
| 85 | + |
| 86 | +[Issue 805](https://github.com/w3c/webextensions/issues/805): Proposal: Add once as an option in API addListener |
| 87 | + |
| 88 | + * [timothy] Would be simple to implement, not sure if we want to go down this road. Should we add more to addListener or switch to addEventListener? |
| 89 | + * [rob] During the face to face we discussed adding an options parameter to the addListener method. If we added that, that would be easy to implement once. The feature request here wouldn't be a driver for that capability, but it would be considered as part of that. |
| 90 | + * [oliver] Other than once there is also a request for “once but don't wake up when the background suspends”. |
| 91 | + * [rob] That exactly was discussed during the F2F. |
| 92 | + |
| 93 | +[Issue 806](https://github.com/w3c/webextensions/issues/806): Proposal: extension specific CSS env() variables |
| 94 | + |
| 95 | + * [oliver] (referring to [comment](https://github.com/w3c/webextensions/issues/806#issuecomment-2779517856) in the issue) Timothy, why not “webext-” prefix? Prefixes in general or that prefix? |
| 96 | + * [timothy] Don't like abbreviations, would be fine with “browser-” for example. |
| 97 | + * [oliver] Need to discuss with the Chrome team; wonder whether there is a need to consult the CSS WG. |
| 98 | + * [simeon] … |
| 99 | + * [oliver] What I have in mind is for all environment variables unique to browsers in extensions would be prefixed with “browser-”. |
| 100 | + * [rob] The idea behind “browser_style” / “chrome_style” are always noble, but in reality do not catch up with redesigns of the browser. |
| 101 | + * [simeon] … |
| 102 | + * [timothy] There are a few colors that are not exposed (Apple-specific with the apple- prefix when we added dark support in WebKit). |
| 103 | + * [timothy] Named colors fell out of fashion a while ago; lately they have come back in favor due to dark mode, etc. May be useful to web as a whole, not necessarily extension specific. |
| 104 | + * [rob] Fingerprinting could be a concern that blocks availability on the web. |
| 105 | + * [rob] Is there a set of variables we can agree on? |
| 106 | + * [carlos] Text and background colors? |
| 107 | + * [timothy] Basic colors are already covered by CanvasText, etc. |
| 108 | + * [timothy] Can mark this as a duplicate of [issue 680](https://github.com/w3c/webextensions/issues/680), where this was already discussed. |
| 109 | + |
| 110 | +[Issue 807](https://github.com/w3c/webextensions/issues/807): Proposal: add OPTIONS_UI as ContextType |
| 111 | + |
| 112 | + * [timothy] Does Firefox have getContexts() support? |
| 113 | + * [rob] Yes. |
| 114 | + * [timothy] Safari always opens options_ui in a tab; I can see benefits to having a distinct type when not opened in a tab. |
| 115 | + * [oliver] We discussed this when implementing getContexts(), and could not come up with a reason for wanting to distinguish the two. |
| 116 | + * [carlos] Use case example is different style/text depending on whether the options page is embedded or not. |
| 117 | + * [oliver] Use case sounds reasonable, not sure if the proposed solution is the best way to do this. |
| 118 | + * [rob] Have you considered querying the tab and see whether the URL matches? |
| 119 | + * [carlos] That works, but is hacky. I can share examples in the issue. |
| 120 | + |
| 121 | +[Issue 698](https://github.com/w3c/webextensions/issues/698): MessageFormat 2 support |
| 122 | + |
| 123 | + * [timothy] Eemeli mentioned that the MF2 spec is now stable; if we want to consider MF2 for extensions, now would be a good time to consider it. |
| 124 | + * [eemeli] When thinking about this issue, I can think of a number of issues that would need to be discussed. What are the next steps? |
| 125 | + * [rob] If there are specific issues that need to be discussed, please add them to the issue. Any specific concerns at the moment? |
| 126 | + * [eemeli] Highest level question: the change from the current localization system to MF2 should impact the API for message formatting. E.g. MF2 expects input variables to be named rather than indexed. If the API were to be updated, should that apply to the existing i18n system, or just the new one? |
| 127 | + * [simeon] When we discussed this, we decided for backward compatibility, didn't we? |
| 128 | + * [eemeli] Does that imply separating the JS API update from localization system update? |
| 129 | + * [timothy] Depends if we can update the API to support both types in the API. |
| 130 | + * [eemeli] Technically probably feasible. |
| 131 | + * [rob] Are there already standard reference APIs that are common and widespread? When last discussed, there were some areas that were still being specified or unstable. Are there any APIs being considered for adoption on the web platform? |
| 132 | + * [eemeli] Intl.MessageFormat formatter is still at stage 1 TC39 proposal. The shape of that API has been stable for about a decade in that proposal. There are not that many different ways to structure a message formatting API in JavaScript when limited to string outputs. |
| 133 | + * https://github.com/tc39/proposal-intl-messageformat |
| 134 | + * [eemeli] It is possible to support both MF2 and locales in the same messages file. Do we want to specify the format in manifest.json or contain that in messages.json? |
| 135 | + * [simeon] From an earlier discussion I thought that we considered support at the messages.json level. |
| 136 | + * [timothy] If one is using MF2 and another the old format, and the API uses named inputs, would that work with named inputs? |
| 137 | + * [rob] If there's no specific demand for mixing the two, it would be easiest if the manifest specified which format to use. If you define it at the message.json level, you have to load the files before it can know how to handle the messages. |
| 138 | + * [eemeli] My experience with that - it is relatively easy to parse the file that goes into a common internal format that goes through the same tooling. It is of course easier to retain both runtimes for the old and new systems. |
| 139 | + * [rob] Can you clarify what you mean by tooling? |
| 140 | + * [eemeli] … if it would be helpful, I can provide JS code that shows this. |
| 141 | + * [rob] Sounds like you're describing an intermediate format. |
| 142 | + * [eemeli] Should I create many new issues? |
| 143 | + * [rob] Start with listing relevant topics in a comment on the main issue, and then fork into new issues as needed. |
| 144 | + * [eemeli] I will add a comment to the current issue. |
| 145 | + |
| 146 | +[PR 791](https://github.com/w3c/webextensions/pull/791): Add trial_tokens key to specification |
| 147 | + |
| 148 | + * [timothy] Small PR from Oliver to add trial tokens. I approved it, Devlin and Mukul has approved it. |
| 149 | + * [oliver] Main thing is to get a review from Firefox. |
| 150 | + * [rob] I assigned the review to Tomislav since he handled this issue before. |
| 151 | + |
| 152 | +[PR 792](https://github.com/w3c/webextensions/pull/792): Proposal: runtime.onInvalidated event |
| 153 | + |
| 154 | + * [timothy] Already got approvals from Chrome and Safari, just Firefox remaining. |
| 155 | + * [rob] I looked at it before and left a comment; I'll revisit this and sign off. |
| 156 | + |
| 157 | +[PR 798](https://github.com/w3c/webextensions/pull/798): WIP: Proposal "Allow to change permissions behavior on extension's update" |
| 158 | + |
| 159 | + * [timothy] I provided some feedback and bikeshedding, generic name. Carlos has also reviewed it. E.g. dictionary for future-proofing, which I like too. |
| 160 | + * [rob] Is it still WIP (work in progress) or ready to review? |
| 161 | + * [timothy] Good enough for others to do another pass. |
| 162 | + * [rob] I have added Oliver (Chrome) and me (Firefox) as reviewers. |
| 163 | + |
| 164 | +[PR 799](https://github.com/w3c/webextensions/pull/799): Add browser.permissions.canAccess() proposal |
| 165 | + |
| 166 | + * [timothy] |
| 167 | + * [carlos] To account for differences between Firefox, Chrome and Safari: activeTab in Chrome grants host permissions, whereas activeTab in Firefox and Safari only grants the ability to run scripts in a tab. fetch() does not work in Firefox and Safari. |
| 168 | + * [timothy] Not a conscious decision in Safari. |
| 169 | + * [simeon] Not sure about Firefox, Rob? |
| 170 | + * [rob] Could be a bug or feature, haven't decided yet. |
| 171 | + * [simeon] Meaningful distinction between `<all_urls>` in `content_scripts` vs `host_permissions`. |
| 172 | + |
| 173 | +[PR 802](https://github.com/w3c/webextensions/pull/802): Add proposal for topFrameMatches and excludeTopFrameMatches |
| 174 | + |
| 175 | + * [timothy] Out of time - please review this PR async! |
| 176 | + |
| 177 | +The next meeting will be on [Thursday, April 24th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=68097f00,384). |
0 commit comments