|
| 1 | +# WECG Meetings 2023, Public Notes, Nov 23 |
| 2 | + |
| 3 | + * Chair: Simeon Vincent |
| 4 | + * Scribes: Rob Wu |
| 5 | + |
| 6 | +Time: 8 AM PST = https://everytimezone.com/?t=655e9600,3c0 |
| 7 | +Call-in details: [WebExtensions CG, 23rd November 2023](https://www.w3.org/events/meetings/1cc4723f-c539-4c9b-94d2-912bcc2598c9/20231123T080000/) |
| 8 | +Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) |
| 9 | + |
| 10 | + |
| 11 | +## Agenda: [agenda discussion in #488](https://github.com/w3c/webextensions/issues/488), [github issues](https://github.com/w3c/webextensions/issues) |
| 12 | + |
| 13 | +The meeting will start at 3 minutes after the hour. |
| 14 | + |
| 15 | + * **Carry-over from previous meetings** |
| 16 | + * [Issue 433](https://github.com/w3c/webextensions/issues/433): Alarms API time slipping |
| 17 | + * [Issue 474](https://github.com/w3c/webextensions/issues/474): Behavior of extension message ports and bfcache |
| 18 | + * **Other new issues** |
| 19 | + * [Issue 477](https://github.com/w3c/webextensions/issues/477): Proposal: userScripts.execute() method |
| 20 | + * [Issue 489](https://github.com/w3c/webextensions/issues/489): Proposal: Re-evaluate userScript and userStyle API |
| 21 | + * [Issue 490](https://github.com/w3c/webextensions/issues/490): Support Promise as return value from webRequest.onAuthRequired |
| 22 | + * [Issue 492](https://github.com/w3c/webextensions/issues/492): Issue with chrome.declarativeNetRequest Not Blocking Requests Over Time |
| 23 | + * [Issue 493](https://github.com/w3c/webextensions/issues/493): Support redirect-only rule in DNR |
| 24 | + * **Open discussion queue (add yourself at the bottom)** |
| 25 | + * None |
| 26 | + * **Check-in on ongoing issues** |
| 27 | + * [Issue 483](https://github.com/w3c/webextensions/issues/483): Proposal: API to embed pages in WebExtension bypassing CSP |
| 28 | + |
| 29 | + |
| 30 | +## Attendees (sign yourself in) |
| 31 | + |
| 32 | + 1. Rob Wu (Mozilla) |
| 33 | + 2. Simeon Vincent (unaffiliated) |
| 34 | + 3. Tomislav Jovanovic (Mozilla) |
| 35 | + 4. Oliver Dunk (Google) |
| 36 | + 5. Carlos Jeurissen (Jeurissen Apps) |
| 37 | + 6. Dmitriy Seregin (AdGuard) |
| 38 | + 7. Anton Bershanskyi (unaffiliated) |
| 39 | + |
| 40 | + |
| 41 | +## Meeting notes |
| 42 | + |
| 43 | +Intro |
| 44 | + |
| 45 | + * [rob] There are only 6 people here right now, probably due to Thanksgiving. Let's only cover topics that do not require input from everyone. |
| 46 | + |
| 47 | +[Issue 433](https://github.com/w3c/webextensions/issues/433): Alarms API time slipping |
| 48 | + |
| 49 | + * [oliver] It is unclear how the alarms API behaves when the device goes to sleep. At TPAC we decided that consistency with the web would be nice. I have investigated setTimeout, but it is unclear what should happen. In practice, macOS+Linux pause the timer during sleep, on Windows the timer continue. |
| 50 | + * [simeon] I was surprised that the WHATWG discussion didn't include mention of setInterval. |
| 51 | + * [oliver] I think that setInterval is basically setTimeout + scheduling a new timer. |
| 52 | + * [tomislav] Yes, and it's crucial that the intervals are scheduled upfront, so that any “past” scheduled timers are not fired immediately after wakeup. |
| 53 | + * [oliver] The web is leaning towards pause on sleep. At the same time enough uncertainty to make our own decisions independent of the web platform. I am leaning towards wall clock time. That would also make the API consistent, always using wall clock time instead of only sometimes wall clock. |
| 54 | + * [simeon] I'm also leaning towards wall clock time. I think the expectation of extensions is associated with the system rather than the page. |
| 55 | + * [oliver] Firefox folks? |
| 56 | + * [rob] Does wall clock imply changes to browser behavior? Timothy already mentioned that Safari already uses wall clock time. |
| 57 | + * [oliver] Chrome sometimes timer-based, but Chrome recalculates when other timers should fire. |
| 58 | + * [rob] I think we use a timer, but not sure what happens with the timer when slept. Did you already check if the change would better match developer expectations? |
| 59 | + * [tomislav] how do we verify that? |
| 60 | + * [rob] I guess we have bugs either way. |
| 61 | + * [tomislav] Since the web is not 100%, might make sense to be as simple and consistent as possible. |
| 62 | + * [rob] If we do wall clock time, then we have to always check for expired timers whenever the device wakes up. |
| 63 | + * [oliver] I would say we fire as soon as the device starts |
| 64 | + * [rob] Please double check your thoughts/proposal with the Chrome engineering team. |
| 65 | + * [oliver] For repeating alarms, when the device wakes up we fire once for repeating alarms even if there would be multiple fired in the gap. We would then schedule the next repeated alarm for the future. |
| 66 | + * [oliver] All developers would need to implement against the device not going to sleep, so I think this most closely matches expected behavior. Only difference is repeated alarms would be collapsed. |
| 67 | + * [tomislav] This shouldn't be a major change for us. |
| 68 | + * [rob] Tentative approval for Firefox. |
| 69 | + |
| 70 | +[Issue 474](https://github.com/w3c/webextensions/issues/474): Behavior of extension message ports and bfcache |
| 71 | + |
| 72 | + * [tomislav] I investigated Firefox's behavior. My confusion was previously caused by a misunderstanding on my part. We have a situation where Ports close more often than Chromium, which we've done from the start: In the 1-to-many scenario (tabs.sendMessage when there are iframes), the Port closes whenever any of the iframes navigate. |
| 73 | + * [rob] For emphasis: this discussion is not relevant to the specific issue here; but for context: Chrome disconnects only when there is no receiver at any end, or when disconnect() is called explicitly. This behavior is documented in Chrome (many years ago I added that to Chrome's documentation). Firefox currently closes a Port when any of the contexts unload ([Firefox bug 1465514](https://bugzilla.mozilla.org/show_bug.cgi?id=1465514)). |
| 74 | + * [rob] The ask of this issue is unclear to me. Oliver, can you clarify? |
| 75 | + * [oliver] We thought the Firefox behavior provided evidence that bfcache ejection was safe. Since that's not the case, we may need to be a little more careful about this approach. |
| 76 | + * [rob] What were the alternatives you were considering? |
| 77 | + * [oliver] We weren't considering other alternatives, but we discussed some options: Keep port around, restore it. |
| 78 | + * [tomislav] The only viable alternative is to disconnect the port if the background tries to communicate with invisible contexts. |
| 79 | + * [oliver] Other alternative is to drop messages. |
| 80 | + * [tomislav] Which is worse. |
| 81 | + * [rob] … but what we do in Firefox. |
| 82 | + * [oliver] I can update the issue to reflect that it specifically reflects the plan to disconnect ports. |
| 83 | + |
| 84 | +[Issue 477](https://github.com/w3c/webextensions/issues/477): Proposal: userScripts.execute() method |
| 85 | + |
| 86 | + * [oliver] The capability was already mentioned in the proposal as something to do in the future. |
| 87 | + * [simeon] My impression of this issue is that it was the kind of capability we were considering for additional phases of userScripts API work. |
| 88 | + * [rob] Oliver, could you get your opinions from the Chrome eng team on this proposal as a preparation for the next meeting? |
| 89 | + * [oliver] Will do. |
| 90 | + |
| 91 | +[Issue 489](https://github.com/w3c/webextensions/issues/489): Proposal: Re-evaluate userScript and userStyle API |
| 92 | + |
| 93 | + * [rob] The proposal is basically to unify userScripts and scripting. It was Chrome's explicit API design request to have different namespaces for these capabilities. |
| 94 | + * [oliver] Opposed on the Chrome side. Smaller request (including support for css in userScripts) sounds more reasonable. |
| 95 | + * [rob] Having separate APIs prevents dependencies between the two. If a user script manager wanted to inject styles, with separate APIs there's no way for the user script manager (USM) to declare order of injection. |
| 96 | + * [rob] Would like to know if there are any USMs would want/need the ability to register CSS stylesheets through the userScripts API. They can already do so through the scripting namespace. |
| 97 | + * [rob] A potential argument in favor of supporting “css” in userScripts is that scripting and userScripts have different matching characteristics. User scripts want to run when either `@matches` or `@include` match the document URL, but it has been a long-standing bug in the extension API that their equivalent (`matches` and `include_globs`) are only allowed if both match the URL. In the userScripts API, this has been fixed, which may be a reason for USM to prefer one API. |
| 98 | + * [rob] Need to hear from USMs about the need for “css” support in userScripts before we implement this functionality. |
| 99 | + |
| 100 | +[Issue 490](https://github.com/w3c/webextensions/issues/490): Support Promise as return value from webRequest.onAuthRequired |
| 101 | + |
| 102 | + * [rob] Safari doesn't support webRequest, so the main question is for Chrome here: are you supportive of accepting Promises as a return value in the webRequest.onAuthRequired event handler? See issue for details. |
| 103 | + * [oliver] Seems reasonable. We previously expressed support for async runtime.onMessage in [issue 338](https://github.com/w3c/webextensions/issues/338). |
| 104 | + * [rob] This week I saw activity on Chromium's issue tracker to resolve the remaining work on “Promise support” in extension APIs. Most issues have been addressed, except for devtools APIs and these bugs. |
| 105 | + * [tomislav] If Chrome has to prioritize either of these bugs, please prioritize the runtime.onMessage one. That is a highly requested feature from extension developers. |
| 106 | + |
| 107 | +[Issue 492](https://github.com/w3c/webextensions/issues/492): Issue with chrome.declarativeNetRequest Not Blocking Requests Over Time |
| 108 | + |
| 109 | + * [rob] This looks like a Chrome bug, should be moved to crbug. Limited rule lifetime is not part of the DNR API design. |
| 110 | + * [oliver] Someone has mentioned this issue before at https://groups.google.com/a/chromium.org/g/chromium-extensions/c/kGdHMCq-yTc/m/HwbX0_PLBAAJ |
| 111 | + |
| 112 | +[Issue 493](https://github.com/w3c/webextensions/issues/493): Support redirect-only rule in DNR |
| 113 | + |
| 114 | + * [rob] Let's get clarification on the request here and discuss this at the next meeting. |
| 115 | + |
| 116 | +[Issue 483](https://github.com/w3c/webextensions/issues/483): Proposal: API to embed pages in WebExtension bypassing CSP |
| 117 | + |
| 118 | + * [rob] This is on the agenda because we needed followup from Chrome before we could discuss further. |
| 119 | + * [tomislav] We are blocked on Chrome's opinion, |
| 120 | + * [oliver] is window.top a significant concern? |
| 121 | + * [rob] before x-frame-options it was the primary technique for frame busting. Broader request is that extensions want to embed pages that don't want to be embedded. Because there is no extension API that enables extensions to pretend that content is “top-level”, they resort to alternatives such as stripping CSP/XFO. Supporting an API that offers the requested feature also has consequences, such as the origin to associate with permission requests and such. I want to understand if this capability is something Chrome wants to support, before even discussing the shape of the API. |
| 122 | + * [tomislav] Carlos, do you encounter this issue with window.top? |
| 123 | + * [carlos] Yes, it's complicated. Workarounds are very hacky. CSP modification is the biggest concern as it's not possible in Chrome MV3. |
| 124 | + * [simeon] Would it makes sense to automatically include an extension's origin in a page's effective frame-ancestors CSP if the extension has host permissions? |
| 125 | + * [rob] CSP spec allows exceptions for extensions (and bookmarklets) (https://www.w3.org/TR/CSP3/#extensions). I would like relaxation of security restrictions to be opt-in, and not enabled by default. |
| 126 | + * [oliver] Do we also want to allow relaxation of CSP for other origins? For example, using a content script to inject example.com on another website. |
| 127 | + * _unanimous agreement that we should not_ |
| 128 | + |
| 129 | +The next meeting will be on [Thursday, December 7th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=65710b00,3c0) |
0 commit comments