|
| 1 | +# WECG Meetings 2024, Public Notes, Jun 20 |
| 2 | + |
| 3 | + * Chair: Timothy Hatcher |
| 4 | + * Scribes: Rob Wu |
| 5 | + |
| 6 | +Time: 8 AM PDT = https://everytimezone.com/?t=66737100,384 |
| 7 | +Call-in details: [WebExtensions CG, 20th June 2024](https://www.w3.org/events/meetings/a97adab8-e1ae-4a2b-85cf-e6b6d3d35f00/20240620T080000/) |
| 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 #635](https://github.com/w3c/webextensions/issues/635), [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 637](https://github.com/w3c/webextensions/issues/637): Allow to create sandboxed iframes in background script of addons |
| 20 | + * [Issue 638](https://github.com/w3c/webextensions/issues/638): Proposal: declarativeNetRequest: Add a way to feature detect whether a specific RuleConditon is supported on the current browser |
| 21 | + * [Issue 639](https://github.com/w3c/webextensions/issues/639): i18n.getMessage() pluralization |
| 22 | + * [Issue 640](https://github.com/w3c/webextensions/issues/640): Proposal: Remove multiple bookmarks in bookmarks.remove() |
| 23 | + * [Issue 642](https://github.com/w3c/webextensions/issues/642): Align on properly formed language tags |
| 24 | + * **Timely issues** (10 minutes) |
| 25 | + * [Issue 636](https://github.com/w3c/webextensions/issues/636): Proposal: Decode regexFilter matches in Declarative Net Request as query parameters |
| 26 | + * [Issue 460](https://github.com/w3c/webextensions/issues/460#issuecomment-2169017147): Proposal: declarativeNetRequest: matching based on response headers |
| 27 | + * **Check-in on existing issues** (20 minutes) |
| 28 | + * [PR 641](https://github.com/w3c/webextensions/pull/641): Proposal: Per-extension language preferences |
| 29 | + * **In-meeting topics** |
| 30 | + * Automated extension API testing |
| 31 | + * TPAC 2024 |
| 32 | + |
| 33 | + |
| 34 | +## Attendees (sign yourself in) |
| 35 | + |
| 36 | + 1. Oliver Dunk (Google) |
| 37 | + 2. Rob Wu (Mozilla) |
| 38 | + 3. Giorgio Maone (Tor, NoScript) |
| 39 | + 4. Timothy Hatcher (Apple) |
| 40 | + 5. Solomon Kinard (Google) |
| 41 | + 6. Simeon Vincent (Mozilla) |
| 42 | + 7. Jackie Han (no affiliation) |
| 43 | + 8. Tomislav Jovanovic (Mozilla) |
| 44 | + 9. Maxim Topciu (AdGuard) |
| 45 | + 10. Mukul Purohit (Microsoft) |
| 46 | + 11. Rémi Pujo (Dashlane) |
| 47 | + 12. Carlos Jeurissen (Jeurissen Apps) |
| 48 | + |
| 49 | + |
| 50 | +## Meeting notes |
| 51 | + |
| 52 | +[Issue 637](https://github.com/w3c/webextensions/issues/637): Allow to create sandboxed iframes in background script of addons |
| 53 | + |
| 54 | + * [timothy] Relevant to Firefox and Safari because Chrome requires service workers. |
| 55 | + * [rob] In Chrome the solution is to use an offscreen document plus the manifest sandbox key. |
| 56 | + * [oliver] Offscreen document should not be seen as the long-term solution. But at the same time it offers a way to do so, so not a priority to develop an alternative API. Current focus is on providing APIs to help with migrating to Manifest Version 3. |
| 57 | + * [rob] manifest sandbox is currently supported in Chrome only. Is Safari going to support it? |
| 58 | + * [timothy] On our timeline, but don't know when it will be supported. |
| 59 | + * [tomislav] Firefox does support the regular CSP sandbox. |
| 60 | + * [rob] sandbox on the web platform is inherit and can only be stricter; The manifest sandbox key enables extensions to specify documents that have a looser CSP, without access to extension APIs. |
| 61 | + * [simeon] Chrome supports the manifest sandbox key to enable extensions to define a page that executes on a null origin. Sandboxed pages don't have access to extension APIs. For Chrome's MV3 transition efforts, this was a notable capability because the MV3 CSP restrictions prevented extensions from executing arbitrary code. |
| 62 | + * [simeon] Any concerns against implementing manifest sandbox? |
| 63 | + * [tomislav] No real concerns. |
| 64 | + * [timothy] No objections. |
| 65 | + * [rob] Might make sense to have sandboxed pages isolated to a specific subdirectory. |
| 66 | + * [oliver] Since you have to declare the sandboxed page in the manifest, what benefit does a specific directory provide? |
| 67 | + * [rob] Page wouldn't be able to include resources outside the directory. Reduces tracing work required to figure out exactly what code is executed. |
| 68 | + |
| 69 | +[Issue 638](https://github.com/w3c/webextensions/issues/638): Proposal: declarativeNetRequest: Add a way to feature detect whether a specific RuleConditon is supported on the current browser |
| 70 | + |
| 71 | + * [timothy] Essentially checking whether a condition is supported and would work. Rob suggested updateSessionRules and catch the error. |
| 72 | + * [rob] The usual implementation in Chrome is to throw when an API receives an unexpected property or value, I guess that this may be an implementation detail where the flag that controls its availability is checked later. So the API recognizes the input, but the rule engine ignores it. |
| 73 | + * [timothy] I see value in verifying whether a specific rule can be used. |
| 74 | + * [oliver] [Issue 449](https://github.com/w3c/webextensions/issues/449) is about introducing a isRuleSupported() . |
| 75 | + * [timothy] In Safari we return the original value. |
| 76 | + * [rob] In Firefox the processed value is returned. I recall that Chrome stores the JSON separately from the compiled rules, so perhaps it returns the original value. |
| 77 | + * [oliver] When we add a dynamic rule with an unrecognized value, we do throw. |
| 78 | + * [timothy] Suggest closing this one in favor of [issue 449](https://github.com/w3c/webextensions/issues/449). |
| 79 | + |
| 80 | +[Issue 639](https://github.com/w3c/webextensions/issues/639): i18n.getMessage() pluralization |
| 81 | + |
| 82 | + * [timothy] This is more common these days; handling numbers/localization in different locales. |
| 83 | + * [tomislav] The linked spec (https://github.com/tc39/proposal-intl-messageformat) is part of the Message Format 2 format, which is also worked on by Mozillians. Instead of bolting on more features on the existing JSON format I would be in favor of moving towards MF2. |
| 84 | + * [timothy] I tend to agree. We don't need to reinvent the wheel. |
| 85 | + * [oliver] I recall having discussed this before, but cannot find an issue. |
| 86 | + * [carlos] The topic was suggested for TPAC 2023: https://github.com/w3c/webextensions/issues/385#issuecomment-1644126655 |
| 87 | + * [rob] Briefly discussed before at TPAC 2023: https://github.com/w3c/webextensions/blob/main/_minutes/2023-09-11-2023-09-14-tpac-extra.md?plain=1#L444-L447 |
| 88 | + |
| 89 | +[Issue 640](https://github.com/w3c/webextensions/issues/640): Proposal: Remove multiple bookmarks in bookmarks.remove() |
| 90 | + |
| 91 | + * [timothy] We don't support bookmarks API in Safari, but this makes sense. |
| 92 | + * [oliver] I don't see issues; I'll talk with the internal people at Chrome who work on the bookmarks API. |
| 93 | + * [simeon] I'm supportive. Feels like a basic API ergonomics issue to me, and the pattern is well established with other APIs. |
| 94 | + |
| 95 | +[Issue 642](https://github.com/w3c/webextensions/issues/642): Align on properly formed language tags |
| 96 | + |
| 97 | + * [carlos] Seems like there is no standard set of supported syntax for language tags in extensions. Suggest standardizing on BCP47. |
| 98 | + * [simeon] Why BCP47? |
| 99 | + * [tomislav] All modern web platform APIs use that. |
| 100 | + * [simeon] tophf raised the concern in [a comment on the issue](https://github.com/w3c/webextensions/issues/642#issuecomment-2179107236) that existing tools use a different standard ([ISO/IEC 15897 standard](https://en.wikipedia.org/wiki/ISO/IEC_15897)). |
| 101 | + * [carlos] That is why I suggest a manifest version bump. |
| 102 | + * [carlos] Firefox already supports both. |
| 103 | + * [timothy] We require underscores, but we can easily change it. I would be supportive of changing it or looking for both. |
| 104 | + * [alexei] I think that this is a place where the browser should be forgiving. Accept the good way and continue supporting the legacy way. |
| 105 | + * [rob] Sounds good to me. |
| 106 | + * [oliver] Carlos, you mentioned that a BCP47 language tag is returned by i18n.getUILanguage. Were you able to test that? |
| 107 | + * [carlos] I did some testing indeed. `i18n.getUILanguage` returns a BCP47 language tag (with hyphens) in both Chrome and Firefox. I believe the same is true for Safari. However in Chrome `i18n.getMessage(‘@@ui_locale')` returns underscores while in Firefox, it returns hyphens. |
| 108 | + * [rob] What does it mean to declare “supportive” on the issue? |
| 109 | + * [carlos] Summarize, support BCP47 in all areas we use language tags in the extension platform. While keeping support for the underscores as suggested by Alexei |
| 110 | + * [rob] I would support that, and not discontinue the previous format for backwards-compatibility. |
| 111 | + * [oliver] I'll follow up internally to check if this is feasible. |
| 112 | + |
| 113 | +[Issue 636](https://github.com/w3c/webextensions/issues/636): Proposal: Decode regexFilter matches in Declarative Net Request as query parameters |
| 114 | + |
| 115 | + * [oliver] Alexei shared feedback in a previous issue about wanting to redirect a request to a partial match of a URL. Rob already provided feedback, more feedback is welcome. We've wanted to tackle this for a bit and are considering adding it to our roadmap. |
| 116 | + * [oliver] The use case is to handle when you click a link and are taken to a URL such as [example.com/redirect?url=something](http://example.com/redirect?url=something). Privacy Badger and other similar extensions want to be able to redirect directly to the destination from the query parameter using Declarative Net Request. |
| 117 | + * [alexei] It is a way to clean tracking links. |
| 118 | + * [rob] The issue appears to be very focused on this specific use case. My suggestion in [a comment on the issue](https://github.com/w3c/webextensions/issues/636#issuecomment-2165978322) was to make it a bit broader to be extensible for more use cases. |
| 119 | + * [oliver] No strong feelings, want to balance implementation complexity. |
| 120 | + * [timothy] I like Rob's suggestion, will read further. |
| 121 | + |
| 122 | +[Issue 460](https://github.com/w3c/webextensions/issues/460#issuecomment-2169017147): Proposal: declarativeNetRequest: matching based on response headers |
| 123 | + |
| 124 | + * [oliver] Exact match is very limited, we're looking into various ways of matching substrings. Multiple options considered, latest new question is whether to support globs (? and \*) |
| 125 | + * [alexei] uBlock was interested in checking if the numeric value for a content length is over a limit. |
| 126 | + * [oliver] Seems like a nice use case to address. |
| 127 | + * [rob] Possible to create multiple patterns to match that, but it would be quite a hack. |
| 128 | + * [rob] In the issue I proposed a simple substring match to enable the browser to easily/quickly reject a rule before evaluating a more complicated version of the pattern. |
| 129 | + * [oliver] We were hoping that globs would offer the balance between functionality and performance. Would that work in Firefox? |
| 130 | + * [rob] I would have to profile. Internally we transform globs to regular expressions except for very simple cases. |
| 131 | + * [rob] Is there a timeline on settling the design? |
| 132 | + * [oliver] Soon. This is the last major thing to resolve before we release the API. |
| 133 | + * [timothy] I think globs would be okay. We have regexp in other places, so I wouldn't be opposed to that. |
| 134 | + |
| 135 | +[PR 641](https://github.com/w3c/webextensions/pull/641): Proposal: Per-extension language preferences |
| 136 | + |
| 137 | + * [timothy] Jackie opened a PR with a proposal for setting the language. |
| 138 | + * [jackie] Feedback is welcome. |
| 139 | + |
| 140 | +[PR 569](https://github.com/w3c/webextensions/pull/569): Proposal: i18n-system-languages |
| 141 | + |
| 142 | + * [timothy] What is the status of this PR? |
| 143 | + * [rob] Does not have a sponsoring browser. Our proposal process requires a sponsoring browser before merging proposals. |
| 144 | + * [timothy] I'd be interested in sponsoring this. |
| 145 | + * [carlos] Devlin also mentioned interest in sponsoring this. |
| 146 | + * [oliver] On our side we would not mind sponsoring. |
| 147 | + * [carlos] So Rob, what do you think about it? |
| 148 | + * [rob] I'll take a look and probably sign off. |
| 149 | + |
| 150 | +End of meeting - random questions |
| 151 | + |
| 152 | + * Automated extension API testing |
| 153 | + * [simeon] What is the status of automated testing of extension APIs? |
| 154 | + * [timothy] We don't have support for that yet in Safari, but will look into developing the primitives to enable the prototype that Patrick built to work. |
| 155 | + * TPAC 2024 |
| 156 | + * [timothy] TPAC 2024 is in Anaheim. |
| 157 | + * [simeon] We were waiting until an official announcement was made. |
| 158 | + * [oliver] Registration is already open. |
| 159 | + * [timothy] Without official announcement we cannot book the specific day, but if you are interested in participating you may as well register now. |
| 160 | + |
| 161 | +The next meeting will be on [Thursday, July 4th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=6685e600,384) |
0 commit comments