-
Notifications
You must be signed in to change notification settings - Fork 56
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Publish minutes of 2022-04-14 meeting
- Loading branch information
Showing
2 changed files
with
145 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,143 @@ | ||
| # WECG Meetings 2022, Public Notes, Apr 14 | ||
|
|
||
| * Chair: Timothy Hatcher | ||
| * Scribes: Rob Wu | ||
|
|
||
| Time: 8 AM PST = https://everytimezone.com/?t=62576400,3c0 | ||
| Call-in details: [WebExtensions CG, 14th April 2022](https://www.w3.org/events/meetings/d7bbce8f-549f-46ea-b440-ea6902f8707c/20220414T080000) | ||
| Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) | ||
|
|
||
|
|
||
| ## Agenda: [discussion in #195](https://github.com/w3c/webextensions/issues/195), [github issues](https://github.com/w3c/webextensions/issues) | ||
|
|
||
| The meeting will start at 3 minutes after the hour. | ||
|
|
||
| * **Carry-over from previous meetings** | ||
| * None | ||
| * **Other new issues** | ||
| * [Issue 8](https://github.com/w3c/webextensions/issues/8#issue-917621223): executeScript API may inject scripts in an unexpected target at runtime (documentID proposal) | ||
| * [Issue 191](https://github.com/w3c/webextensions/issues/191): Should background pages be allowed to navigate? | ||
| * [Issue 196](https://github.com/w3c/webextensions/issues/196): Proposal: onDoubleClicked for browserAction | ||
| * [Issue 197](https://github.com/w3c/webextensions/issues/197): feature request: content_security_policy_report_only in manifest.json | ||
| * [Issue 198](https://github.com/w3c/webextensions/issues/198): Proposal: action.default_area=navbar and action.default_area=hidden | ||
| * [Issue 199](https://github.com/w3c/webextensions/issues/199): Streamline and optimize after-install dialog action buttons | ||
| * **Open discussion queue (add yourself at the bottom)** | ||
| * Update on [Issue 170:](https://github.com/w3c/webextensions/issues/170) Proposal: Offscreen Documents for Manifest V3 | ||
| * **Check-in on ongoing issues** | ||
| * [Issue 119](https://github.com/w3c/webextensions/issues/119): Proposal: add optional_host_permissions | ||
|
|
||
|
|
||
| ## Attendees (sign yourself in) | ||
|
|
||
| 1. Rob Wu (Mozilla) | ||
| 2. Craig Lurey (Keeper) | ||
| 3. Rainer Enders (Keeper Security) | ||
| 4. Tomislav Jovanovic (Mozilla) | ||
| 5. Oliver Dunk (1Password) | ||
| 6. Steven McLintock (1Password) | ||
| 7. Carlos Jeurissen (Jeurissen Apps) | ||
| 8. Timothy Hatcher (Apple) | ||
| 9. Simeon Vincent (Google) | ||
| 10. Dave Tapuska (Google) | ||
| 11. Tim Heflin (Keeper) | ||
| 12. Alexei (Privacy Badger) | ||
| 13. Zane Bond (Keeper Security) | ||
| 14. Krzysztof Modras (Ghostery) | ||
| 15. Mukul Purohit (Microsoft) | ||
| 16. Tyler Carson (Keeper) | ||
| 17. Richard Worth (Capital One) | ||
| 18. James Hycner (Keeper) | ||
|
|
||
|
|
||
| ## Meeting notes | ||
|
|
||
| [Issue 8](https://github.com/w3c/webextensions/issues/8#issue-917621223): executeScript API may inject scripts in an unexpected target at runtime (documentID proposal) | ||
|
|
||
| * [timothy] This is one of the first issues that mentioned the concept of documentID. Dave from the Chrome team is here to discuss. | ||
| * [dave] Chrome is currently working on pre-rendering. Initial motivation for pursuing documentId is that frameID is a bit difficult to work with in this context. | ||
| * [rob] This is the “Exposing Document Info to Extensions” proposal that is being discussed: https://docs.google.com/document/d/1xOe5e8CDU9HM6sazGg6aqvK0iPnptilmwBS9qiZSfkY/edit | ||
| * [dave] Proposing documentId, parentDocumentId, documentLifeCycle (prerendering, cached, etc.) and frameType properties. frameType includes fenced_frame (that we're working on as part of Privacy Sandbox). | ||
| * [dave] Properties on most events, but only documentId in the runtime.onMessage events for performance reasons. | ||
| * [rob] runtime.onMessage is less frequent than webRequest/webNavigation, but there are more fields on webRequest/webNavigation events than messaging. | ||
| * [timothy] curious how Chrome handles the prerender path today. Something we're interested in on Safari | ||
| * [dave] This code is still very experimental. Thinking of getFrame to get the documentId and then allowing extensions to send messages by documentId. | ||
| * [timothy] Specifically interested in whether there is script execution in prerendered pages. | ||
| * [dave] Still WIP, but content scripts would execute in prerendered pages. executeScript+allFrames currently executes in the active page, but should also run in prerendered pages. | ||
| * [tomislav] There will be situations where there are two documents in the top-level frame. | ||
| * [tomislav] For runtime.onMessage/onConnect it could be useful for extensions to know whether the caller is in a prerender or not - suggesting to include more properties besides documentId (e.g. documentLifeCycle). | ||
| * [dave] That comes down to the feedback of whether we expose all the properties on the various events. | ||
| * [rob] documentId is currently documented to be some opaque string. What about non-document contexts such as web workers? They can initiate requests | ||
| * [dave] it's an optional flag. documentId is only exposed for things backed by frames. I'll need to think about that as well. | ||
| * [alexei] This proposal may help with answering questions like what is the top-level document URL that a request belongs to, so that's exciting. This however does not address the cases where a Service worker fetches on behalf of a web page. | ||
| * [dave] Correct, subsequent request not executed in the context of the service worker | ||
| * [alexei] Extension devs have been requesting a way to synchronously get the URL of the top-level document that a given request belongs to for many years now (for example, https://crbug.com/856766). This is a big pain point for extensions that need to understand the full context of each request; this new API might help with some edge cases, but unfortunately not with service worker-originated requests as per above. | ||
| * [alexei] You're mentioning the possibility of there being two documents in the top-level frame, wouldn't that cause backwards compatibility issues? | ||
| * [dave] There is only one top level frame, index 0. A pre-render frame tree will be indicated by non-zero frameId - that's the backward incompatible part. | ||
| * [rob] To confirm, are you saying that the prerender frame will have a non-zero frameid, and that it's mutable? That sounds like a significant change in the extension API. | ||
| * [dave] In Chrome, frameId 0 is just an alias for the active frame. If something is tracking based on that frameId 0, that could be problematic. | ||
| * [rob] With the introduction of documentId, exposing this as a non-zero frame ID may be problematic. | ||
| * [dave] That's why we also include frameType, the top-level frame would have frameType “outermost_frame”. | ||
| * [tomislav] If we're introducing frameType to identify the top-level frame, then I would also be in favor of having a non-zero frameId everywhere. | ||
| * [oliver] Changing frameIds over the lifetime of the same document can cause issues, e.g. when runtime.onMessage changes frameId. | ||
| * [rob] given the concern over changing frame ID, how about leaving frameId as is and using documentId to target specific documents. If you are concerned about extensions not being prepared to deal with prerendered tabs, then you could consider allowing extensions to opt in to the visibility of prerendered tabs via the extension manifest. | ||
| * [dave] Prerendered has not shipped yet, we do not know yet how many extensions actually break. | ||
| * [timothy] I was of the impression that Chrome already had some prerendering support. | ||
| * [dave] Prerendering was shipped and unshipped on desktop. Our goal is that extensions will execute in prerender. | ||
| * [rob] Let's continue the rest of the discussion in the Github issue or in the Matrix chat since we've already spent half of the meeting on this. | ||
|
|
||
| [Issue 191](https://github.com/w3c/webextensions/issues/191): Should background pages be allowed to navigate? | ||
|
|
||
| * [timothy] I filed this. There's some inconsistency across browsers. Safari allows this, Chrome blocks it, Firefox seems to allow it. | ||
| * [tomislav] Officially not by design in Firefox, we just didn't prevent it. Safe to say it's not something we intend to support. | ||
| * [rob] What about same origin navigation? | ||
| * [timothy] That's the only thing we allow in Safari. | ||
| * [rob] In the issue you mentioned “Safari 14+ allows navigations” - does that mean same-origin navigation only and not remote URLs? | ||
| * [timothy] Yes. | ||
| * [simeon] Already covered what Chrome does here, but | ||
| * [rob] Related, what about extension popups? They can navigate elsewhere to a remote URL, is this support deliberate? | ||
| * [timothy] Pretty sure that Chrome supports this too, we checked and implemented it too. | ||
| * [simeon] Not sure if it is deliberate. I can see the use case for same origin navigation, but I'm hesitant about potential security issues and encouraging (or at least implicitly endorsing patterns we don't want to encourage. | ||
| * [carlos] If we are resolving to change behavior, suggest limiting this to a new manifest version bump or at least limiting it to manifest v3. | ||
| * [rob] For Firefox we would limit this to MV3, maybe also MV2 if it makes sense later. Chrome does not support background pages/event pages in MV3. How about Safari? | ||
| * [timothy] In Safari we do support this currently, but don't anticipate much breakage. | ||
| * **Resolution**: No, background pages should not be allowed to navigate to remote URLs. Same-origin navigation are permitted. | ||
|
|
||
| [Issue 196](https://github.com/w3c/webextensions/issues/196): Proposal: onDoubleClicked for browserAction | ||
|
|
||
| * [timothy] Short recap: some extension developers implement double-click behavior to change what the extension does based on whether the user single or double clicks the action. | ||
| * [tomislav] Not in favor, because there are no other buttons in the browser UI with similar behavior. There is no affordance for it. And it is not available on mobile either. Probably not going to implement that in Firefox. | ||
| * [simeon] Hesitant about the feature too, but understands the developer's concern. This is already possible in user land (with the existing APIs), so there is probably no need for a new platform API for this. | ||
| * [rob] Chrome's documentation emphasizes that setTimeout/setInterval are not reliable, but they are actually for this specific use case. | ||
| * **Resolution**: Do not introduce the requested onDoubleClicked event. | ||
|
|
||
| [Issue 197](https://github.com/w3c/webextensions/issues/197): feature request: content_security_policy_report_only in manifest.json | ||
|
|
||
| * [carlos] This proposal is to introduce a new report-only manifest key. | ||
| * [simeon] Can you clarify the difference between this issue and [issue 97](https://github.com/w3c/webextensions/issues/97): replacement for deprecated report-uri for content_security_policy | ||
| * [carlos] CSP-report-only could have stricter policies to allow extensions to migrate to a stricter CSP later on. | ||
| * [timothy] Open to this on the Safari side | ||
| * [rob] Are you asking about triggering CSP violation events (report-only) or reporting them to a remote server? I have concerns about the latter. | ||
| * [carlos] How do the browsers feel about this? | ||
| * [timothy] Initially supportive. (Safari) | ||
| * [simeon] I think that this worth further discussion. (Chrome) | ||
| * [rob] I'm not convinced that we need this capability, but interested in following along with the discussion. (Firefox) | ||
|
|
||
| [Issue 198](https://github.com/w3c/webextensions/issues/198): Proposal: action.default_area=navbar and action.default_area=hidden | ||
|
|
||
| * [carlos] Given the time, best to move on to 199. This is a sub-issue of that one. | ||
|
|
||
| [Issue 199](https://github.com/w3c/webextensions/issues/199): Streamline and optimise after-install dialog action buttons | ||
|
|
||
| * [carlos] Inconsistent behavior across browsers in the install flow. Would be nice to offer controls to allow the user to e.g. pin the extension action button. | ||
| * [rob] We can talk about it, but this isn't something we'd standardize because this is browser-specific UI and UX. | ||
| * [simeon] Worth mentioning that Chrome is working on updating the (extension) browser UI and toolbar. We intentionally passed on the ability to pin the button in the install flow. I will follow up to that in the issue. | ||
| * [simeon] Some additional context from the Chrome side: the extension menu currently has 3 groups of extensions (full access, access requested, no access needed). The middle option is essentially "the extension wants to run." In the updated UI, we lean more into surfacing when an extension wants to run and giving the user an opportunity to grant access. That may help address some concern around pinning an action. We're also considering declarative content badging - a way for extensions to surface that they can do something in a page that doesn't expose page data to the extension. Hopefully together these will alleviate the need to be pinned. | ||
| * [tomislav] Are you considering exposing an API to explicitly signal that the extensions "wants to run"? | ||
| * [simeon] nothing concrete, but I feel like this is valuable and would be happy to continue discussing this | ||
|
|
||
| [Issue 119](https://github.com/w3c/webextensions/issues/119): Proposal: add optional_host_permissions | ||
|
|
||
| * (ran out of time; did not discuss this in the meeting) | ||
| * [timothy] Landed in Safari Technology Preview 142, and is being tested in Safari 15.5. | ||
|
|
||
| The next meeting will be on [Thursday, April 28th, 8 AM PST (3 PM UTC)](https://everytimezone.com/?t=6269d900,3c0). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters