-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publish minutes of 2024-11-21 meeting #726
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,163 @@ | ||
| # WECG Meetings 2024, Public Notes, Nov 21 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PDT = https://everytimezone.com/?t=673e7800,3c0 | ||
| Call-in details: [WebExtensions CG, 21st November 2024](https://www.w3.org/events/meetings/a97adab8-e1ae-4a2b-85cf-e6b6d3d35f00/20241121T080000/) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #721](https://github.com/w3c/webextensions/issues/721), [github issues](https://github.com/w3c/webextensions/issues) | ||
|
|
||
| The meeting will start at 3 minutes after the hour. | ||
|
|
||
| See [issue 531](https://github.com/w3c/webextensions/issues/531) for an explanation of this agenda format. | ||
|
|
||
| * **Announcements** (2 minutes) | ||
| * **Triage** (15 minutes) | ||
| * [Issue 722](https://github.com/w3c/webextensions/issues/722): A multi-tab broadcast version of chrome.tabs.sendMessage | ||
| * [Issue 723](https://github.com/w3c/webextensions/issues/723): Proposal: Allow selection of manifest JSON when loading unpacked extensions | ||
| * [Issue 724](https://github.com/w3c/webextensions/issues/724): I18N: Support more valid locales: language-script and language-script-region | ||
| * [Issue 725](https://github.com/w3c/webextensions/issues/725): Consider approach to allow importmap | ||
| * **Timely issues** (10 minutes) | ||
| * **Check-in on existing issues** (20 minutes) | ||
| * [PR 676](https://github.com/w3c/webextensions/pull/676): Proposal: Public Suffix API | ||
| * [PR 542](https://github.com/w3c/webextensions/pull/542): Add content scripts section in specification | ||
| * [PR 529](https://github.com/w3c/webextensions/pull/529): Add permissions.requestSiteAccess() API proposal | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. Oliver Dunk (Google) | ||
| 3. Timothy Hatcher (Apple) | ||
| 4. David Johnson (Apple) | ||
| 5. Simeon Vincent (Mozilla) | ||
| 6. Mukul Purohit (Microsoft) | ||
| 7. Carlos Jeurissen (Jeurissen Apps) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 722](https://github.com/w3c/webextensions/issues/722): A multi-tab broadcast version of chrome.tabs.sendMessage | ||
|
|
||
| * [rob] We wanted to reduce broadcast semantics, not more. | ||
| * [timothy] Don't think that we'd save more. | ||
| * [rob] Not having broadcast prevents some optimizations. I see serialization cost as significant. Performing that once would be strictly better. | ||
| * [timothy] If we are still awaiting results, then there is no benefit. Broadcast without reply can indeed be quicker. | ||
| * [oliver] Reporter mentions background script being locked, wondering whether that is an issue with the extension or the extension API. | ||
| * [timothy] I'm inclined to be opposed to this. Don't see significant performance gains. | ||
| * [rob] I think there are performance gains. Initial JS->internal serialization and IPC is significant and showing up in performance profiles. Getting this to one initial message+IPC can result in a measurable performance improvement. Would not want response semantics in the initial version unless there's a very good reason to support it. | ||
| * [timothy] In favor of a no-response version. Agreed that not serializing many times may also be a time saver. | ||
| * [simeon] I expected no response due to the broadcast nature of the API. Generally when you yell into a crowd you don't expect a response. | ||
| * [oliver] I can follow up on the Chrome side. | ||
| * [rob] Hack is to use a storage.local.onChanged listener - also has broadcast semantics to content scripts. Downside is that it also stores the items to disk. | ||
| * [timothy] I'll put the safari:neutral on the issue. | ||
|
|
||
| [Issue 723](https://github.com/w3c/webextensions/issues/723): Proposal: Allow selection of manifest JSON when loading unpacked extensions | ||
|
|
||
| * [timothy] There have been efforts to allow the same manifest to be used across browsers. | ||
| * [oliver] Concerned about not requiring manifest.json in some cases. | ||
| * [rob] I'm against supporting anything other than “manifest.json” for loading extensions. Adds complexity to the browser and external tools. Extension developers can create a build script, or even copy to the content to a new folder. | ||
| * [timothy] We do not support loading unpacked extensions, so I'm neutral on Safari's end. | ||
| * [oliver] We are opposed on Chrome's side. | ||
| * [rob] Since Chrome and Firefox are opposed, can we just close the issue? | ||
| * [timothy] Sounds good to me. | ||
|
|
||
| [Issue 724](https://github.com/w3c/webextensions/issues/724): I18N: Support more valid locales: language-script and language-script-region | ||
|
|
||
| * [timothy] Recently fixed in Safari; there was a debate in another issue about Firefox's support for language script tags but Chrome does not. I fixed this in Safari, and Safari will now support loading based on the script tag as well. | ||
| * [rob] Example? Is this about the third component? | ||
| * [timothy] The second component, e.g. “Hant” in Zh-Hant-HK | ||
| * [carlos] Many extensions have a script in their language tag, and it depends on the browser which should be supported. | ||
| * [carlos] If an extension specifies zh-Hans, and a browser is requesting zh-CN. Will the browser actively look for zh-Hans? | ||
| * [timothy] If extension support zh-Hans, and the user has not set it, the browser will find the right one. If the extension has zh-CN, and user has zh-Hans-US, then zh-CN would still be picked. We rely on some internal Apple API to resolve the mapping. | ||
| * [rob] Is there a standard or API we can reference? | ||
| * [timothy] Not sure whether it is built-in in ICU. I just know that we had a method in WebKit that we can use.. | ||
| * [rob] WebKit is open source, so there may be a reference you can share | ||
| * [timothy] No, it calls a system API. | ||
| * [carlos] Comes down to whether or not browsers try to have a better match between what the browsers support and what the developers provide. | ||
| * [timothy] Only affects a few languages. Having smarter fallback for Hans, there should be a way to address this without introducing a black box. If there's a direct match there are no issues. | ||
| * [oliver] In principle this sounds good, but I don't have enough context on internal capabilities or positions. | ||
| * [rob] In principle better localization support sounds good. Not currently well defined what should happen. Hesitant to add more locale detection capability without a definition. If someone would like to see this, please write up a high level description of what you'd like to see. | ||
| * [oliver] I think at TPAC the loc group said they could help with this kind of thing | ||
| * [carlos] The [i18n-tracker label](https://github.com/w3c/webextensions/labels/i18n-tracker) is already on this issue. | ||
| * [timothy] If you hover over the label you can see that it brings it to their attention but may not get a response. | ||
| * [rob] Eemeli is who we spoke with at TPAC. | ||
| * [rob] I'd like to put neutral or supportive from Firefox side here since I am supportive of improving localization support, but presently it is difficult to identify anything actionable or alignable here. | ||
| * [timothy] I think Firefox is in good shape here. If a user selected zh-Hans-US it behaves correctly. Chrome is the only one that doesn't understand the script codes, I believe. | ||
| * [rob] I think we check the browser language against the list of localizations in the extensions. The logic isn't terribly smart. | ||
| * [timothy] Extension author had to switch to zh-CN or zh-TW to get it to work in Chrome. | ||
| * [carlos] Does this have any influence on the language fallback? Does it still fall back to less specific locales? | ||
| * [timothy] In Safari, yes. | ||
| * [carlos] I specifically created a patch for Firefox to improve language fallbacks. | ||
| * [rob] Carlos, do you have more context on desired outcomes? | ||
| * [carlos] Asked Jackie to for actionable items for this issue. Assuming we can declare it as being about using a more advanced algorithm for language matching. | ||
|
|
||
| [Issue 725](https://github.com/w3c/webextensions/issues/725): Consider approach to allow importmap | ||
|
|
||
| * [timothy] Interesting - define import map in extension and use that in the extension, to support dev / production builds. | ||
| * [timothy] I prefer declaring in the manifest over weird nonce stuff. | ||
| * [simeon] I think we've discussed having an import maps key in the manifest. | ||
| * [rob] Is this about every extension script, content script, whatever? | ||
| * [timothy] Had same question, it seems a global thing. Can also see potentially separate import maps for content scripts vs background scripts. | ||
| * [oliver] Would be curious to hear from devs who've used import maps on whether it would be necessary to have them for multiple contexts. | ||
| * [rob] In background pages (event pages) it is already possible to have import maps in the background page by declaring a background “page” and embedding the import map in the background script. | ||
| * [rob] Do Service workers support import maps? | ||
| * [oliver] Seems like it's an open discussion for service workers | ||
| * https://github.com/WICG/import-maps/issues/2 | ||
| * [carlos] Looks like importmaps are not supported for workers. | ||
| * https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap | ||
| * [rob] Seems premature for us to do anything here. No platform support for import maps in service workers. Content scripts don't have first class support for modules. | ||
| * [oliver] Would like to look at imports in content scripts. There are workarounds that exist today but would be nice to address. | ||
| * [rob] First-class support for modules in content scripts would be nice. | ||
| * [rob] I'd say I'm neutral, but there's not much we can do now. In extension pages and background pages, they can use the script element for now. In theory if we had first class support for import maps that would make static analysis easier. | ||
| * [timothy] Neutral on Safari's side. Also added a summary comment. | ||
| * [oliver] Neutral on Chrome's side too. | ||
|
|
||
| [PR 676](https://github.com/w3c/webextensions/pull/676): Proposal: Public Suffix API | ||
|
|
||
| * [timothy] Lots of back and forth here recently. Is there anything we need to hash out? | ||
| * [oliver] Since we last checked in here, Simon from the PSL left a few comments. I spoke to Devlin, and at first he thought that it was exposing the version. Now that he realized that there are more methods, he has to take another look. | ||
| * [rob] I spoke with the PR author (mckenfra). I would like to get this to the finish line. Don't think we should block further beyond exposing real issues. | ||
| * [timothy] Agreed. As long as the format is reasonable and won't be affected by future changes to PSL. | ||
| * [oliver] Same. | ||
|
|
||
| [PR 542](https://github.com/w3c/webextensions/pull/542): Add content scripts section in specification | ||
|
|
||
| * [timothy] Oliver's been working on this and pushed some recent changes. | ||
| * [oliver] Didn't have anything specific, but wanted to check in on some of the recent comments. There are a few open questions. One was on Safari regarding matchAboutBlank. Chrome currently checks if there's an about scheme, Firefox checks about:srcdoc and about:blank. Not sure about Safari | ||
| * [timothy] about:blank and srcdoc makes sense, about: seems too permissive. | ||
| * [oliver] Retrospectively agree, but not sure if there are other cases where we'd no longer be injecting. | ||
| * [rob] I implemented support in Chrome. There are no other about: schemes that could be matched. Firefox has more about:-schemes, but these should not be matched by extensions. | ||
| * [oliver] Please take another look, would be great to land. | ||
| * [timothy] I'll read this through as well. | ||
| * [timothy] Would like world to support lowercase as well for consistency, ISOLATED + isolated. | ||
| * [simeon] Lowercase is the more prevalent pattern on the web. For example, event names are lowercase. There are some unusual cases, like DOMContentLoaded, but generally they're all concatenated lowercase. | ||
| * [oliver] Also note that there appears to be a problem with the Bikeshed rendering. If you see something odd in the rendered version, | ||
| * [rob] This is an issue that has been there for a while - mckenfra also ran into the CI failures. | ||
|
|
||
| [PR 529](https://github.com/w3c/webextensions/pull/529): Add permissions.requestSiteAccess() API proposal | ||
|
|
||
| * [oliver] Now available in Chrome. We published a blog post earlier this week. | ||
| * https://developer.chrome.com/blog/new-extensions-menu-testing | ||
| * [oliver] toph wondered whether the name should change to requestHostAccess instead of requestSiteAccess. | ||
| * [timothy] Host sounds like a more logical name, would like to have thought about it sooner. | ||
| * [rob] Is it already on Chrome stable? | ||
| * [oliver] Has not shipped to stable yet. | ||
| * [simeon] plz change 🙂 | ||
| * [rob] Not opposed to changing. Host is more consistent. If you compare the host_permissions manifest key to this feature, are they sufficiently alike? | ||
| * [oliver] I think so, you need a value in host permissions or optional host permissions to use this API. You're requesting a tab or URL, so there you could argue it's a “site” request. | ||
| * [timothy] I prefer Host if there is still time to change it, otherwise we'll be stuck with it. | ||
| * [oliver] I'll get back to the team and discuss this. | ||
|
|
||
| [PR 569](https://github.com/w3c/webextensions/pull/569): i18n-system-languages | ||
|
|
||
| * [carlos] This is for OS language. I think we can merge this now with Safari's recent change. | ||
| * [timothy] I think so. Someone from Firefox want to approve the PR? | ||
| * [rob] I will take a look. | ||
| * [timothy] Congrats on landing changes in two places! | ||
| * [rob] If he submits a patch to Chrome too, he will single handedly propose and add it to all browsers. | ||
|
|
||
| The next meeting will be on [Thursday, December 5th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=6750ed00,384). | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: this W3 link is now 404. It used to be correct before, perhaps that is why so few people joined today?
The link will be correct for the next meetings.