Skip to content

Latest commit

 

History

History
123 lines (101 loc) · 10.5 KB

2023-08-03-wecg.md

File metadata and controls

123 lines (101 loc) · 10.5 KB
Raw

WECG Meetings 2023, Public Notes, Aug 3

  • Chair: Timothy Hatcher
  • Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=64caee00,384 Call-in details: WebExtensions CG, 3rd August 2023 Zoom issues? Ping @zombie (Tomislav Jovanovic) in chat

Agenda: discussion in #432, github issues

The meeting will start at 3 minutes after the hour.

  • Carry-over from previous meetings
    • None
  • Other new issues
    • Issue 431: Proposal: Default to Active Tab in scripting.executeScript()
    • Issue 433: Inconsistency: Alarms API time slipping
  • Open discussion queue (add yourself at the bottom)
    • None
  • Check-in on ongoing issues
    • Issue 362: Proposal: Declarative Cosmetic Rules
    • Issue 403: Proposal: Ability to insert CSS from content script context
    • Issue 394: [DNR] Add support for wildcards in initiatorDomains and excludedInitiatorDomains fields

Attendees (sign yourself in)

  1. Jason Waterman (Mozilla)
  2. Simeon Vincent (Unaffiliated)
  3. Oliver Dunk (Google)
  4. Rob Wu (Mozilla)
  5. Dmitriy Seregin (AdGuard)
  6. Timothy Hatcher (Apple)
  7. Benjamin Bruneau (1Password)
  8. Tim Heflin (Keeper)
  9. Carlos Jeurissen (Jeurissen Apps)
  10. Mukul Purohit (Microsoft)
  11. Andrey Meshkov (AdGuard)
  12. Maxim Topciu (AdGuard)
  13. Matt Gibson (Bitwarden)

Meeting notes

Issue 431: Proposal: Default to Active Tab in scripting.executeScript()

  • [simeon] In MV2, tabs.executeScript defaulted to the active tab; in MV3 scripting.executeScript explicitly requires the target option to be specified.
  • [oliver] I seem to remember similar changes in other APIs, to make the target of script execution explicit.
  • [timothy] I see the reasoning there; at the same time it makes the API usage cumbersome for common uses. Perhaps we can achieve the explicitness by supporting a new property instead of tabId?
  • [simeon] This brings up a broader question around API design philosophy. The change to require a tab ID feels in like with the Extensible Web Manifesto, where lower level and more specific capabilities are provided and the expectation is that the community will produce libraries that provide nicer to use APIs. In our case, though, we don't have a demonstrable history of extension-specific libs being widely adopted. A question I still don't have resolved in my own head is “How batteries-included should extension APIs be?”
  • [timothy] I'm of the mindset of that we should build the APIs the way they are intended to be used.
  • [oliver] If we were to add a property such as “useCurrentTab”, do we expect people to understand the risks?
  • [simeon] We see it in action.onClicked, where people use tabs.query even though the tab is provided in the callback.
  • [oliver] I think that may be further motivation to make this explicit, so developers eventually figure out the callback has what they need. As a side note - some APIs already have a current window concept which tries to use the executing context and may be applicable here.
  • [rob] I understand the request behind this feature, but the case of action.onClicked isn't very convincing for me. The risk with introducing a “currentTab” property is that developers will rely on this behavior and find the extension behaves unexpectedly in use. For example, when SW takes a moment to start and the current tab changes between invocation and injection.
  • [timothy] Fundamentally we run into this in function-driven namespaces rather than browser-scoped APIs. E.g. an API call on a document/window object has an obvious target, instead of the tabIds in the extension APIs.
  • [rob] In the case of the window object, a cross-origin navigation automatically results in APIs breaking. In extension APIs, a navigation does not automatically break API calls, resulting in execution in unexpected (cross-origin) contexts.
  • [rob] Resolution?
  • [timothy] I added supportive from Safari; I'd still be supportive of an option to run in the current tab.
  • [oliver] I'll follow up and get back later. Currently leaning towards not needing it.
  • [rob] I also lean towards not needing it, but can be convinced otherwise. Neutral.
  • [simeon] Also leaning towards a convenience, e.g. “currentDocument”, tied to documentId.
  • [timothy] That name also assumes a main frame.

Issue 433: Inconsistency: Alarms API time slipping

  • [anton] In web platform, setTimeout/setInterval only count when the document is active. When the computer goes to sleep or frame navigates away, the timer is suspended and does not advance. But in the alarms API, each alarm has a scheduledTime which gives an impression of timer being scheduled for an exact timestamp and not a relative offset. When computer is suspended, it does not advance the timer so the alarm is delayed by the exact time the computer was asleep, with scheduledTime set to the original timestamp. Furthermore, only the first alarm is delayed since all alarms share a single timer which gets recalculated and “fixed” every time an alarm fires.
  • [simeon] In Chrome, I think that the behavior depends on whether delayInMinutes or a timestamp is given.
  • [anton] I believe that all timers are converted to timestamps.
  • [simeon] Interesting. When I investigated before, there was a report where timers fired surprisingly unexpectedly, which was caused by the options used.
  • [anton] This may be a different issue: all extensions under the same profile share a single timer, so debugging extension A with different arguments developer may have extension B randomly set off extension A timers.
  • [simeon] Some of what you said sounds like a definite bug; others sound like something where we should agree on the desired behavior.
  • [rob] Where is the “inconsistency”?
  • [anton] I believe that Safari implements this fine, but Chrome and Firefox exhibit this time slipping.
  • [timothy] Safari computes everything based on wall clock.
  • [rob] How would the use case of triggering an alarm at a fixed time be affected by what you're describing?
  • [timothy] A past timer fired upon wakeup, but a future alarm will fire at the scheduled time.
  • [timothy] What is the desired behavior here?
  • [anton] For more context; Chrome used to use separate alarms, but probably optimized to use one alarm. Safari might want to move to only one alarm. (...)
  • [oliver] If a fixed timestamp is given and an alarm does not fire at that timestamp, it would be a definite bug.
  • [rob] Could you update the issue with clear test cases (minimal extension + steps to reproduce)?
  • [anton] I will do.
  • [simeon] Do you know whether Tomislav has made progress on test suites? That's where we could add tests for things like this.
  • [rob] I'm not aware of specific progress in that area.

Issue 362: Proposal: Declarative Cosmetic Rules

  • [andrey] What do we need to do to move this forward?
  • [timothy] I'm interested in pursuing this. This is also related to the next issue in the list (issue 403). I'd like to see this getting done. In Safari the underlying engine can easily support this.
  • [andrey] The main concerning feedback here was on the scripting. Perhaps we can split this issue in two parts. And design the issue so that it can be expanded beyond just the CSS selector use case.
  • [timothy] I think that it's best. Starting with CSS seems like a good approach.
  • [oliver] I'm generally supportive of this.
  • [timothy] I'd be fine with putting this in DNR, but it would bloat the namespace. It takes a similar form to conditions/actions.
  • [rob] DNR operates on the network, but the cosmetic part is in the web content. DNR is not a natural choice for an API operating on content.
  • [timothy] Content blocking in Safari happens in different processes (content and network process).
  • [andrey] Should we design with browser internals in mind or easier to understand for users (extension devs)? In the latter case adding to DNR would be an obvious choice.
  • [rob] There are combinations of conditions/triggers that are not meaningful when DNR rules/actions and CSS selectors/cosmetic rules are combined.
  • [timothy] An advantage to re-using DNR is that we get features like dynamic/session rules, etc., which would result in duplication across APIs.
  • [rob] That's a valid concern.
  • [andrey] I'll work on specifying the rules and actions, and split off scriptlets.

Issue 403: Proposal: Ability to insert CSS from content script context

  • [oliver] I added an update to express interest in adding this in the dom namespace.
  • [timothy] With API duplication in mind, why do we want this API?
  • [oliver] Not specifying target or files.
  • [rob] Does that mean that Chrome is supportive?
  • [oliver] Yes.
  • [rob] That means that we are all supportive, and that we can implement this once there is an agreement between browser vendors.

Issue 394: [DNR] Add support for wildcards in initiatorDomains and excludedInitiatorDomains fields

  • [andrey] In previous discussions, there was reluctance towards implementing wildcards in initiatorDomains. Could we perhaps extend conditions with a version of initiatorDomains that supports regexs, like regexFilter?
  • [timothy] I'd be supportive of a regex filter option.
  • [oliver] I started to warm up to wildcards after reading more into this. Regexps could be a way to support this, but also have a lot of other issues.
  • [andrey] Instead of a regex we could also consider an initiatorUrlFilter that wouldn't have the issues with regexps.
  • [timothy] urlFilter would be the simplest syntax that's supported universally.
  • [rob] I'm concerned with using regexps, and urlFilter sounds a bit better.
  • [timothy] Please clean up the issue so that we can weigh the options.

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