diff --git a/_minutes/2023-09-28-wecg.md b/_minutes/2023-09-28-wecg.md new file mode 100644 index 00000000..2d4411fd --- /dev/null +++ b/_minutes/2023-09-28-wecg.md @@ -0,0 +1,190 @@ +# WECG Meetings 2023, Public Notes, Sep 28 + + * Chair: Timothy Hatcher + * Scribes: Rob Wu + +Time: 8 AM PDT = https://everytimezone.com/?t=6514c200,384 +Call-in details: [WebExtensions CG, 28th September 2023](https://www.w3.org/events/meetings/1cc4723f-c539-4c9b-94d2-912bcc2598c9/20230928T080000/) +Zoom issues? Ping @zombie (Tomislav Jovanovic) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) + + +## Agenda: [github issues](https://github.com/w3c/webextensions/issues) + +The meeting will start at 3 minutes after the hour. + + * **Carry-over from previous meetings** + * [Issue 445](https://github.com/w3c/webextensions/issues/445): Inconsistency: notifications.NotificationOptions + * [Issue 446](https://github.com/w3c/webextensions/issues/446): Proposal: Trigger navigation dependent APIs on JavaScript Navigation + * [Issue 449](https://github.com/w3c/webextensions/issues/449): Provide way of handling unsupported DNR rules + * [Issue 451](https://github.com/w3c/webextensions/issues/451): Allow extensions to register full-fledged programmatic protocol handlers + * [Issue 452](https://github.com/w3c/webextensions/issues/452): Idle API: no way to reset the interval to default after idle.setDetectionInterval() + * [Issue 454](https://github.com/w3c/webextensions/issues/454): Add a new manifest key to include a origin trial token + * **Other new issues** + * (moved to next meeting) + * **Open discussion queue (add yourself at the bottom)** + * None + * **Check-in on ongoing issues** + * None + + +## Attendees (sign yourself in) + + 1. Timothy Hatcher (Apple) + 2. Rob Wu (Mozilla) + 3. Richard Worth (Capital One) + 4. Giorgio Maone (Tor, NoScript) + 5. Patrick Kettner (Google Chrome) + 6. Rémi Pujo (Dashlane) + 7. Simeon Vincent (Unaffiliated) + 8. Oliver Dunk (Google Chrome) + 9. Mukul Purohit (Microsoft) + 10. Sam Macbeth (DuckDuckGo) + 11. Tomislav Jovanovic (Mozilla) + 12. Kiara Rose (Apple) + 13. Carlos Jeurissen (Jeurissen Apps) + 14. Maxim Topciu (AdGuard) + 15. David Johnson (Apple) + + +## Meeting notes + +(intro - meeting structure) + + * [timothy] At TPAC we discussed the idea of having separate meetings to make progress on our goals, OR separating out some time during our existing meetings to make progress on testing, writing documents, etc. instead of just going over our list of issues. What do the folks around here think? + * [simeon] I think that it would be useful to have a dedicated backlog cleanup. I'm hesitant to change the structure of this meeting, because I think that there is a lot of utility in the current structure, putting emphasis on getting feedback from the community in a timely fashion. + * [timothy] Yes, I also like that aspect. + * [simeon] But because of that, we do not make progress on things that aren't brought to us externally. I'm inclined to introduce a dedicated hour once-a-month to talk to issues in more depth than we'd be able to do otherwise. + * [oliver] I don't feel strongly about whether it's an extra meeting. I do see that there are issues where we could be making more progress. + * [tomislav] Getting more focused and making use of the time we already have could be a start. E.g. once a month is every other meeting in the current schedule. + * [timothy] Sounds like we're + * [rob] Would be good to make progress on tests. If we can fit that in the existing structure, great. Otherwise we may want to set aside additional time for this and make sure relevant people join. Does that make sense? + * [oliver] I think so. Would like to make sure the right parties are able to participate. + * [tomislav] Community members, do you have any thoughts? + * [richard] Sounds a little like we're trying to get more done in the same amount of time. Backlog and new issues and testing. That's a lot to cover. + * [tomislav] Fair. + * [rob] Should we bite the bullet and set aside additional time? + * [timothy] I do worry that every four weeks, we wouldn't get through the list of issues that we have. Usually we do need the full hour to talk about the issues we already have. + * [simeon] I strongly feel that trying to fit it in our existing schedule is insufficient. + * [tomislav] It may be difficult to get time on people's calendars across so many organizations. Suggest that we scope down current meetings in order to make time to clean up. + * [rob] The value of these meetings is discussing relevant issues directly with the community. I worry that deprioritizing new issues will result in an ever-increasing backlog. Suggest we discuss this topic async and focus the rest of the current meeting on our agenda. + * [timothy] Sounds good. + +[Issue 445](https://github.com/w3c/webextensions/issues/445): Inconsistency: notifications.NotificationOptions + + * [timothy] Safari doesn't support this, so I don't have context here. + * [oliver] What's available in notifications is platform-specific. Even if some properties are supported, their actual effective behavior depends on the platform. + * [rob] What do we want to do here? Oliver, would the actionable part here doing a review of the feature set to determine the desired set of properties supported in the long term? + * [oliver] Some options are only supported on some platforms. Worth discussing which options the community wants to see added, what's useful, etc. + * [timothy] Consistency would be helpful for Safari's work here as well. + * [oliver] This issue lists items Chrome supports, but would be useful to understand what options are useful and why. + * [timothy] Anyone with feedback on what you use and why you use it would be very welcome. Telemetry would also help. + * [patrick] We can investigate this. Are you interested per use by extension or call counts? + * [timothy] Per extension. + * [patrick] I think that we have that data, I'm not sure if we can share that. + * [tomislav] Just the conclusion would already be helpful, without the raw data. + * [timothy] That's about it for this issue. + * [tomislav] Similarly to what Oliver was saying, the originally supported feature set in Firefox was dependent on the feature set available from the native platform. A potential outcome could be “this option is recognized but does nothing”. + * [timothy] I agree. We shouldn't go with the lowest common denominator; extensions should be able to use platform features if available. + +[Issue 446](https://github.com/w3c/webextensions/issues/446): Proposal: Trigger navigation dependent APIs on JavaScript Navigation + + * [timothy] I don't think that this is something we should pursue. I think it's dangerous to reinject scripts. + * [rob] I'm surprised about the existence of this issue. webNavigation has an event for JS navigation. There are a number of extension and DOM APIs that extensions can use for this use case. I don't think there's anything else we could provide. + * [tomislav] Is that a Chrome-only event? I'm not aware of a capability in Firefox. + * [rob] Some sites may have different mechanisms for navigation that are independent of this event. For example, YouTube. It's often site specific to implement this. + * [tomislav] I have had similar experiences. There's no single event that's a reliable cross-site. + * [rob] Right, the browser can't do better here. If there's a way we can solve this generally it should be implemented at a web platform level. + * [sam] I agree - this is not an issue in content scripts. In the background context, the events that exist that make this possible is onHistoryStateUpdated. This isn't available in Safari, which requires us to come up with workarounds. + * [timothy] I'm supportive of exposing this Safari. I don't think there's anything else we can do with this issue. + * [rob] I'll close out after the meeting. + +[Issue 449](https://github.com/w3c/webextensions/issues/449): Provide way of handling unsupported DNR rules + + * [oliver] I filed this, but Sam brought this up. + * [sam] The DNR “spec” is not a fixed format, and may receive new features. I posted a comment that documents the current behavior. + * [sam] Chrome refuses to load the extension (in developer mode only?) if a static ruleset contains an “invalid” rule. + * [simeon] Safest cross-browser approach is now to use the minimum functionality, which is not desired long-term. + * [sam] TPAC discussion indicated Chrome ignores invalid rules, but there may not be a feedback mechanism for invalid rules. Not sure how Firefox behaves. + * [rob] For clarification, you mentioned in Developer Mode in Chrome it fails to load, and then shortly after you said Chrome ignores invalid rules. What did you intend to say? + * [sam] Chrome's static rules error, Firefox ignores static rules. + * [sam] Is there a feedback mechanism that can be useful? + * [timothy] Not entirely sure what happens in Safari. I know that in developer mode warnings are shown in the settings, and that invalid rules are ignored. Dynamic rule registration rejects the promise. + * [rob] Dynamic and session rules are rejected completely if any rule is invalid. There is no feedback for static rules beyond logging in the developer tools. + * [timothy] Supportive of adding a isRuleSupported or other feedback mechanism for static rules. + * [sam] For dynamic rules, something similar to isRegexSupported would be useful + * [rob] Cross-browser way to approach this is to register a rule dynamically and see if it fails. Other than the tabIds condition (meaningless in static rules), static and dynamic rules have the same syntax. Can you elaborate on why this is insufficient? + * [sam] This specific issue is not a problem right now; since MV3 shipped, DNR hasn't changed much, at least not in backwards-incompatible ways. Not currently shipping MV3 in Safari. This could be a challenge because we'll need to figure out what's compatible across browsers. + * [timothy] More of an issue as features change or browser progressively adopt new capabilities. + * [oliver] We already have supportive:chrome on this one. I definitely think that it'd be good tot have soft failures. + * [timothy] If we reject the entire static list, we should change to only reject individual rules. I will file an issue to track this in Safari. + * [rob] Next step is to agree between browsers & community how we handle invalid rules. If the mechanism is well defined it's easier to account for. + * [sam] I'll try to complete the support matrix for the current state across platforms. + * [rob] Also specify what you mean by invalid rule. There are many ways a rule could be invalid (incorrect key, invalid value, etc.) + * [timothy] We'll want to come back to this issue. + +[Issue 451](https://github.com/w3c/webextensions/issues/451): Allow extensions to register full-fledged programmatic protocol handlers + + * [timothy] This is not something we support in Safari today. We're also opposed to this, because we want this to be handled at the system level and not in a browser context only. + * [simeon] My read of this issue is a request for protocol-wide handlers. + * [timothy] Okay. Still something we're not likely to support. In our opinion OS wide protocol handlers should be handled through the extension's associated app. + * [oliver] The biggest thing that stands out here is that it'd be a lot of work. We'll probably not prioritize this anytime soon. + * [oliver] Right now this looks like it would only work through a fetch event listener in the service worker. As such, it would only handle things that look like HTTP. Not sure if that's intentional. + * [tomislav] I think the idea was to expand existing support, so close resemblance to HTTP is semi-intentional. Not necessarily opposed to this. Much of this could be be handled with webRequest.filterResponseData. + * [rob] Not for alternate protocols, just HTTP(S). + * [tomislav] Yes. We already provide a sort-of similar approach. We likely wouldn't pursue this without other browser vendors leading the way. It's not a priority for us. + * [rob] Sounds like the “consensus” here is that it is not a priority for any of us to implement. + * [oliver] To do this within a browser, you could accomplish this by building a mini-browser in your extension. + * [tomislav] Not totally the same. Image resource resolution, etc. + * [oliver] Good point. + * [timothy] Sounds like there's not much more to add right now. Let's move on. + +[Issue 452](https://github.com/w3c/webextensions/issues/452): Idle API: no way to reset the interval to default after idle.setDetectionInterval() + + * [timothy] (reading the issue) Chrome will throw if the interval is less than the default minimum. Having a way to see the default via a constant or a way to null the current value to reset may be ideal. + * [rob] Firefox supports this API and method. + * [tomislav] I think our minimums are different. + * [rob] Regardless of minimums, it would be less demanding to the API implementation to provide a way to reset rather than exposing the default. Exposing a constant implies the browser must always behave like that. + * [oliver] Do you expect that this would ever be dynamic? + * [tomislav] If you're on battery power or a different profile, perhaps? Some timers behave differently based on power state. + * [oliver] Is the interval how often we check or how long it has to be idle to consider it tø be idle? I think it's the second. The dev has no control over that, so I don't think there are performance concerns fo what this value could be set to, but there's a minimum, so perhaps there is? + * [rob] Our minimum is also 15 (like Chrome). + * [timothy] Rob, you'd be more supportive of resetting than exposing a constant, correct? + * [rob] Yes. There are other APIs where a constant can change (session.MAX_SESSION_RESULTS). That design decision leads to the system being more complicated than necessary. + * [oliver] Do you have any preference for a null parameter vs a reset method? + * [rob] No strong preference. + * [timothy] A separate method would enable easier feature detection. + * [tomislav] I don't have concerns about making the minimum a constant. + * [patrick] On feature detection, if you passed null, we'd also want a way to query the current value. At the moment this isn't exposed, correct? + * [timothy] There appears to be a setter, not a getter. + * [patrick] We'd want to expose that. + * [oliver] If we had a new API, we'd want to return the value or we'd still have the same problem. + * [timothy] Yes, a getter is probably warranted no matter the option we chose. + * [rob] We've discussed method vs. constant. Oliver asked the question, but I'd like to revisit: does anyone think we'd need to change the constant? + * [timothy] I don't anticipate it changing if we were to support the API, but we don't support the API yet, so I don't have enough context. + * [oliver] I can check on the Chrome side, but I don't anticipate it changing. Maybe in future versions of Chrome? + * [timothy] We have infrastructure to change constants. Not much worry on our side. + * [rob] It's also feasible to do so in Firefox. I previously mentioned implementation complexity, but that is mainly due to the “constant” being configurable by the user. + * [timothy] We'll follow up on this offline. + +[Issue 454](https://github.com/w3c/webextensions/issues/454): Add a new manifest key to include a origin trial token + + * [patrick] This issue is mostly what it says on the tin. Normally enabled via a HTTP header or meta tag. Notable recent use is WebSQL's live being extended via origin trial. Used to experiment with new web features. + * [rob] These origins trials are browser specific, correct? + * [patrick] Correct. The concept is not browser-specific, technically. The individual origin trails are browser specific. In Chrome the value is only there for ~8 weeks. Won't stay long term. I don't think you'd need to have a browser-specific field. + * [rob] My question was should we expose this in browser specific settings? + * [patrick] Since the concept is cross-browser, it would make more sense to have this as a top-level key. Since there are values that are regularly added or removed in Chrome, invalid values are simply ignored. While there might be a conflict, it's essentially a noop. + * [rob] My concern was with conflicts, but we already have that with headers today. + * [patrick] The string is base64 encoded with data about the origin and dates. The chance of collision is very low. + * [timothy] As long as browsers soft-fail (ignore) unrecognized trials without failing, I'm supportive of this. + * [anton] Can it be an array of strings so we can participate in multiple trials? + * [patrick] Yes. + * [carlos] Would it make sense for performance to separate these values in browser specific settings? + * [patrick] Not sure I follow. If they don't support this field they'd ignore it. + * [rob] The list could get very large if multiple browsers support it. Shouldn't be too expensive, it would be an install-time check. + * [carlos] ? + * [timothy] As long as the browser can perform a quick lookup, it should be easy and fast to skip invalid tokens. If it requires network or other costly lookup, it may make sense to move into browser specific settings. + * [tomislav] I believe they're cryptographically signed. I believe Firefox only supports one origin trial experiment. Not sure if this is a feature we'll support long term, will need to investigate. Making it an array solves the concern about multiple browser tokens. + * [rob] On Firefox we can likely say supportive. If we don't support origin trials long term, we can ignore this value. If we do, we can read values. + * [timothy] I'm supportive of this at the top-level in Safari. It would be a key we currently ignore. + +The next meeting will be on [Thursday, October 12th, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=65273700,384). diff --git a/_minutes/README.md b/_minutes/README.md index 176ef0e7..d986d274 100644 --- a/_minutes/README.md +++ b/_minutes/README.md @@ -10,24 +10,25 @@ After the end of each meeting, meeting notes are published here. ## Upcoming meetings -- 2023-09-28 at 8 AM PDT = https://everytimezone.com/?t=6514c200,384 - 2023-10-12 at 8 AM PDT = https://everytimezone.com/?t=65273700,384 +- 2023-10-26 at 8 AM PDT = https://everytimezone.com/?t=6539ac00,384 ## Past meetings +* 2023-09-28 ([minutes](2023-09-28-wecg.md)) * 2023-09-14 ([minutes](2023-09-14-wecg.md)) * 2023-09-12 at TPAC ([minutes](2023-09-12-wecg-tpac.md)) * 2023-09-11 at TPAC ([minutes](2023-09-11-wecg-tpac.md)) * 2023-08-31 ([minutes](2023-08-31-wecg.md)) * 2023-08-17 ([minutes](2023-08-17-wecg.md)) * 2023-08-03 ([minutes](2023-08-03-wecg.md)) -* 2023-07-20 ([minutes](2023-07-20-wecg.md))
All past meeting notes **2023** +* 2023-09-28 ([minutes](2023-09-28-wecg.md)) * 2023-09-14 ([minutes](2023-09-14-wecg.md)) * 2023-09-12 at TPAC ([minutes](2023-09-12-wecg-tpac.md)) * 2023-09-11 at TPAC ([minutes](2023-09-11-wecg-tpac.md))