Skip to content

Latest commit

 

History

History
158 lines (124 loc) · 12.5 KB

2024-01-04-wecg.md

File metadata and controls

158 lines (124 loc) · 12.5 KB
Raw

WECG Meetings 2024, Public Notes, Jan 4

  • Chair: Simeon Vincent
  • Scribes: Rob Wu

Time: 8 AM PST = https://everytimezone.com/?t=6595f500,3c0 Call-in details: WebExtensions CG, 4th January 2024 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
  • Other new issues
    • Issue 505: Proposal: Retrieving, deleting storage items using a filter
    • Issue 506: Firefox' webRequest.FilterResponse & more for all browsers
    • Issue 507: Support $schema in manifest.json
    • Issue 510: Proposal: Increase maximum item size in Storage sync quotas
    • Issue 511: Inconsistency: storage onChanged
    • Issue 513: Proposal: RunAt.before_document_start
  • Open discussion queue (add yourself at the bottom)
    • [tomislav] Update and feedback request on the runtime.onPerformanceWarning event being added to Firefox by Dave Vandyke (DuckDuckGo) in: #456 (comment)
    • (Moved remaining items to the next meeting).
  • Check-in on ongoing issues
    • (moved to next meeting)

Attendees (sign yourself in)

  1. Simeon Vincent (unaffiliated)
  2. Rob Wu (Mozilla)
  3. Oliver Dunk (Google)
  4. Giorgio Maone (NoScript, Tor Browser)
  5. Rémi Pujo (Dashlane)
  6. Timothy Hatcher (Apple)
  7. Kiara Rose (Apple)
  8. David Johnson (Apple)
  9. Carlos Jeurissen (Jeurissen Apps)
  10. Steven McLintock (1Password)
  11. Patrick Kettner (Google)
  12. Tomislav Jovanovic (Mozilla)
  13. Mukul Purohit (Microsoft)
  14. Tim Heflin (Keeper)

Meeting notes

Issue 500: Inconsistency in default warning Content Security Policy Script

  • [rob] This is a warning, not an error. Child-src defines the CSP restrictions for frame-src and worker-src; the author specified child-src while frame-src should have been used instead.
  • [carlos] Asked the author if there is anything in addition to discuss in the group. There does not seem to be so we can probably close the issue.

Issue 501: Proposal: Toggleable event listeners

  • [anton] Basically the exact use case has reasonable work-arounds. Not sure why the requested feature is needed.
  • [rob] Tried porting an extension to MV3 and encountered this issue. Currently an event listener has to be registered at top level to wake an event page or SW. If the developer unregisters then registers a listener again before shutdown, Chrome retains the subscription but Firefox does not: https://bugzilla.mozilla.org/show_bug.cgi?id=1869125
  • [timothy] Safari behaves more like Chrome. I'm agreeing with Anton that a special API is not needed if it is already possible through the existing API.
  • [simeon] Possible to work around, but feels like the platform is working against you.
  • [oliver] Agree we should address, but this specific proposal feels like it introduces too much complexity.
  • [rob] This is just one optional activity. Other parts of the platform don't have declarative solutions for this kind of thing. Firefox will need to adapt to support this pattern.
  • [rob] In Chrome, when a listener is registered async (not at the top level), the background service worker wakes up when the event is triggered (but the event is dropped because the top-level listener does not exist). What is Safari's behavior?
  • [timothy] We wait a short while starting the event page/ to record listeners, in order to know which events should wake up the event page/service worker at the next browser startup.
  • [kiara] That's correct.
  • [rob] Let's confirm the desired behavior and revisit this issue later, because we have many other topics on the agenda.

Issue 502: Auth Header in Fetch Redirects (Chrome v119+)

  • [simeon] This is a Chrome specific issue, but it raises a broader question about how extensions should handle redirects that have authentication information.
  • [oliver] If you make a request with an “auth” header, a cross-origin redirect results in the auth header being stripped. Firefox/Safari had already implemented this, I'm curious why extensions there haven't been impacted there.
  • [anton] The extension in question is Chrome-specific.
  • [rob] Issue contains a link to a Firefox extension. I haven't verified Firefox's behavior here. Thoughts on desired behavior?
  • [oliver] Issue requests exception for redirect to localhost, but that sounds like something that should be discussed at the web level.
  • [simeon] I definitely want to support this use case. Initial concern is with passing credentials to another origin. Would want to gate this behind host permissions. Beyond that, not sure how to handle this.
  • [rob] Could consider API additions to explicitly cover redirects like this.

Issue 503: Ability to detect browser variant / fork

  • [carlos] Some browsers do not expose themselves. But for extensions the exact browser may be important to account for UI changes.
  • [rob] Discussion in the issue called out forks. Is the expectation that other vendors would add data to extension APIs?
  • [carlos] Maybe.
  • [simeon] userAgentData brands has this info (not supported by Firefox), but several Chromium forks do not list themselves here.
  • [carlos] These vendors may be more willing to add the detailed brand in the extension API despite unwillingness to expose the info in the web API.
  • [rob] We could define “brands” in runtime.getBrowserInfo(), but it only offers value if these other browsers expose the information.
  • [simeon] I'll take the action item to reach out to other browser vendors to request a comment on this issue.

Issue 505: Proposal: Retrieving, deleting storage items using a filter

  • [simeon] In short, pattern matching to retrieve or delete data in storage. I've also wanted this kind of thing.
  • [rob] In favor of the capability in abstract, but concerned that this API design introduces too much magic.
  • [anton] What about tags rather than wildcards? Tags meaning an array of strings associated with a field.
  • [rob] Adding the ability to retrieve all keys would allow developers to implement their own solutions. The API already supports bulk deletion and retrieval. This would be much simpler and allow extensions to look up keys without all values.
  • [timothy] I am in favor of Rob's approach.
  • [oliver] I like that too.
  • [simeon] Con: that approach is that it takes two roundtrips. Pro: enables the ecosystem and allows us to pave cow paths in the future.
  • [tomislav] Rob's proposal leans much in the API design that we already have.
  • [oliver] For performance-sensitive data the storage API should probably not be used anyway.
  • [rob] I'll raise my counter-proposal in the issue.

Issue 506: Firefox' webRequest.FilterResponse & more for all browsers

  • [rob] The request here is basically implementing filterResponseData in Chrome/Firefox.
  • [oliver] This definitely requires the blocking option.
  • [rob] Does require it, but that's to ensure that the filter is registered in time. The feature request is the ability for an extension to put itself between the network response stream and the browser's processing of it.
  • [oliver] I'm not sure if we would be willing to support that, because it would have the performance considerations that were relevant to dropping support for webRequestBlocking.
  • [timothy] Yes, what Oliver said.
  • [rob] With that, we could close the issue, because Chrome and Safari's positions are clear here.

Issue 507: Support $schema in manifest.json

  • [patrick] The main request is to stop treating $schema as a hard error in Chrome. Other browsers don't fail here.
  • [oliver] I think that we are supportive on Chrome's end - we are moving towards treating unrecognized/unsupported keys as non-fatal warnings instead of errors.
  • [carlos] Currently you can load an extension just fine in Chrome with the $schema property. The issue seems to be present in the Chrome Web Store only.

Issue 510: Proposal: Increase maximum item size in Storage sync quotas

  • [timothy] We don't currently support sync in Safari, but our preference is to keep things small.
  • [rob] Devs shouldn't store too much data here. Breaking up the data into smaller pieces is a hack and against the spirit of the API limitations.
  • [simeon] Sounds like this might be a documentation issue. We should clarify what the intent of this API is and that developers should use another system to sync user data.
  • [rob] That having said, the current individual limit is 8k; do we want to keep it there or are we willing to raise it?
  • [oliver] I'll check with the team.

Issue 511: Inconsistency: storage onChanged

  • [tomislav] FYI on Firefox side we may not even be consistent across our namespaces. In some cases onChanged is fired when set() is called even without changes. I would not be opposed to changing it.
  • [rob] For clarity, this issue is related to set() handling. Are all values propagated?
  • [kiara] We only dispatch an update for changed values.
  • [] How about sync, as mentioned in the issue?
  • [rob] I expect that if sync updates the value, the extension should be notified.
  • [rob] Can we align on desired behavior? Does firing only on changed values make sense?
  • [timothy] Yes.
  • [oliver] Yes.
  • [rob] What about sync?
  • [oliver] Would be hesitant to expose all data on sync if we're not already.
  • [simeon] Why would we expose more data for sync than local changes?
  • [tomislav] The extension has full context on local changes, but doesn't for remote changes. There's additional signal in getting the full set of values set.
  • [oliver] Let's take this offline.

Issue 513: Proposal: RunAt.before_document_start

  • [anton] Browsers currently support injection at 3 phases. All of them happen no earlier than the specified phase, but do not guarantee execution at a specific time. There's no way to make sure that scripts run in time to do something (e.g. proxy calls made by the page itself).
  • [rob] What you're requesting is what document_start is supposed to do. There may be some cases where browsers may execute other code first. Before_document_start would have the same set of
  • [simeon] To my knowledge, document_start does as documented in Chrome, except when a same-origin iframe is created because the host page has access to sub-page.
  • [giorgio] I'm all in favor of fixing document_start. E.g. in Firefox at file:-URLs document_start may run too late.
  • [anton] Fixing document_start would be preferable.
  • [timothy] That's what we're favoring too.
  • [rob] I'll close the issue - if there are issues with document_start, please file bugs for these at the issue trackers of the browsers.

Issue 456: Proposal: Provide reporting event for browser's slow extension warnings

  • [tomislav] Update and request for feedback on the runtime.onWarning API being added to Firefox by Dave Vandyke in #456 (comment) . In response to feedback the event was renamed to runtime.onPerformanceWarning

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