Skip to content

Files

Latest commit

1b83812 · Nov 11, 2021

History

History
149 lines (112 loc) · 12.2 KB

2021-11-11-wecg.md

File metadata and controls

149 lines (112 loc) · 12.2 KB

WECG Meetings 2021, Public Notes, Nov 11

  • Chair: Simeon Vincent
  • Scribes: Rob Wu

Time: 8 AM PST = https://everytimezone.com/?t=6179e800,384 Call-in details: WebExtensions CG, 11th November 2021 event Zoom issues? Ping @zombie (Tomislav Jovanovic) in chat

Attendees (sign yourself in)

  1. Simeon Vincent (Google)
  2. Oliver Dunk (1Password)
  3. Rob Wu (Mozilla)
  4. Alexei (Privacy Badger)
  5. Tomislav Jovanovic (Mozilla)
  6. Carlos Jeurissen (Jeurissen Apps)
  7. Timothy Hatcher (Apple)
  8. Nick McGuire (1Password)
  9. Brandon Lucier (1Password)
  10. Sam Macbeth (DuckDuckGo)
  11. Stuart Colville (Mozilla)
  12. Mukul Purohit (Microsoft)
  13. Maxim Topciu (AdGuard)
  14. Krzysztof Modras (Ghostery)
  15. Giorgio Maone (NoScript)

Queue (add yourself at the bottom)

  • <add yourself>

Meeting notes

Would be good to invite somebody from Google who can speak about Google's MV3 SW plans. (Alexei)

  • [simeon] Chatted with Devlin. He is tentatively planning to join the next meeting (in four weeks, since the next one in two weeks is scheduled due to Thanksgiving.
  • [alexei] Google has given a timeline, with the appearance that MV3 is stable. The community response has been largely negative. Wonderful that Devlin can join us. Would like to have a discussion to discuss the trade-offs and whether they make sense.
  • [carlos] Suggest to split SW discussion in two parts (1) missing APIs (#72 and proposal #134) and (2) lack of persistent background scripts (e.g. #44).
    • [simeon] [tomislav] [timothy] Agreed, this makes sense.

Do browser vendors have plans for addressing WASM startup times in MV3? (Oliver Dunk)

  • [simeon] Aware of this concern and investigating, but too early to make commitments.
  • [oliver] We use WebAssembly in our extension, and this causes a noticeable delay at startup, to the point that we may have to reconsider using WebAssembly in favor of JS.
  • [nick] The non-persistent background page forces us to re-initialize WASM all the time. It would be nice if it's possible to keep some WASM state between sessions.
  • [simeon] Utility in discussing it here is mostly making sure that browser vendors are aware of and considering these use cases.
  • [timothy] Also speaks to concern around startup times and optimizations in general.

Issue 119: Proposal: add optional_host_permissions

  • [simeon] Not formed a final decision, but amenable to the idea.
  • [tomislav] Not decided to commit yet either, but the idea makes sense. Not necessary to support a new key, could re-use optional_permissions.
  • [simeon] Intentionally moved host_permissions outside of optional_permissions, would like to have a separate optional_host_permissions.
  • [carlos] Please let optional_host_permissions take precedence over host_permissions; browsers that support it can treat it as optional; other browsers can use host_permissions instead.
  • [timothy] In favor of supporting optional_host_permissions in Safari.

PR 122: Manifest keys cleanup

  • Part of issue 121 (Determine what manifest properties every vendor agrees on).
  • [simeon] Concerned about losing the existing content, but it's in the revision history if needed.
  • [tomislav] will review after meeting.
  • [timothy] externally_connectable is supported in Safari, so that should be kept since we have at least 2 implementations. We also support devtools_page.
  • [tomislav] Yes, we previously agreed that the criteria is to have at least two implementations.

Issue 134: Proposal: Limited Event Pages for MV3

  • [tomislav] We at Mozilla believe that support for event pages is a good way to help developers to transition from a persistent background page to a context that may not stay alive forever. We will start prototyping this in the coming weeks.
  • [timothy] We (Safari) support this proposal. We already require non-persistent background pages in Safari on mobile, and allowing event pages in MV3 is less friction for developers.
  • [simeon] At the Chrome side are currently not supporting this proposal. In 4 weeks from now, Devlin will join to explain and discuss the trade-offs.
  • [krysztof] Would like a written statement from Google that explains the decisions.
    • [carlos] Issues could be created
    • [rob] These meeting notes are the written record of these meetings.
  • [carlos] The use of “persistent” in the manifest prevents extensions from loading in Safari on iOS - https://developer.apple.com/forums/thread/691542
    • [timothy] We currently require the persistent flag to be set to false, to ensure that extensions are designed for non-persistency. We are supportive of one manifest that works in all browsers, and as mentioned in previous meetings a warning rather than an error may be preferred.

Issue 12: runtime.getFrameId proposal()

  • [tomislav] #12 (comment)
  • [simeon] Would like to prototype, but we also need to consult other groups (e.g. security review), and this is not a fast process.
  • [tomislav] Believes that Devlin's comment concerns implementation details, rather than design issues. Will start prototyping.
  • [rob] Raised the issue of embed not having a contentWindow getter at whatwg/html#7140. Their consensus is to not add a new embed.contentWindow getter because embed is a legacy element. The options available are to either (1) let getFrameId take <embed> elements as a parameter, or (2) add an extension-only embed.contentWindow getter.
    • [timothy] Supportive of (1). An embed.contentWindow getter is not preferred for implementation reasons.
    • [rob] Chrome's implementation for shadow root getters was added to a chrome.dom namespace instead of an element getter like Firefox, so although Simeon cannot speak to the implementation right now, it's probably safe to assume that Chrome would prefer (1) over (2).

Unique frame ids, frame messaging and getting frameId from window objects. #90, #12, #77, #91 (Carlos)

  • [carlos] #77, send messages directly to frames. #91, addresses the issue of executeScript/insertCSS
  • [simeon] Concern with 91, frameid does not uniquely identify a frame
  • [tomislav] Too many assumptions that tabId is 0 or -1. New scripting API's executeScript taking an object introduces the possibility of more flexibility in specifying execution context. Might be able to figure out an alternate way to target. Hesitant to promise window ID could be used as they're separate kinds of IDs. There are ways to uniquely identify a popup.

Issue 128: Proposal: agree on a unified sidebar_action API for mv3

  • [carlos] Reached out to Opera. Got approval for participation from a member of their team.
  • [tomislav] Difference between Firefox and Opera is primarily the shape of the manifest definition. Should discuss more in the issue and possibly offline. Feel free to put them in contact with me

Issue 131: Documentation: get a complete list of all locales supported in each browser

  • [carlos] asking browser vendors to follow up with information and participate in this issue
  • [timothy] Safari is not represented in the spreadsheet & relies on underlying OS. You would be interested in specifying a specific fallback order, correct?
  • [carlos] Yes, can be followed up in a separate issue.
  • [mukul] Are you looking at having a consistent fallback scheme across all browsers and OSs?
  • [carlos] Yes, want a well-defined path.
  • [tomislav] I expect this behavior to be the same as the resolution process for pages. May be best to bring in experts from that realm
  • [carlos] Practical request is to have a list for developers on what language codes are/are not supported

Issue 125: Inconsistency: scripting.registerContentScripts and contentScripts.register

  • [rob] Recognizes incompatibility. Firefox will move to scripting API, which is currently being implemented. Found minor issues with Chrome's implementation, will reach out separately to Google, and if any specification-worthy issue comes up I'll file an issue here.

Issue 132: Proposal: allow extensions to register web share targets

  • [carlos] Issue raised during Chrome Dev Summit to have extensions be a share target
  • [simeon] did a small amount of investigation, looks like it's only defined in the PWA manifest. Assume we should adopt a similar implementation and leverage existing web platform capabilities
  • [timothy] Initial thought looking at the PWA world is that this would likely be defined very differently in the extension world. Similar end user UX, but likely little overlap with PWA
  • [tomislav] Agree with Timothy's assessment.
  • [timothy] If someone wants to come up with a proposal, that would be awesome.

(ran out of time for the other topics)

The next meeting will be on Thursday, December 9th, 8 AM PST (4 PM UTC). Note that we are skipping the originally scheduled meeting on November 25th.