Skip to content

Latest commit

 

History

History
167 lines (131 loc) · 13.8 KB

2022-09-29-wecg.md

File metadata and controls

167 lines (131 loc) · 13.8 KB
Raw

WECG Meetings 2022, Public Notes, Sep 29

  • Chair: Timothy Hatcher
  • Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=6334e000,384 Call-in details: WebExtensions CG, 29th September 2022 Zoom issues? Ping @zombie (Tomislav Jovanovic) 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 276: Proposal: declarative localization of title in contextMenus.create() and contextMenus.update()
    • Issue 278: Should browser.storage.local.set({"": ""}) and browser.storage.local.get("") be valid?
    • Issue 280: Inconsistency: session and dynamic DNR rules are applied with differing priorities across browsers
    • Issue 282: Inconsistency: declaring background scripts in a neutral way
    • Issue 281: Inconsistency: runtime.getURL()
    • Issue 284: Main world User Script shared params
    • Issue 285: Inconsistency: CSP sandbox directive and content script and style injection into pages
  • Open discussion queue (add yourself at the bottom)
    • None
  • Check-in on ongoing issues
    • Issue 205: Label naming for issues where consensus has been achieved
    • Issue 274: Proposal: i18n.getLanguageDictionary
    • Issue 258: Per-extension language preferences
    • Issue 188: Inconsistency: Permissions "menus"
    • Old housekeeping issues (Added by Carlos, in an attempt to reduce the amount of open issues)
      • Issue 1: What to do with the older CG?
      • Issue 9: New Issue Template
      • Issue 29: Update contributing guide with info on current communication channels
      • Issue 30: Set up Bikeshed spec pipeline

Attendees (sign yourself in)

  1. Tomislav Jovanovic (Mozilla)
  2. Rob Wu (Mozilla)
  3. Richard Worth (Capital One)
  4. Tim Heflin (Keeper)
  5. Matt Gibson (Bitwarden)
  6. Jonathan Kingston (DuckDuckGo)
  7. Carlos Jeurissen (Jeurissen Apps)
  8. Steven McLintock (1Password)
  9. Giorgio Maone (NoScript, Tor)
  10. Benjamin Bruneau (1Password)
  11. Jack Works (Sujitech)
  12. Frederic Rivain (Dashlane)
  13. Oliver Dunk (1Password)
  14. Annie Chen (1Password)
  15. Simeon Vincent (Google)
  16. Tyler Carson (Keeper)
  17. Lucas Selker (Dashlane)
  18. Mukul Purohit (Microsoft)
  19. Jack Steam (Merlyn Mind)
  20. James Hycner (Keeper)

Meeting notes

Issue 276: Proposal: declarative localization of title in contextMenus.create() and contextMenus.update()

  • [carlos] Author want to be able to declare localization IDs in extension APIs so that it does not have to dynamically update the items in response to localization changes. Basically syntactic sugar.
  • [timothy] (Apple/Safari: neutral) Personally not opposed, but also agree with backward compatibility concerns expressed in the issue.
  • [tomislav] (Mozilla/Firefox: neutral) Not opposed either. But have to think about the whole range of APIs where it would have to be applied.
  • [timothy] Are you saying that if it's declarative, you wouldn't have to manually set the string as you do now.
  • [tomislav] Previously the line was static (manifest) vs dynamic APIs, but now we're blurring the line to also cover things that are updated infrequently.
  • [carlos] So the action item would be to list down which APIs and properties supporting localisation strings would make sense.
  • [timothy] Encourage browser vendors to add labels indicating their supportive status on this issue

Issue 278: Should browser.storage.local.set({"": ""}) and browser.storage.local.get("") be valid?

  • [timothy] We had a bug in Safari where getting/setting an empty key failed. Wanted to get a clarification on whether an empty key should be valid.
  • [rob] Someone already explored the behavior in Chrome and Firefox, where it works.
  • [simeon] Off-hand, I don't know if the key can be empty in JavaScript.
  • [tomislav] It can be, using bracket notation.
  • [simeon] Oh, I don't like that! Okay, in that case I think we should support it, but I don't like it.
  • [timothy] (Apple/Safari: supportive/implemented) In any case we plan to fix it. We should eventually also document this in the spec.
  • [tomislav] We don't like current behavior either, but from the Safari bug report, it seems we're stuck with it.
  • [rob] Meta-question: How do we ensure that this ends up in the spec?
  • [timothy] Adding the spec clarification label.

Issue 280: Inconsistency: session and dynamic DNR rules are applied with differing priorities across browsers

  • [timothy] Rob's recent investigation into the priority of rules being applied across browsers, it seems Safari and Chrome apply them in the exact opposite order (session, then static).
  • [simeon] Before we resolve to do that, some of the history here: before Chrome introduced the priority here: everything was equal weight, and dynamic rules had higher precedence than static rules, because dynamic rules had to be able to update static rules. Now that we have more control, with an explicit way to set priority, this is not necessary any more. But we would have to consider the existing extensions if we want to change this.
  • [timothy] It might change at this point for Chrome.
  • [tomislav] Since Firefox is in the process of implementing, we can align with the actually “better” way that Safari is doing, if Chrome could investigate how feasible it is for them to change current behavior, that would be a good way to align everyone.
  • [rob] The origin of the rule makes sense, but in the current shape of the API it is not strictly necessary. We should aim to unify the behavior.

Issue 282: Inconsistency: declaring background scripts in a neutral way

  • [carlos] Since browsers have different levels of support (service_worker and event pages), it would be nice if there is one syntax that allows the extension to work in both if they stick to a common set of APIs (no worker-specific APIs and no event page-specific APIs).
  • [simeon] I was recently speaking to a tech writer of the Chrome team, and was observing that it's unfortunate that we switched from a list of scripts to one service_worker plus need to use importScripts. Short-term, the challenge for MV3, it would be confusing to overload the “scripts” key.
  • [rob] That concern could be addressed with requiring the suggested "prefered_environment" key, which would be a clear signal to developers that they cannot just use “scripts” and expect it to work in Chrome. So either “service_worker”: , or “scripts”+”preferred_environment”, or (if event pages are supported) “scripts”.
  • [timothy] (Apple/Safari: supportive) I am supportive of this clean syntax.
  • [rob] (Mozilla/Firefox: supportive) Supportive for the same reasons.
  • [simeon] Personally like the idea, will follow up with the team to discuss further.

Issue 281: Inconsistency: runtime.getURL()

  • [carlos] Tested and found several inconsistencies in the runtime.getURL API.
  • [timothy] I will follow up with Safari-specific inconsistencies at least. A lot of it boils down to how URLs are normalized; Safari and Firefox appear to be simplifying the URL.
  • [tomislav] I'd like to thank Carlos for this detailed test. This could basically be a set of tests to support the spec.
  • [oliver] new URL("chrome-extension://test").origin returns different values in Chrome and Node, because one recognises the scheme and one doesn't. This may be a good contribution to standards in general to make things more consistent.
    • [tomislav] This is because the environment does not recognize the schema and does not parse the URL. This is the same in Firefox, and I believe is expected behavior.
    • [timothy] and also in Safari.
  • [simeon] FYI: If you use getURL from a content script, and the extension has use_dynamic flag in web accessible resources, a dynamic ID will be returned instead of the fixed chrome-extension: URL. That may be notable to consider in a test suite.

Issue 284: Main world User Script shared params

  • [jonathan] We want to offer the ability to the user to change the behavior of content scripts. Currently the content script has to send messages to the background page or use other async APIs to fetch these global preferences.
  • [tomislav] Once the script is injected in the main world, there is no distinction between the page script and the main world script. Is it feasible for the extension to use a synchronous DOM event to communicate with the content script?
  • [jonathan] The issue is that the content script would have to fetch the configuration asynchronously.
  • [anton] One way to solve this in the past is to define a function scope, define the var in the function scope and expose this to the script. Would be nice if the browsers provide a native implementation, but otherwise we can work around it.
  • [jonathan] That would require dynamic scripts (strings).
  • [rob] For scripting.executeScript we could consider supporting the existing args key for file (not just func), which would execute the file as code in a function scope with the arguments being passed, and similarly for the scripting.registerContentScripts API. While conceptually understandable to JS devs, it may be more complicated to implement by browsers though.
  • [rob] While not a blocker, it would be nice to consider this functionality in the context of the user script API (#279).

Issue 285: Inconsistency: CSP sandbox directive and content script and style injection into pages

  • [rob] I noticed this issue in the past and discussed it with Devlin (Chrome), and designed an update to the content script API to address this inconsistency: https://bugzilla.mozilla.org/show_bug.cgi?id=1411641#c43. Timothy and I should probably look into this more closely and revisit the issue next meeting.

Issue 205: Label naming for issues where consensus has been achieved

  • [carlos] We've introduced some labels, so maybe this is no longer needed?
  • [rob] This has been addressed with the supportive/implemented labels.
  • [timothy] Typically, when there are two or more implementations, there is consensus.

Issue 274: Proposal: i18n.getLanguageDictionary

  • [carlos] Discussion on how to split this API from the bigger issue #258, opinions on naming?
  • [simeon] Not concerned with the naming specifically; last time I was confused about the specific word “dictionary” in the signature, but don't want to focus too much on naming for the moment. I'm supportive of this in abstract.
  • [timothy] (Apple/Safari: supportive) I'm supportive of it for Safari and have already added the supportive: safari label.
  • [tomislav] (Mozilla/Firefox: neutral) Not opposed either.

Issue 258: Per-extension language preferences

  • [carlos] This is the other half of the previously discussed issue.
  • [tomislav] Would we need to provide a UI, or is an extension API sufficient?
  • [carlos] The value of this API is that both the browser and user/extension can change this.
  • [tomislav] Then I don't understand why this is per extension.
  • [carlos] The browser would allow a native toggle per extension language, like Android.
  • [tomislav] I will read the full issue later. Note that implementing UI is a high bar, an API-only approach would be preferred.
  • [oliver] Would this also affect things like the extension name?
  • [timothy] Curious whether there is user demand for this feature. Is this pretty common for bilingual people to change this?
  • [carlos] Can conceive several examples.
  • [rob] One potential abuse vector for this api is if extensions dynamically change their own name without user action, and try to masquerade as some other “official” trusted brand app.
  • [simeon] During TPAC I attended the web manifest session, where they discussed similar concerns about the web application being able to update metadata such as icons. I share the same concerns expressed there and by Rob.

Issue 188: Inconsistency: Permissions "menus”

  • [carlos] Did Simeon have time to follow up on this?
  • [simeon] Cannot follow up for the next two-three weeks, but will revisit later.

Old housekeeping issues (Added by Carlos, in an attempt to reduce the amount of open issues)

  • (ran out of time, moving to next meeting)

The next meeting will be on Thursday, October 13th, 8 AM PDT (3 PM UTC).