Skip to content

Latest commit

 

History

History
155 lines (123 loc) · 13.3 KB

2022-12-08-wecg.md

File metadata and controls

155 lines (123 loc) · 13.3 KB

WECG Meetings 2022, Public Notes, Dec 8

  • Chair: Timothy Hatcher
  • Scribes: Rob Wu

Time: 8 AM PST = https://everytimezone.com/?t=63912900,3c0 Call-in details: WebExtensions CG, 8th November 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
    • Issue 311: Ability to unload the background script from SW code [regression from MV2]
    • Issue 312: [contextMenus] create or update contextMenus in a single call
    • Issue 313: registerContentScripts misleadingly names page scripts as content scripts
    • Issue 315: Proposal: Complete privileged page process even after closing
    • Issue 317: registerProtocolHandler (protocol_handlers) in extensions
    • Issue 318: Adjust the maximum number of static rulesets and enabled rulesets
    • Issue 319: Increase the maximum number of dynamic rules to 30,000
  • Other new issues
    • PR 331: Add User Scripts API proposal
    • Issue 330: Proposal: add browser.search.getSuggestions method
  • Open discussion queue (add yourself at the bottom)
    • (ran out of time, remaining issues moved to next meeting)
  • Check-in on ongoing issues
    • None

Attendees (sign yourself in)

  1. Rob Wu (Mozilla)
  2. David Johnson (Apple)
  3. Kiara Rose (Apple)
  4. Maxim Topciu (AdGuard)
  5. Dmitriy Seregin (AdGuard)
  6. Oliver Dunk (1Password)
  7. Timothy Hatcher (Apple)
  8. Nikita Vasilyev (independent)
  9. Tomislav Jovanovic (Mozilla)
  10. Carlos Jeurissen (Jeurissen Apps)
  11. Giorgio Maone (NoScript, Tor)
  12. Benjamin Bruneau (1Password)
  13. Tim Heflin (Keeper)
  14. Jason Waterman (Mozilla)
  15. Frederic Rivain (Dashlane)
  16. Mukul Purohit (Microsoft)
  17. Tyler Carson (Keeper)
  18. Andrey Meshkov (AdGuard)
  19. Luke Selker (Dashlane)
  20. Emilia Paz (Google)

Meeting notes

Issue 311: Ability to unload the background script from SW code [regression from MV2]

  • [simeon] On the Chrome side we've talked about this numerous times - we'd like to give extensions more control over its lifetime.
  • [oliver] 1Password use case: close context to erase passwords
  • [timothy] Supportive from Safari's side. I believe there was previously a .terminate() method
  • [simeon] On our side we haven't followed up on the platform side to see if it may be valuable to the web platform instead of just extensions. I should do that.
  • [tomislav] I would prefer that if possible. Sounds like we need further investigation in general.
  • [rob] What are the next steps here? Are you going to reach out to the platform folks Simeon?
  • [simeon] Yes. I think that it may be better to open an issue in the SW repo.

Issue 312: [contextMenus] create or update contextMenus in a single call

  • [simeon] Note that there is no .getAll() method so extensions cannot retrieve the existing menus.
  • [simeon] Not sure how to approach this kind of ergonomics issue. At the moment we're currently focusing on is gaps, e.g. between MV2 and MV3, and not what's already possible. Would love to be able to focus on convenience.
  • [tomislav] This may be potentially useful when a SW/event page is not sure about whether a menu exists already.
  • [rob] Extensions can already call create and catch the promise rejection if needed. While it may be useful, it's not a strictly necessary addition to the API. Therefore I'm at most neutral towards supporting the functionality (Firefox's perspective).
  • [simeon] Thinking to the history of libraries like jQuery and Sizzle, where the community found a better pattern than the platform exposed, the platform adopted the pattern (such as with querySelectorAll), and the platform was better for it.
  • [timothy] Neutral too.
  • [simeon] Neutral.

Issue 313: registerContentScripts misleadingly names page scripts as content scripts

  • [timothy] Not sure if I fully disagree, or if it is even a meaningful thing to bikeshed on.
  • [simeon] In my tech writing tasks, I observe the usefulness of distinguishing between the scripts in the different worlds, and also css injection in content_scripts. I also agree that bikeshedding here does not add much here.
  • [tomislav] I also, we have Emilia's proposal, which uses a separate namespace to cover a similar use case.
  • [rob] Sounds like we're all inclined to close this issue.

Issue 315: Proposal: Complete privileged page process even after closing

  • [oliver] Comment on issue 315 with use case from 1Password.
  • [timothy] If extensions control whether the popup closes, then it can await first and then close.
  • [tomislav] Such tasks should then be delegated to the background.
  • [rob] Spawning the background is not free. If we can offer a way to hide the UI briefly to handle common tasks, that might make things easier without having to rely on the background. The potential problem is that developers may become over-reliant on this and run into issues where they're taking too long. I'm not opposed, but the capability needs to be managed carefully.
  • [timothy] I would be supportive of keeping it around for up to 5, maybe 10 seconds, but not longer.
  • [simeon] Currently neutral, also concerned about state lingering if the user closes and re-opens the popup.
  • [rob] It's like switching away from a tab and then returning to it.
  • [tomislav] Introduces complications, such as whether the browser should render a new page or the existing page when the popup is re-opened.

(lifetime discussion forked from previous discussion)

  • [simeon] Addition to known issues page: comment indicating that we're looking at the SW lifetime and considering an event-based approach rather than a fixed time. There is a lack of a event.waitUntil method to extend lifetimes.
  • [rob] In Firefox we're already taking an event-based approach. As long as there's useful activity, we'll keep the background alive.
  • [timothy] Also supportive of exploring waitUntil in extensions.

Issue 317: registerProtocolHandler (protocol_handlers) in extensions

  • [timothy] [Whether we have a custom thing or use the web's method.] Supportive of using a declarative approach similar to Firefox.
  • [tomislav] Simeon, can you follow up on whether Chrome is open to the declarative approach?
  • [simeon] Yes.

Issue 318: Adjust the maximum number of static rulesets and enabled rulesets

  • [timothy] A lot of ad blockers run into the limited number of rules. Safari already supports a higher number of rules. I'd be supportive of increasing this number.
  • [andrey] Two requests here: max number of static rulesets (50 to 100+) and number of enabled rulesets (10 to 20+).
  • [simeon] Saw this, but haven't yet had time to dig into the numbers or discuss with the team. I will follow up on this in the next week or two.
  • [rob] I'm in favor of increasing the limits. Note that even if we increase these limits, I expect ad blockers in Firefox to continue using blocking webRequest.

Issue 319: Increase the maximum number of dynamic rules to 30,000

  • [timothy] 5k to 30k. Also supportive in this in Safari. Safari's implementation combines everything, so from our implementation perspective the exact limits do not matter.
  • [simeon] Same as previous issue; saw it, but haven't had time to dig into it.
  • [rob] In favor of the larger limit. Want to revisit the design that ties the quotas for session and dynamic rules together. One is only in-memory, the other is persisted. Combining them consumes a shared pool that may not be necessary, and even complicates the implementation due to the need to synchronize the management of session & dynamic rulesets.
  • [timothy] I would be in favor of separating the limits. It's confusing that they're tied together. You may not realize you're encountering limits because they're conceptually separate.
  • [simeon] In general, it's safe to say that continuing Chrome's path is the easiest. That said, if other browsers are considering it, then that makes us necessarily revisit. Main concern offhand is that if we split the pool and have a lower max in either specific group, we may run into issues.
  • [rob] This topic started with increasing the limit from 5k to 30k. If we make the limits of session and dynamic rules independent with a minimum of 5k, then there is no risk of backwards-incompatible issues.

PR 331: Add User Scripts API proposal

  • [emilia] Basically the PR takes a couple of things from the discussion in the issue. I suggest to drive the conversation there to make it easier to resolve discussions inline.
  • [rob] This uses a different namespace even though it has very similar capabilities to the scripting API. Do we want to separate these capabilities?
  • [emilia] First proposal had user scripts under the scripting API. However, having a separate namespace provides a clear separation between user and content scripts that can lead to stronger enforcement of remotely hosted code abuse, which is the reason we need this API in the first place.
  • [rob] Noticed that the PR is designed for user scripts, but there are some smaller pieces that are not user script specific. Re-using the generic API namespace can be of use beyond just user script managers.
  • [emilia] The idea of having it be separate is directly tied to remotely hosted code.
  • [simeon] The new namespace clearly communicates that this feature is intended to primarily be used for user scrips.
  • [rob] We can continue that discussion in the PR. Still doesn't allow user script managers to directly transition from one API in MV2 to another in MV3.
    • [rob] In Chrome, user script managers inject an inline script. The way a user script manager would use this API is to set a relaxed CSP and continue following the practice they do today: inject and execute an inline script. But this sidesteps the new capabilities. Basically lots of work for a new API that isn't going to be used.
  • [simeon] Want to quickly respond to the the "sidestepping" issue. That approach may allow user script managers to become MV3 compatible, then we continue working with user script managers to encourage adoption of the API's capabilities and patterns.
  • [tomislav] User scripts have more flexibility for content matching. …
  • [rob] With regard to easing the transition, consider foregoing the introduction of a new incomplete userScripts API, and (re-)introduce content_security_policy.isolated_worlds and via review only allow user script managers to introduce script-src ‘unsafe-inline'.

Issue 330: Proposal: add browser.search.getSuggestions method

  • [nikita] There is already browser.search.search. Would be nice to add an API to retrieve search suggestions. Then we don't have to be constrained by API limits of an unofficial http API.
  • [simeon] This opensearch is also supported by other engines.
  • [timothy] Does the extension know what the default is?
  • [nikita] Omnibox requires a keyword. What I'm requesting is the ability to add results wherever the user searches.
  • [oliver] When you type something in the omnibox, you currently get results beyond search results, including suggestions from bookmarks/history. The requested API with the intended use case of simulating the omnibox will not result in what you are intending.
  • [timothy] If there is anything that can be interpreted as sensitive data, then we would
  • [nikita]
  • [rob] Your use case is about trying to replicate results from the omnibox, right? You will get search suggestions, but not the other content that the browser would provide (bookmarks, history, etc.)
  • [oliver] Right.
  • [nikita] For clarity, I'm specifically asking for search suggestions. Other things would not be applicable to this API.
  • [tomislav] This is basically something you can do already, but you'd have to ask the user to specify their search provider.
  • [rob] We're past the end of the meeting, let's continue async in the issue.

The next meeting will be on Thursday, January 5th, 8 AM PST (4 PM UTC).