Skip to content

Latest commit

 

History

History
141 lines (109 loc) · 11.2 KB

2022-04-28-wecg.md

File metadata and controls

141 lines (109 loc) · 11.2 KB
Raw

WECG Meetings 2022, Public Notes, Apr 28

  • Chair: Simeon Vincent
  • Scribes: Rob Wu

Time: 8 AM PST = https://everytimezone.com/?t=6269d900,3c0 Call-in details: WebExtensions CG, 28th April 2022 Zoom issues? Ping @robwu (Rob Wu) in chat

Agenda: discussion in #201, github issues

The meeting will start at 3 minutes after the hour.

  • Carry-over from previous meetings
    • Issue 198: Proposal: action.default_area=navbar and action.default_area=hidden
    • Update on Issue 170: Proposal: Offscreen Documents for Manifest V3
  • Other new issues
    • Issue 188: Inconsistency: Permissions "menus"
    • Issue 203: API to query the navigation history of a specific tab
    • Issue 204: Remove object-src from the CSP (at least in MV3)
  • Check-in on ongoing issues
  • Open discussion queue (add yourself at the bottom)
    • Introduce new Safari Extensions manager

Attendees (sign yourself in)

  1. Rob Wu (Mozilla)
  2. Giorgio Maone (NoScript)
  3. Simeon Vincent (Google)
  4. Timothy Hatcher (Apple)
  5. Oliver Dunk (1Password)
  6. Steven McLintock (1Password)
  7. Bradley Cushing (Dashlane)
  8. Jessie Berlin (Apple)
  9. Richard Worth (Capital One)
  10. Igor Oleinikov (Grammarly)
  11. David Johnson (Apple)
  12. Sam Macbeth (DuckDuckGo)
  13. Frederic Rivain (Dashlane)
  14. Krzysztof Modras (Ghostery)
  15. Tim Heflin (Keeper)
  16. Felipe Erias (Igalia)
  17. Alexei (Privacy Badger)
  18. Rainer Enders (Keeper Security)
  19. Mukul Purohit (Microsoft)
  20. Carlos Jeurissen (Jeurissen Apps)

Meeting notes

Issue 198: Proposal: action.default_area=navbar and action.default_area=hidden

  • [simeon] At the moment, when an extension is installed in Chrome, the extension action button appears in the extension menu by default. Firefox allows extensions to specify the default area. The feature request is to allow extensions to specify that area. Any objections?
  • [rob] Does Chrome have any objections against it?
  • [simeon] Other UI work is in progress, at the moment we aren't looking to implement this. This is not a useful signal, e.g. if all extensions ask to be shown by default. I'll refer to my comments from the last time.
  • [carlos] Suggestion is to allow extensions to offer a hint to the browser, so that (different) browsers can act on the hint.
  • [timothy] If implemented, the API names should be generic where possible. E.g. navbar would be quite Firefox-specific and possibly not applicable to mobile.
  • [carlos] Is Chrome open to feedback from developers on the UI updates? If so, when and how should we test?
  • [simeon] Early implementation work can be seen in Canary as it is merged into main. Devs are always welcome to share feedback based on their Canary experiences. In this case, though, some of it may be landing behind a flag, which is obviously not as discoverable. I will start some conversations about how to solicit dev feedback, but I anticipate we will post on the chromium-extensions group and possibly the WECG Matrix room.
  • [bradley] Integration in the UI (e.g. pinning) is an important part of onboarding.
  • [jessie] APIs to query the state would be more feasible than APIs to set the UI state.
  • [simeon] The action.getUserSettings API allows extensions to determine whether the extension button is pinned.

Update on Issue 170: Proposal: Offscreen Documents for Manifest V3

  • [rainer] What's the status of this project? Is this being actively worked on? A focus?
  • [simeon] On the Chrome side it's top of mind, but we haven't started the implementation yet. We hope to plan the implementation to aim for a prototype this quarter.
  • [rainer] What's the level of interest in this feature?
  • [simeon] My impression is that this is a key component of MV3 that solves several open issues with MV3.
  • [frederic] Implication on MV2/MV3 deadline when this feature is not ready yet? Are we pushing down the deadline?
  • [simeon] It is safe to say that we are also concerned about providing extension authors enough runway to implement the changes. At the moment no other updates on that.

Issue 188: Inconsistency: Permissions "menus"

  • Proposal is to drop “context” and go with “contextMenus”.
  • [rob] When FF added support we used "contextMenus", but over time added more generic functionality (e.g. the tools_menu context) and introduced the more generic “menus” name. Safari also supports “menus”.
  • [rob] This is also a perfect opportunity to resolve a long-standing weirdness in the API: contextMenus.create returns an integer/string instead of a Promise.
  • [simeon] Open to discussion, but cannot commit. Will follow up with the team to discuss and reply on the issue.
  • [rob] Would be ideal if we could get this in for MV3.

Issue 203: API to query the navigation history of a specific tab

  • [rob] Popular feature request to get the back/forward history of a given tab. Curious if there's cross browser interest in this feature. At the moment extensions can navigate back/forward, but they cannot see where this action will take them. All browsers maintain some concept of history, and it seems viable to expose this to developers.
  • [timothy] Proposal sounds logical, no objections.
  • [rob] In the proposal I suggest 3 fields (url, title, favIconUrl) by default. Main purpose is to know where the extension will navigate to, not to duplicate history (which would be significantly more complex, e.g. cloning history state).
  • [olliver] would activeTab have implications here?
  • [simeon] I would think so
  • [rob] In the proposal I suggest the tabs permission to control visibility of sensitive fields.
  • [simeon] Initial hesitation here are privacy concerns, but open to API discussion.
  • [rob] Could be resolved with permissions; no more privacy leakage than current tabs/history/webNavigation APIs.
  • [timothy] There could be privacy concerns. Will need additional consideration on the Safari side.

Issue 204: Remove object-src from the CSP (at least in MV3)

  • [rob] Object-src is to block plugin execution, which has been removed from Firefox and Safari, Chrome slated to drop plugin support soon. Firefox and Chrome require that extensions specify object-src. Seems like this has been simply carried over from MV2.
  • [timothy] Safari does not support plugins. Supportive.
  • [simeon] Sounds like a good clean up, I'm supportive of this.
  • Resolution: Drop object-src from the extension CSP in all browsers.

Issue 162: Declarative Net Request proposal: disable individual static rules

  • See also crbug.com/1225229
  • [felipe] Brought this to the group a few weeks ago. Since then I've reworked the proposal and been working on performance testing. The problem is that static rulesets can only be enabled/disabled as a whole. Last year there was a problem where a popular extension had a misbehaving rule and Google Docs users began to encounter problems. A fix was deployed within 24 hours. In MV3 this kind of quick turnaround will not be possible. We're looking at extending the API to address this situation. Expectation is that this will not be called often, but when it is it will be critical.
  • [timothy] Appreciate the concern and need for this, but hesitant around "won't be called often". Will likely need better safeguards to ensure that it is not called often. Got me thinking why you can't just have a dynamic rule with a high priority that supersedes the existing “broken” rule.
  • [simeon] Historically the Chrome team has also been thinking about this, and indeed declaring a higher-priority rule is generally the way we've thought about supporting this use case. It's not ergonomic, but should be functional.
  • [felipe] Concern that this could also conflict with other rules.
  • [simeon] That concern makes sense. Last time I looked at this proposal there was no proposal doc linked and we had concerns about performance implications, etc. With more details (docs) the engineering team can take a closer look.
  • [krzysztof] More perspective from another content blocker. We'd prefer to disable a rule over specifying a high-priority rule to minimize breakage. This probably happens a couple times a month. In terms of rule update frequency, Ghostery updates once a day. EasyList updates multiple times a day. We can currently ship changes within hours, but if we had to update extensions it would take days.
  • [simeon] Will get the doc to the engineering team, and revisit this issue next time.

Issue 119: Proposal: add optional_host_permissions

  • [carlos] This has been implemented in Chrome and Safari, and is on the tracker in Firefox.
  • [rob] Seems like there's no action here. It's something that came up in the group and has been/is being implemented by all browsers.
  • Resolution: mark item as fixed (+ create fixed label).

Status of action.openPopup() (related issue at developer.chrome.com repo)

  • [simeon] Don't have that much to say, other than it looks like a documentation bug that we should fix in the documentation.
  • [carlos] In Chrome it's MV3-only.
  • [timothy] In Safari it's available in MV2 and MV3. We never did page actions like Chrome, so page/browser actions are aliases.
  • [oliver] I am working on patches for Firefox in https://bugzilla.mozilla.org/show_bug.cgi?id=1755763.

Jessie: introducing New manager on Safari extension team

  • [jessie] David Johnson is the new manager of the Safari extension team at Apple.

Bikeshed: "fixed" label naming

  • [rob] Fixed or Complete are fairly generic. Would like to have something clearer such as “stage: implementation”
  • [simeon] “stage” sounds more formal than the current state of the group.
  • [simeon] As is the way of bikeshedding, it turns out that this is more complicated than expected. Let's continue in a new issue: #205

The next meeting will be on Thursday, May 12th, 8 AM PST (3 PM UTC).