Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Publish minutes of 2022-09-15 meeting #275

Merged
merged 1 commit into from
Sep 15, 2022
Merged

Publish minutes of 2022-09-15 meeting #275

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
135 changes: 135 additions & 0 deletions _minutes/2022-09-15-wecg.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,135 @@
# WECG Meetings 2022, Public Notes, Sep 15

* Chair: Simeon Vincent
* Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=63226b00,384
Call-in details: [WebExtensions CG, 15th September 2022](https://www.w3.org/events/meetings/d7bbce8f-549f-46ea-b440-ea6902f8707c/20220915T080000)
Zoom issues? Ping `@robwu` (Rob Wu) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat)


## Agenda: [github issues](https://github.com/w3c/webextensions/issues)

The meeting will start at 3 minutes after the hour.

* **Carry-over from previous meetings**
* None
* **Other new issues**
* [Issue 258](https://github.com/w3c/webextensions/issues/258): Per-extension language preferences
* [Issue 269](https://github.com/w3c/webextensions/issues/269): declarativeNetRequest API: have isUrlFilterCaseSensitive condition set to false by default
* [Issue 270](https://github.com/w3c/webextensions/issues/270): Inconsistency: devtools.panels.create()
* [Issue 271](https://github.com/w3c/webextensions/issues/271): Proposal: extend the manifest file so that extensions can extend the permissions API
* [Issue 259](https://github.com/w3c/webextensions/issues/259) and [Issue 272](https://github.com/w3c/webextensions/issues/272): Proposal: browser.alert.create()
* **Check-in on ongoing issues**
* [Issue 162](https://github.com/w3c/webextensions/issues/162): DNR: disable individual static rules
* **Open discussion queue (add yourself at the bottom)**
* None


## Attendees (sign yourself in)

1. Rob Wu (Mozilla)
2. David Johnson (Apple)
3. Simeon Vincent (Chrome)
4. Felipe Erias (Igalia)
5. Jack Steam (Merlyn Mind)
6. Matt Gibson (Bitwarden)
7. Timothy Hatcher (Apple)
8. Mukul Purohit (Microsoft)
9. Tim Heflin (Keeper)
10. James Hycner (Keeper)
11. Oliver Dunk (1Password)
12. Luca Greco (Mozilla)
13. Joe Medley (Chrome)
14. Carlos Jeurissen (Jeurissen Apps)


## Meeting notes

[there were zoom connectivity issues at the start of the meeting; meeting started ten minutes later than usual]

[Issue 258](https://github.com/w3c/webextensions/issues/258): Per-extension language preferences

* [carlos] (summarizes issue and recent comment at https://github.com/w3c/webextensions/issues/258#issuecomment-1248028674)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Summary of the issue is here #258 , not that comment. I reorganized the proposal on 2022-09-12.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

During the meeting, I have explained your issue in detail. Explained the fact you drew inspiration from the handling on Android, how there are use cases to have an app / extension in a different language than the OS / browser. And the proposed methods / solutions proposed by you (@hanguokai).

Only later after comments from Rob and Simeon, I have explained some points made in my comment. This happened in between:
[timothy] It would also leak to the browser UI (button labels etc).
[simeon] What is “create instance” in i18n.createLanguageInstance referring to?

Between those comments, @xeenon was asking for the getMessage syntax he found in this issue before. On which I mentioned the fact the original post first mentioned the getMessage-extension and was later extended / modified by you (@hanguokai) to include the other proposals (setCurrentLanguage, getCurrentLanguage, and so on). After which I mentioned the alternative syntax as is now described in #274.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@carlosjeurissen Sorry, I didn't attend this meeting. And thanks for the explanation.

* [rob] The API should indeed be async, not sync because otherwise the implementation would have to eagerly keep all languages in the content processes.
* [simeon] Would other browsers have concerns with the setter aspect of the feature request?
* [rob] Yes. Read-only is feasible, writable may impact the browser
* [carlos] The setter is only for the extension, not the browser.
* [rob] But the setter is not limited to just the current page, it has to be propagated to the whole browser.
* [timothy] It would also leak to the browser UI (button labels etc).
* [simeon] What is “create instance” in i18n.createLanguageInstance referring to?
* [carlos] Open to changing the name for clarity.
* [rob] As an action, would it make sense to split the issue in new ones?
* [carlos] I am not the issue author, but sounds good to me.

[Issue 269](https://github.com/w3c/webextensions/issues/269): declarativeNetRequest API: have isUrlFilterCaseSensitive condition set to false by default #

* [simeon] (summarizes issue) Observation that most rules are case-insensitive, so it would make sense to change default from case sensitive to case-insensitive.
* [simeon] Sounds reasonable, but initial thought is that the biggest concern could be backwards compatibility.
* [rob] Could introduce an API to explicitly set the default.
* [luca] Suggesting a manifest key since static rules are loaded at startup.
* [rob] A potential way to cover this is to introduce a dummy rule (a new action?) to change the default.
* [simeon] A dummy rule could make the implementation complex, since the order of rules now becomes significant.
* [rob] To make the design more comprehensible, we could limit to the “first” dummy rule at first.
* [luca] dummy rule may be interesting also because it may allow different rulesets to use a different default and help reduce the size in similar ways.
* [rob] Currently, the API combines all rulesets, and rules are extension-global. If we limit to “the first”, what would the first rule be?
* [simeon] Initial thought is to make this per-file (ruleset).
* [rob] I think that this general concept of supporting metadata at the top of the file is quite common, and useful. I support this functionality (Mozilla).
* [simeon] Good direction. Supportive from Google's perspective.
* [timothy] Supportive for Safari.
* [timothy] Older browser would ignore the rule and so the extensions will need to take that into account.
* [simeon] Taking a step back, for this issue is it preferable to introduce this new concept or simply change the default?
* [rob] In this specific case, changing the default value of the flag would be very reasonable, so we could save the more generic feature for later and proceed by changing the default of the flag. Those who want to be compatible with all versions of browsers (including before this change) could explicitly set the flag to true/false.
* [simeon] We will need to communicate the changes with developers.
* [timothy] At Apple we have the possibility to introduce quirks for handling built products produced against a given SDK version of the platform. Might be worth considering this as a possibility for the future. I know we've talked about the possibility of a manifest version 3.1 or something.
* [rob] I suspect that we'll have more breaking changes to DNR in the future, would like to avoid tying this to the manifest version.
* [timothy] Agreed. Even in the last year there have been many changes. Mostly additive though.
* [simeon] Perhaps a (DNR) version number to introduce breaking changes.
* [rob] perhaps an alternative to version numbers would be feature flags
* [simeon] Realize that we've moved far from the original issue, let's table the discussion and move on to the next issue.

[Issue 270](https://github.com/w3c/webextensions/issues/270): Inconsistency: devtools.panels.create()

* [simeon] Reported issue is that resolution of relative URLs are inconsistent; some relative to the current directory, others to the extension root.
* [simeon] Carlos noted that this is a broader issue beyond just the devtools API, including the manifest file.
* [carlos] Correct. After further testing, the browserAction.setIcon method is also relative in FF, while the handling of notifications.create is absolute.
* [timothy] Paths in manifest.json are always relative to the root.
* [luca] Think that this is a documentation bug.
* [simeon] Clearest next steps for this issue is to create tests to check behavior across browsers, and if there are differences, try to consolidate the behavior.
* [anton] Should I generalize the issue?
* [simeon] Should we generalize this issue, or file a new one?
* [timothy] Generalizing makes sense to me.
* [rob] We already have an actionable bug, a follow-up would be broader and less actionable.
* [rob] If Chrome and Safari are already behaving consistently, we could change Firefox's behavior for consistency, tied to MV3 to avoid backwards-compatibility issues.
* [carlos] How is this currently handled in Safari and Chrome.
* [simeon] We tend to handle paths relative to the root.
* [timothy] Since we are using the same class, paths are always relative to the root.
* [simeon] I will file a new issue for the general case.

[Issue 271](https://github.com/w3c/webextensions/issues/271): Proposal: extend the manifest file so that extensions can extend the permissions API

* [simeon] Extension API to extend the extension API?
* [rob] No, extending a web platform API.
* [simeon] Don't know if this strictly needs to be a platform capability.
* [anton] It's indeed possible to modify the globals with content scripts, but they would have to be injected in all frames.
* [rob] This issue is not just about changing runtime web APIs, but also about changing the behavior of how “allow” is interpreted. That's not the Permissions API but [Feature Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Feature_Policy/Using_Feature_Policy).
* [simeon] This issue is more complicated than we have time left in this meeting, and needs more exploration in the issue.

[Issue 259](https://github.com/w3c/webextensions/issues/259) and [Issue 272](https://github.com/w3c/webextensions/issues/272): Proposal: browser.alert.create()

* [simeon] API name and namespace aside, what do the browsers think of this functionality?
* [timothy] Supportive of the functionality (Safari).
* [simeon] Need to talk with the Chrome team, but personally supportive.
* [simeon] alert is the least complex functionality; prompt/confirm being async is more complex but would also be very useful. Not something that would fit in the web platform, but useful to extensions.
* [rob] Alert can be easily replaced by Notifications. I'd like to see more details in the issue on prompt and confirm. These APIs are listed as examples because they're already well-known on the web. There are other use cases that may require three buttons. Where do we draw the line between.
* [timothy] I like the idea of having a separate alert API as opposed to notifications. They show up drastically differently on the platforms, with alerts demanding immediate interaction while notifications are passive.
* [joe] Is there a way via design that you can prevent people from using one when they should use the other?
* [timothy] I know that people currently use Notifications when they should use alerts because they don't have the alert option. Documentation can definitely encourage, but can't technically enforce.
* [rob] Let's continue discussion offline given that we have run over.

[Issue 162](https://github.com/w3c/webextensions/issues/162): DNR: disable individual static rules

* [felipe] Added a couple of comments on the issue; [one: API proposal](https://github.com/w3c/webextensions/issues/162#issuecomment-1245662951), [two: WIP implementation details + benchmark](https://github.com/w3c/webextensions/issues/162#issuecomment-1248217901). In summary, we have been able to find strategies to ensure reasonable performance, and will continue working on the implementation and benchmarks. For more details, please check the issue and API proposal.

The next meeting will be on [Thursday, September 29th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=6334e000,384).
In a few hours we will also have the [TPAC 2022](https://github.com/w3c/webextensions/issues/232) session. Encouraging anyone interested to join.
8 changes: 5 additions & 3 deletions _minutes/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,24 +10,26 @@ After the end of each meeting, meeting notes are published here.

## Upcoming meetings

- 2022-09-15 at 8 AM PDT = https://everytimezone.com/?t=63226b00,384
- 2022-09-15 at 13:30 AM PDT = TPAC 2022 ([issue 232](https://github.com/w3c/webextensions/issues/232) - [agenda item with time zone conversion](https://www.w3.org/events/meetings/7bbba4a3-8305-45cd-a998-67ede8b0a1a1))
- 2022-09-29 at 8 AM PDT = https://everytimezone.com/?t=6334e000,384
- 2022-10-13 at 8 AM PDT = https://everytimezone.com/?t=63475500,384

## Past meetings

* 2022-09-15 ([minutes](2022-09-15-wecg.md))
* 2022-09-01 ([minutes](2022-09-01-wecg.md))
* 2022-08-18 ([minutes](2022-08-18-wecg.md))
* 2022-08-04 ([minutes](2022-08-04-wecg.md))
* 2022-07-21 ([minutes](2022-07-21-wecg.md))
* 2022-07-07 ([minutes](2022-07-07-wecg.md))
* 2022-06-23 ([minutes](2022-06-23-wecg.md))
* 2022-06-09 ([minutes](2022-06-09-wecg.md))

<details>
<summary><strong>All past meeting notes</strong></summary>

**2022**

* 2022-09-15 ([minutes](2022-09-15-wecg.md))
* 2022-09-01 ([minutes](2022-09-01-wecg.md))
* 2022-08-18 ([minutes](2022-08-18-wecg.md))
* 2022-08-04 ([minutes](2022-08-04-wecg.md))
* 2022-07-21 ([minutes](2022-07-21-wecg.md))
Expand Down