2024-07-18-wecg.md

WECG Meetings 2024, Public Notes, Jul 18

• Chair: Timothy Hatcher
• Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=66985b00,384 Call-in details: WebExtensions CG, 18th July 2024 Zoom issues? Ping @zombie (Tomislav Jovanovic) in chat

Agenda: discussion in #655, github issues

The meeting will start at 3 minutes after the hour.

See issue 531 for an explanation of this agenda format.

• Announcements (2 minutes)
• Triage (15 minutes)
  • Issue 653: API for extensions to exclusion/deny list their content scripts
  • Issue 656: Undetectable widgets, to avoid conflicts (modals, tooltips, notifications, ...)
  • Issue 657: [MV3] Clarify browser inconsistency for temporary host permissions granted on extension click
  • Issue 658: Proposal: API to allow incognito access
• Timely issues (10 minutes)
  • Issue 659: WECG at TPAC 2024
• Check-in on existing issues (20 minutes)
  • PR 641: Proposal: Per-extension language preferences

Attendees (sign yourself in)

1. Rob Wu (Mozilla)
2. Giorgio Maone (NoScript, Tor)
3. Timothy Hatcher (Apple)
4. Simeon Vincent (Mozilla)
5. David Johnson (Apple)
6. Tomslav Jovanovic (Mozilla)
7. Rémi Pujo (Dashlane)
8. Carlos Jeurissen (Jeurissen Apps)
9. Alisa Tikhova (eyeo)
10. Kiara Rose (Apple)
11. Mukul Purohit (Microsoft)
12. Solomon Kinard (Google)
13. Jackie Han (no affiliation)

Meeting notes

Issue 653: API for extensions to exclusion/deny list their content scripts

• [timothy] Confused - there is already exclude_matches?
• [rob] exclude_matches set in the manifest.json file cannot be modified later. The request here is to make the exclusion list dynamic.
• [rob] Similar capability was requested before for userScripts - #607.
• [tomislav] There is no way to undo what a content script has already done to a page. That part of the request is not achievable.
• [timothy] We have the same limitation.
• [rob] I'm supportive of this capability. The feature itself could also be implemented with something like the scripting.globalParams proposal from before.
• [timothy] Not running scripts when it can has benefits too.
• [rob] A way to implement this is to expand the scripting.updateContentScripts API to support modification of statically declared scripts. Complexity with this is persisting changes across restarts and updates.
• [timothy] Even if we don't persist, we could fall back to manifest declaration. Extension can re-declare updated excludes on startup.
• [rob] Would be in favor of adding static exclude matches to the manifest declaration. More hesitant with adding more matches.
• [timothy] Would be in favor of only allowing extensions to restrict themselves, not expand host permissions for a static declaration at runtime.

Issue 656: Undetectable widgets, to avoid conflicts (modals, tooltips, notifications, ...)

• [timothy] The feature request here is hard to do, i.e. DOM modifications undetectable to the page. It'd be more feasible to look into the direction of a separate document that draws over the page, or a sidebar that can float / roam freely.
• [tomislav] The other issue mentions the showModal API of <dialog> which solves the definition of “render over everything else”.
• [timothy] The <dialog> element has been discussed before.
• [rob] Even with the dialog element, there is still the question of which content should be rendered on top when the web page or even another extension opens the dialog after an extension has already opened the dialog before.
• [timothy] And even if invisible from the DOM, the content is visually indistinguishable from the web content.
• [simeon] When discussed in the past, another consideration is that rendering one page is already hard enough. In order for extensions to render content over the page, a special frame could be used to render the item (iframe invisible to the web page), and then these could be rendered on top of the document.
• [rob] To clarify, you're describing a way to implement this within the primitives that already exist on the web platform + browser implementations, right?
• [simeon] Yes.
• [timothy] We do something similar for devtools. If we can limit to one or two documents we don't need to worry as much about ordering.
• [tomislav] We also do something similar for devtools.
• [rob] In previous discussions, the action (browserAction) panel was preferred as a way to display notifications, etc. Chrome has recently removed the user interaction requirement for action.openPopup to make it more attractive as a primitive. I recognize that there may still be some use cases for which rendering on top of the web content would be nice.
• [simeon] Would also be nice to be able to render content without requiring host permissions.
• [tomislav] Should we close this as a duplicate of the previous issue (Issue 235: Discuss allowing extensions to reliably draw over pages).
• [timothy] Agreed.

Issue 657: [MV3] Clarify browser inconsistency for temporary host permissions granted on extension click

• [timothy] This is pretty much specific to Chrome's run when clicked option. I don't know about Firefox, but we don't have this in Safari.
• [simeon] In Chrome it's called Click-to-script.
• [tomislav] If you click, the MV3's content scripts are automatically run if you would have the content script. We'd like to implement something closer to Chrome's click-to-script; when we click on the extension button, we run content scripts as if the extension had permissions for them. It's temporary, for that page only (which is part of the issue). The other part of the issue is that some scripts need to run early; Chrome offers a button to reload.
• [timothy] Does the content script still run after a navigation?
• [rob] activeTab lasts until the next navigation.
• [timothy] We grant host access but do not run content scripts.
• [rob] This behavior is MV3 only in Firefox.
• [tomislav] In MV2 content scripts implied host origins from match patterns granted.
• [rob] The discussion so far are browser-specific details. We have previous feature requests about APIs to explicitly declare the desired behavior.
  • Issue 600: Request immediate injection of manifest script registered with document_idle
  • Issue 617: manifest key to enable automatic injection of content scripts after installation/update
• [rob] So what are we going to do with this issue? Are we going to write async about the behaviors of the browsers and see whether we should align somewhere?
• [tomislav] Yes.

Issue 658: Proposal: API to allow incognito access

• [timothy] There is no API to request access to private browsing. I'm inclined to keep it that way.
• [simeon] To clarify, are you opposed to a way to show the UI, or a modal?
• [timothy] Current UI is switching to a different app on iOS, different UI in macOS. I'm opposed to adding a modal.
• [simeon] For extension developers, it would be nice if there were ways to direct users to the relevant native UI to toggle this behavior.
• [carlos] As an extension developer, I agree with Simeon - it is very difficult to teach users to toggle incognito access.
• [david] The expectation is that users that use private browsing are able to turn off and on access to private browsing in Safari without going into the settings.
• [rob] I have some reservations. Not currently possible for an extension to know if the extension has private browsing access. Could run into issues where extensions that aren't designed to work with multiple browsing modes leak data.
• [rob] I'm opposed, or neutral at best to the requested feature here.

Issue 659: WECG at TPAC 2024

• [timothy] Created issue for TPAC. Simeon created a wiki page.
• [simeon] In previous meetups, we had information scattered over the issue, and not everyone is able to modify the first comment. I added a schedule + timeslots to the wiki.
• [simeon] We were not able to get a single room for the duration of TPAC, so we have 1 room on day 1 (Monday), a different room on day 2, and the same room on Thursday and Friday. Friday is a fully-booked day, so if you plan to leave earlier, get involved in the planning so that your topic is scheduled earlier.
• [timothy] Wednesday is the off-day, reserved by the W3C for their plenary sessions. We haven't scheduled anything for us on that day.
• [rob] Can everyone actually edit the wiki? In Github there is a setting in the repo's settings section to control that access.
• [simeon] I thought that I enabled that option. (confirmed)

PR 641: Proposal: Per-extension language preferences

• [timothy] Some recent activity.
• [jackie] Question from Rob is which methods should be available in content scripts. IMO it makes sense to expose getCurrentLanguage, but not setCurrentLanguage.
• [carlos] Also makes sense to expose onLanguageChanged.
• [timothy] What is the main blocker?
• [jackie] Another problem is, for setCurrentLanguage, what is a valid locale? If the language exists but it not in the messages file, can the developer set it still?
• [rob] You can put something in the proposal and then we can review.
• [rob] Abuse concern - an extension can have different names in the locales, and allowing them to change the locale at runtime could enable them to change name/description/etc, and confuse the user about the true name of the extension.
• [carlos] A potential solution is to use the language of the extension management page.
• [simeon] There may then be a mismatch between the language displayed in the extension page vs the language of the embedded options page.
• [rob] Please update the PR with what you think is a good approach, and then we can continue the review from there.

The next meeting will be on Thursday, August 1st, 8 AM PDT (3 PM UTC)