Skip to content

Latest commit

 

History

History
135 lines (110 loc) · 10.5 KB

2022-09-15-wecg.md

File metadata and controls

135 lines (110 loc) · 10.5 KB
Raw

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 Zoom issues? Ping @robwu (Rob Wu) in chat

Agenda: github issues

The meeting will start at 3 minutes after the hour.

  • Carry-over from previous meetings
    • None
  • Other new issues
    • Issue 258: Per-extension language preferences
    • Issue 269: declarativeNetRequest API: have isUrlFilterCaseSensitive condition set to false by default
    • Issue 270: Inconsistency: devtools.panels.create()
    • Issue 271: Proposal: extend the manifest file so that extensions can extend the permissions API
    • Issue 259 and Issue 272: Proposal: browser.alert.create()
  • Check-in on ongoing issues
    • Issue 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: Per-extension language preferences

  • [carlos] (summarizes issue and recent comment at #258 (comment))
  • [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: 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: 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: 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.
  • [simeon] This issue is more complicated than we have time left in this meeting, and needs more exploration in the issue.

Issue 259 and Issue 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: DNR: disable individual static rules

  • [felipe] Added a couple of comments on the issue; one: API proposal, two: WIP implementation details + benchmark. 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). In a few hours we will also have the TPAC 2022 session. Encouraging anyone interested to join.