From 8aa90f2fb40f0f741af14d7b831fdfb8f22f384b Mon Sep 17 00:00:00 2001 From: mpurohit Date: Fri, 20 Aug 2021 14:55:03 +0530 Subject: [PATCH 1/6] Publish minutes of 2021-08-19 meeting --- _minutes/2021-08-19-wecg.md | 153 ++++++++++++++++++++++++++++++++++++ 1 file changed, 153 insertions(+) create mode 100644 _minutes/2021-08-19-wecg.md diff --git a/_minutes/2021-08-19-wecg.md b/_minutes/2021-08-19-wecg.md new file mode 100644 index 00000000..1831cbd2 --- /dev/null +++ b/_minutes/2021-08-19-wecg.md @@ -0,0 +1,153 @@ +# WECG Meetings 2021, Public Notes, Aug 5 + +* Chair: Timothy Hatcher +* Scribes: Rob Wu + +Time: 8 AM PDT = https://everytimezone.com/?t=610b2a00,384 + +Call-in details: https://lists.w3.org/Archives/Member/internal-webextensions/2021Jun/0000.html + +Zoom issues? ping @zombie (Tomislav Jovanovic, Mozilla) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) + +## Agenda: [github issues](https://github.com/w3c/webextensions/issues) + +* [Issue 50](https://github.com/w3c/webextensions/issues/50): Document "browser\_action" and "page\_action" or document "action"… +* [Issue 21](https://github.com/w3c/webextensions/issues/21): How should sidebarAction be considered, since it’s only implemented in two browsers? +* [Issue 13](https://github.com/w3c/webextensions/issues/13): Where do we start for a draft? + * Specifically "Should we contribute WebIDL files for the APIs?" +* [Issue 43](https://github.com/w3c/webextensions/issues/43): Proposal for Manifest v3: Have less restrictive security measures for force-installed extensions +* [Issue 45](https://github.com/w3c/webextensions/issues/45): Participating in TPAC 2021 + +## Queue (add yourself at the bottom) + +* hard to find Zoom link + +## Attendees (sign yourself in) + +Put a \*\*\* if you prefer this time slot: + +1. Tomislav Jovanovic (Mozilla) \*\*\* +2. Daniel Glazman (Dashlane) \*\*\* +3. Oliver Dunk (1Password) +4. Philipp Kewisch (Mozilla) \*\*\* +5. Rob Wu (Mozilla) \*\*\* +6. Timothy Hatcher (Apple) \*\*\* +7. Peter Saint-Andre (Mozilla) \*\*\* +8. Bradley Cushing (Dashlane) \*\*\* +9. Thierry Régagnon (Dashlane) \*\*\* +10. Sam Macbeth (DuckDuckGo) +11. Jon Howard (Easyfundraising) \*\*\* +12. Ellie Epskamp-Hunt (Apple) +13. Nir Nahum (WalkMe) +14. Mélanie Chauvel (Dashlane) +15. Marwan Liani (Dashlane) +16. Shane Caraveo (Mozilla) +17. Todd Schiller (PixieBrix) \*\*\* +18. Pawel Wszola (OceanHero) +19. Simeon Vincent (Google) \*\*\* +20. Mukul Purohit (Microsoft) +21. Sohail Rajdev (Microsoft) +22. Andrew Beyer (1Password) \*\*\* +23. Don Hopkins (Ground Up Software) \*\*\* +24. Jack Works (Sujitech) +25. Richard Worth (Capital One) + +## Meeting notes + +[Issue 50](https://github.com/w3c/webextensions/issues/50): Document "browser\_action" and "page\_action" or document "action"… + +* [timothy] During Mélanie’s first contribution to the manifest format the question of what to do with browser\_action/page\_action/action came up. +* [simeon] Specify overlap between MV2 and MV3 +* [tomislav] Specify common where there are at least 2 implementations +* [glazou] we’re not forced to have 2 compatible implems per feature; we’re supposed to describe the WebExtensions state-of-the-art and we don’t have to be conformant to REC exit criteria and our specs go to WG for that +* [simeon] Example of Firefox’s contentScripts API vs Chrome’s scripting API; similar functionality, different approaches to registering content scripts dynamically. + * [rob] Firefox will deprecate the contentScrips namespace in favor of the scripting namespace; we can collaborate in this group to design a cross-browser compatible API. + * [simeon] In the future, it might be nice if we could get to the point where browsers support multiple versions of APIs so that we don't depend on the whole ecosystem agreeing on one canonical version at a time. + +[Issue 21](https://github.com/w3c/webextensions/issues/21): How should sidebarAction be considered, since it’s only implemented in two browsers? + +* [timothy] Opera and Firefox have implementations, are two enough to spec the API? +* [simeon] No objections to speccing it, except it is not in the overlap of MV2+MV3. +* [Mélanie/Timothy] sidebarAction is not being actively removed in mv3, therefore it is a continuation. +* [glazou] Consider showing the result of individual implementations for the browser. Add this to the templates for each entry in the manifest. This should help a lot for the future. + * For example as shown at [wpt.fyi](https://wpt.fyi) + * [simeon] Positive towards a common set of tests + * [philipp] There is also an effort in the [browser-compat-data](https://github.com/mdn/browser-compat-data) project that is used to e.g. render compatibility tables on MDN. + * Result: glazou will file an issue to track this further. +* [Simeon] We don’t need to conform to other specs, if we wanted to add visual indicators we should. +* Consensus: We should proceed by specifying it, there are 2 implementations (despite it not being a part of MV3 right now). +* Mélanie will look into documenting the manifest property, the issue will remain open for additional work. + +[Issue 13](https://github.com/w3c/webextensions/issues/13): Where do we start for a draft? + +* [from issue] "Should we contribute WebIDL files for the APIs?" +* [simeon] Sounds like a good idea. Talked to a related team, integrating definitions into spec for scripting. There is a split in how well that works. Complex or optional values are difficult to write in webidl, especially in a deeply nested part of the manifest. Team was looking to extend webidl, infrastructure folks were not very fond of that idea. +* [timothy] webidl would be more for the javascript side of things. Using JSON Schema for the manifest. +* [simeon] How are browsers doing this? Parsing the html file and plug that into their systems? +* [tomislav] Use webidl as the basis, it will be adjusted when used in the browsers. The files won’t be used wholesale. +* [timothy] Same for webkit. Apple adds attributes and annotations. More of a copy/modify scenario. +* [don] (referencing Simeon’s earlier comment) Is this similar to how typescript defines the structure? + * [simeon] Yes, there are likely similar capabilities in webidl +* [tomislav] In Firefox we are currently not using webidl, but JSON schemas as originally used in Chromium. Webidl is less descriptive, we would lose some specifity that we would still need to implement. If we go with webidl in the spec, we wouldn’t be able to cover all of the cases. We’re transitioning to webidl for ServiceWorkers, but we need JSON Schema for other validations. +* [timothy] Maybe a combination of both. Use webidl for the API level, for the individual dictionaries (e.g. tab query) we specify a separate json schema. +* [philipp] do we need both? +* [Mélanie] Webidl would be distributed with the spec? + * [simeon] This is what the webapp CG does, they publish separate schema files to jsons-schemas.org + * [Mélanie] JSON Schema helpful when using external tools, e.g. mocking all API methods. + * [timothy] If we can specify everything in json schema that would be great, we could generate + * [simeon] We can’t; JSON schemas does not support return types. + * [todd] json schema is only the data, everything further would be swagger or (opensomething?). + * [don] Can we translate the other way (webidl -> json schema) + * [timothy] webidl can be translated into anything, using a tool. Could generate a json schema shell. + * [simeon] Chrome generates extension docs from IDLs and JSON schemas +* [timothy] Moving discussion to the issue seems like the next logical step. +* [simeon] What is the goal of having webidl or json schema? + * [simeon] Spec contained idl, this was consumed in the browsers, that doesn’t seem to be the case. + * [timothy] There is a process to import these files, Apple adds more attributes. + * [tomislav] Easier to copy something from the spec and adapt as needed + * [rob] what type of info is in the apple webidl files? Is it a fundamentally lacking feature in WebIDL? + * [timothy] very specific stuff, e.g. was it implemented as NSObject. Webidl has its limits here. + * [timothy] If we separate the object definitions as Mélanie mentioned, this would be good for tooling. Unclear if we can specify everything. + * [Mukul] How does WebIdl handle variations in APIs and types by browser implementations? + * [timothy] It gets complicated when options are re-arranged, problems can come up if there is a lot of churn. Mv2 and mv3 are mostly compatible to each other, this is easily done in webidl by new scripting namespaces. + * [don] Does webidl have a generic annotation mechanism to decide when to use what? + * [timothy] There are generic attributes that could be used. + * [don] We could make that up, or use something someone has done +* [Oliver] Original intention, browser vendors are most implemented in putting together the draft. How can we distribute the workload, 1Password is very interested in contributing as well. + * [timothy] All for community contributions. See how we can split this up + * Digging into the sub-levels of the manifest + * [oliver] Sounds like spec is the main focus, how can we allocate this? + * [timothy] In previous meetings we agreed that the manifest was a good starting point. + * [glazou] To contribute, make a proposal to get it accepted by the group. It had to be kickstarted for others to contribute, so we can start contributing. Editors (and in part Chairs) will be able to help getting PRs reviewed and accepted. + +[Issue 43](https://github.com/w3c/webextensions/issues/43): Proposal for Manifest v3: Have less restrictive security measures for force-installed extensions + +* [timothy] In the issue the OP asks for relaxed restrictions for enterprise-installed extensions. +* [simeon] Do other browsers have the concept of force installation/side loading. What does Firefox do? +* [tomislav] We have something for linux distros and enterprise. This doesn’t seem like an issue that is in scope for this group. +* [nir] As an extension developer, we are counting on having the same API on all the browsers. If any browser would choose their own way to tackle this. Would be great to have a single codebase. If it is detected that the extension was not installed from the store but from central IT, in that case certain APIs would still be enabled. Example: blocking webRequest. + * [tomislav] Counter-example, we don’t distinguish between enterprise or not. We have blocking webRequest in both mv2 and mv3. + * [glazou] This is explicitly out of scope in the charter. Quote: Deployment mechanisms. We should not be discussing this. + * [nir] Not talking about the deployment, more about the APIs. + * [timothy] We could only describe the APIs, it would be up to the browser vendors to decide how to expose them. + * [rob] What is the goal behind filing the issue? + * [nir] Deprecations in mv3 are affecting vendors and customers. Enterprise use cases are affected, if we can accommodate this in the group everyone would win. Enterprises have higher requirements, browser vendors want enterprises to use the browsers. Restrictions make sense for end-users, this makes less sense for enterprise where there is a security team. + * [rob] So you’re asking for the spec to describe privileged APIs that are disabled/enabled in certain cases, is that what you (Nir) are asking? + * [Nir] Yes + * [philipp] We talked about browser compat data, can we just make this a special case of that (e.g. supported: no, caveat it is supported in the enterprise case) + * [simeon] In the context of this group we could consider making it easier to feature-detect APIs + * [timothy] De facto standard is to check whether the API is present. + * [tomislav] Thumbs up + +[Issue 45](https://github.com/w3c/webextensions/issues/45): Participating in TPAC 2021 + +* [simeon] Please add ideas to this issue to help us organize outreach for TPAC +* No time left, deferred to the next meeting. + +(queue) hard to find Zoom link + +* Zoom link is on the w3c calendar and visible if you’re logged in. +* Zoom link is also in the link in the “Call-in details” link at the top. +* Link https://www.w3.org/events/meetings/7fc25ca5-a50c-498c-82e5-f48fc96e1637 in github somewhere so people can join easier. + +The next meeting will be on [Thursday, August 19th, 11 PM PDT (Friday, August 20th, 6 AM UTC)](https://everytimezone.com/?t=60f8b500,708). After that meeting we will evaluate whether we need to adjust the current cadence. From 2bbd5b88d9e38489c4f6ebfe7b7a880ace773be5 Mon Sep 17 00:00:00 2001 From: mpurohit Date: Fri, 20 Aug 2021 14:59:59 +0530 Subject: [PATCH 2/6] Publish minutes of 2021-08-19 meeting --- _minutes/2021-08-19-wecg.md | 279 +++++++++++++++++------------------- 1 file changed, 131 insertions(+), 148 deletions(-) diff --git a/_minutes/2021-08-19-wecg.md b/_minutes/2021-08-19-wecg.md index 1831cbd2..a3278953 100644 --- a/_minutes/2021-08-19-wecg.md +++ b/_minutes/2021-08-19-wecg.md @@ -1,153 +1,136 @@ -# WECG Meetings 2021, Public Notes, Aug 5 - -* Chair: Timothy Hatcher -* Scribes: Rob Wu - -Time: 8 AM PDT = https://everytimezone.com/?t=610b2a00,384 - -Call-in details: https://lists.w3.org/Archives/Member/internal-webextensions/2021Jun/0000.html - -Zoom issues? ping @zombie (Tomislav Jovanovic, Mozilla) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) - +# WECG Meetings 2021, Public Notes—Aug 19, 2021 + +* Chair: Simeon Vincent +* Scribes: Mukul Purohit + +Time: 11 PM PDT = https://everytimezone.com/?t=611d9f00,708 + +Call-in details: https://www.w3.org/events/meetings/7fc25ca5-a50c-498c-82e5-f48fc96e1637/20210805T150000 + +Zoom issues? ping @robwu (Rob Wu, Mozilla) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) + ## Agenda: [github issues](https://github.com/w3c/webextensions/issues) - -* [Issue 50](https://github.com/w3c/webextensions/issues/50): Document "browser\_action" and "page\_action" or document "action"… -* [Issue 21](https://github.com/w3c/webextensions/issues/21): How should sidebarAction be considered, since it’s only implemented in two browsers? -* [Issue 13](https://github.com/w3c/webextensions/issues/13): Where do we start for a draft? - * Specifically "Should we contribute WebIDL files for the APIs?" -* [Issue 43](https://github.com/w3c/webextensions/issues/43): Proposal for Manifest v3: Have less restrictive security measures for force-installed extensions -* [Issue 45](https://github.com/w3c/webextensions/issues/45): Participating in TPAC 2021 - + +* [PR 59](https://github.com/w3c/webextensions/pull/59): Add `sidebar_action` to manifest keys +* [Issue 60](https://github.com/w3c/webextensions/issues/60), [PR 61](https://github.com/w3c/webextensions/pull/61): Add the `name` and `short_name` prose + ## Queue (add yourself at the bottom) - -* hard to find Zoom link - + +* Meeting schedule +* [Issue 1](https://github.com/w3c/webextensions/issues/1): What to do with the older CG? +* Krzysztof Modras: is discussion on webextension features in the scope of interest of this WG? For example performance implication of manifest v3 model +* [Issue 30](https://github.com/w3c/webextensions/issues/30): Adding some form of deploy on PR to see the result + ## Attendees (sign yourself in) - -Put a \*\*\* if you prefer this time slot: - -1. Tomislav Jovanovic (Mozilla) \*\*\* -2. Daniel Glazman (Dashlane) \*\*\* + +1. Daniel Glazman (Dashlane) +2. Rob Wu (Mozilla) 3. Oliver Dunk (1Password) -4. Philipp Kewisch (Mozilla) \*\*\* -5. Rob Wu (Mozilla) \*\*\* -6. Timothy Hatcher (Apple) \*\*\* -7. Peter Saint-Andre (Mozilla) \*\*\* -8. Bradley Cushing (Dashlane) \*\*\* -9. Thierry Régagnon (Dashlane) \*\*\* -10. Sam Macbeth (DuckDuckGo) -11. Jon Howard (Easyfundraising) \*\*\* -12. Ellie Epskamp-Hunt (Apple) -13. Nir Nahum (WalkMe) -14. Mélanie Chauvel (Dashlane) -15. Marwan Liani (Dashlane) -16. Shane Caraveo (Mozilla) -17. Todd Schiller (PixieBrix) \*\*\* -18. Pawel Wszola (OceanHero) -19. Simeon Vincent (Google) \*\*\* -20. Mukul Purohit (Microsoft) -21. Sohail Rajdev (Microsoft) -22. Andrew Beyer (1Password) \*\*\* -23. Don Hopkins (Ground Up Software) \*\*\* -24. Jack Works (Sujitech) -25. Richard Worth (Capital One) - +4. Richard Worth (Capital One) +5. Denis Schneider (Dashlane) +6. Mélanie Chauvel (Dashlane) +7. Mukul Purohit (Microsoft) +8. Simeon Vincent (Google) +9. Jesse Trana +10. Andrew Beyer (1Password) +11. Krzysztof Modras (Ghostery) +12. Philipp Kewisch (Mozilla) + ## Meeting notes - -[Issue 50](https://github.com/w3c/webextensions/issues/50): Document "browser\_action" and "page\_action" or document "action"… - -* [timothy] During Mélanie’s first contribution to the manifest format the question of what to do with browser\_action/page\_action/action came up. -* [simeon] Specify overlap between MV2 and MV3 -* [tomislav] Specify common where there are at least 2 implementations -* [glazou] we’re not forced to have 2 compatible implems per feature; we’re supposed to describe the WebExtensions state-of-the-art and we don’t have to be conformant to REC exit criteria and our specs go to WG for that -* [simeon] Example of Firefox’s contentScripts API vs Chrome’s scripting API; similar functionality, different approaches to registering content scripts dynamically. - * [rob] Firefox will deprecate the contentScrips namespace in favor of the scripting namespace; we can collaborate in this group to design a cross-browser compatible API. - * [simeon] In the future, it might be nice if we could get to the point where browsers support multiple versions of APIs so that we don't depend on the whole ecosystem agreeing on one canonical version at a time. - -[Issue 21](https://github.com/w3c/webextensions/issues/21): How should sidebarAction be considered, since it’s only implemented in two browsers? - -* [timothy] Opera and Firefox have implementations, are two enough to spec the API? -* [simeon] No objections to speccing it, except it is not in the overlap of MV2+MV3. -* [Mélanie/Timothy] sidebarAction is not being actively removed in mv3, therefore it is a continuation. -* [glazou] Consider showing the result of individual implementations for the browser. Add this to the templates for each entry in the manifest. This should help a lot for the future. - * For example as shown at [wpt.fyi](https://wpt.fyi) - * [simeon] Positive towards a common set of tests - * [philipp] There is also an effort in the [browser-compat-data](https://github.com/mdn/browser-compat-data) project that is used to e.g. render compatibility tables on MDN. - * Result: glazou will file an issue to track this further. -* [Simeon] We don’t need to conform to other specs, if we wanted to add visual indicators we should. -* Consensus: We should proceed by specifying it, there are 2 implementations (despite it not being a part of MV3 right now). -* Mélanie will look into documenting the manifest property, the issue will remain open for additional work. - -[Issue 13](https://github.com/w3c/webextensions/issues/13): Where do we start for a draft? - -* [from issue] "Should we contribute WebIDL files for the APIs?" -* [simeon] Sounds like a good idea. Talked to a related team, integrating definitions into spec for scripting. There is a split in how well that works. Complex or optional values are difficult to write in webidl, especially in a deeply nested part of the manifest. Team was looking to extend webidl, infrastructure folks were not very fond of that idea. -* [timothy] webidl would be more for the javascript side of things. Using JSON Schema for the manifest. -* [simeon] How are browsers doing this? Parsing the html file and plug that into their systems? -* [tomislav] Use webidl as the basis, it will be adjusted when used in the browsers. The files won’t be used wholesale. -* [timothy] Same for webkit. Apple adds attributes and annotations. More of a copy/modify scenario. -* [don] (referencing Simeon’s earlier comment) Is this similar to how typescript defines the structure? - * [simeon] Yes, there are likely similar capabilities in webidl -* [tomislav] In Firefox we are currently not using webidl, but JSON schemas as originally used in Chromium. Webidl is less descriptive, we would lose some specifity that we would still need to implement. If we go with webidl in the spec, we wouldn’t be able to cover all of the cases. We’re transitioning to webidl for ServiceWorkers, but we need JSON Schema for other validations. -* [timothy] Maybe a combination of both. Use webidl for the API level, for the individual dictionaries (e.g. tab query) we specify a separate json schema. -* [philipp] do we need both? -* [Mélanie] Webidl would be distributed with the spec? - * [simeon] This is what the webapp CG does, they publish separate schema files to jsons-schemas.org - * [Mélanie] JSON Schema helpful when using external tools, e.g. mocking all API methods. - * [timothy] If we can specify everything in json schema that would be great, we could generate - * [simeon] We can’t; JSON schemas does not support return types. - * [todd] json schema is only the data, everything further would be swagger or (opensomething?). - * [don] Can we translate the other way (webidl -> json schema) - * [timothy] webidl can be translated into anything, using a tool. Could generate a json schema shell. - * [simeon] Chrome generates extension docs from IDLs and JSON schemas -* [timothy] Moving discussion to the issue seems like the next logical step. -* [simeon] What is the goal of having webidl or json schema? - * [simeon] Spec contained idl, this was consumed in the browsers, that doesn’t seem to be the case. - * [timothy] There is a process to import these files, Apple adds more attributes. - * [tomislav] Easier to copy something from the spec and adapt as needed - * [rob] what type of info is in the apple webidl files? Is it a fundamentally lacking feature in WebIDL? - * [timothy] very specific stuff, e.g. was it implemented as NSObject. Webidl has its limits here. - * [timothy] If we separate the object definitions as Mélanie mentioned, this would be good for tooling. Unclear if we can specify everything. - * [Mukul] How does WebIdl handle variations in APIs and types by browser implementations? - * [timothy] It gets complicated when options are re-arranged, problems can come up if there is a lot of churn. Mv2 and mv3 are mostly compatible to each other, this is easily done in webidl by new scripting namespaces. - * [don] Does webidl have a generic annotation mechanism to decide when to use what? - * [timothy] There are generic attributes that could be used. - * [don] We could make that up, or use something someone has done -* [Oliver] Original intention, browser vendors are most implemented in putting together the draft. How can we distribute the workload, 1Password is very interested in contributing as well. - * [timothy] All for community contributions. See how we can split this up - * Digging into the sub-levels of the manifest - * [oliver] Sounds like spec is the main focus, how can we allocate this? - * [timothy] In previous meetings we agreed that the manifest was a good starting point. - * [glazou] To contribute, make a proposal to get it accepted by the group. It had to be kickstarted for others to contribute, so we can start contributing. Editors (and in part Chairs) will be able to help getting PRs reviewed and accepted. - -[Issue 43](https://github.com/w3c/webextensions/issues/43): Proposal for Manifest v3: Have less restrictive security measures for force-installed extensions - -* [timothy] In the issue the OP asks for relaxed restrictions for enterprise-installed extensions. -* [simeon] Do other browsers have the concept of force installation/side loading. What does Firefox do? -* [tomislav] We have something for linux distros and enterprise. This doesn’t seem like an issue that is in scope for this group. -* [nir] As an extension developer, we are counting on having the same API on all the browsers. If any browser would choose their own way to tackle this. Would be great to have a single codebase. If it is detected that the extension was not installed from the store but from central IT, in that case certain APIs would still be enabled. Example: blocking webRequest. - * [tomislav] Counter-example, we don’t distinguish between enterprise or not. We have blocking webRequest in both mv2 and mv3. - * [glazou] This is explicitly out of scope in the charter. Quote: Deployment mechanisms. We should not be discussing this. - * [nir] Not talking about the deployment, more about the APIs. - * [timothy] We could only describe the APIs, it would be up to the browser vendors to decide how to expose them. - * [rob] What is the goal behind filing the issue? - * [nir] Deprecations in mv3 are affecting vendors and customers. Enterprise use cases are affected, if we can accommodate this in the group everyone would win. Enterprises have higher requirements, browser vendors want enterprises to use the browsers. Restrictions make sense for end-users, this makes less sense for enterprise where there is a security team. - * [rob] So you’re asking for the spec to describe privileged APIs that are disabled/enabled in certain cases, is that what you (Nir) are asking? - * [Nir] Yes - * [philipp] We talked about browser compat data, can we just make this a special case of that (e.g. supported: no, caveat it is supported in the enterprise case) - * [simeon] In the context of this group we could consider making it easier to feature-detect APIs - * [timothy] De facto standard is to check whether the API is present. - * [tomislav] Thumbs up - -[Issue 45](https://github.com/w3c/webextensions/issues/45): Participating in TPAC 2021 - -* [simeon] Please add ideas to this issue to help us organize outreach for TPAC -* No time left, deferred to the next meeting. - -(queue) hard to find Zoom link - -* Zoom link is on the w3c calendar and visible if you’re logged in. -* Zoom link is also in the link in the “Call-in details” link at the top. -* Link https://www.w3.org/events/meetings/7fc25ca5-a50c-498c-82e5-f48fc96e1637 in github somewhere so people can join easier. - -The next meeting will be on [Thursday, August 19th, 11 PM PDT (Friday, August 20th, 6 AM UTC)](https://everytimezone.com/?t=60f8b500,708). After that meeting we will evaluate whether we need to adjust the current cadence. + +[PR 59](https://github.com/w3c/webextensions/pull/59): Add `sidebar_action` to manifest keys + +* [Mélanie] Summary : sidebar action PR introduces a new key to the manifest +* [Simeon] PR merged, thanks for adding this + +[Issue 60](https://github.com/w3c/webextensions/issues/60), [PR 61](https://github.com/w3c/webextensions/pull/61): Add the `name` and `short_name` prose + +* [Simeon] Submitted by Timothy, this PR adds more meaningful descriptions to these properties. Also raises a couple questions. +* [Simeon] Chrome and Firefox take strings of arbitrary length, but both browsers' extension stores restrict the name to 45 chars. Should we capture that in the spec? Inclined to capture that as ecosystem is more than the browser (i.e. distribution channel) +* [Mélanie] Maybe good idea to address the limitation +* [Daniel] The spec does not include restriction but web-stores could restrict the length. This can be indicated in the document +* [Rob] If anything, we could specify the minimum supported length across vendors. +* [Daniel] If restriction is specified then browsers would need to enforce it. +* [Rob] Are you referring to short\_name only? +* [Simeon] No, name, shortname, icons, or any other property that has limitations imposed by parts of the ecosystem beyond the browser itself. +* [Simeon] The text that Timothy provided is a big improvement over the current placeholder text, but it does raise questions about the scope of what we're specifying. We can use another discussion thread. We should have more folks for consensus +* [Simeon] In the same PR, the concept of localization is introduced, we should capture that in another issue. Will file a new issue about this topic. Contributions welcome; otherwise I will eventually submit PR. + +[Issue 53](https://github.com/w3c/webextensions/issues/53): Decompose manifest.json spec work into action items members can PR + +* [Simeon] There are now few entries in the document for manifest keys. Issue 53 proposes that we decompose manifest json into actual actionable work. We can create the issues for each item or just do PRs. +* [Daniel] Simpler the better. PRs only is fine +* [Rob] We can add issues if identified else PRs are good +* [Simeon] Consensus is to tackle individual properties as PRs. If you're interested in helping, feel free to open a new PR. + +Administrativia + +* [Rob] What is the process to select issues for this meeting? +* [Simeon] Selecting the Agenda items that support the goal identified in the charter: specify a common core. Thought process was to focus on pursuing the common core in agenda items, then open discussion to topics of interest via the queue. Open to improving the process. +* [Mélanie] Can we add agenda items? +* [Rob] Ping me for items on the Matrix chat. This time we have plenty of time to discuss any other topic. +* [Simeon] For the most part the doc is open, but it is locked temporarily before publishing +* [Daniel] Could we improve the manifest spec and define the types of property +* [Rob] We touched upon this Web IDL vs JSON in one of the previous meetings. +* [Daniel] Manifest is JSON, can we define the types of the values. How are we going to define the types e.g. CSS property +* [Simeon] Inclination to follow the format used by App Manifest. Will add the examples to matrix. + * E.g. https://www.w3.org/TR/appmanifest/#name-member + * https://browserext.github.io/browserext/#list-of-keys +* [Mélanie] Research for specs that could be used as inspirations to define the manifest json document. Inclined to do research across multiple resources. +* [Simeon] Can you provide some examples +* [Mélanie] Browser extension community group spec +* [Simeon] I recall that it Lists all the properties as table +* [Simeon] [WebApp manifest spec](https://www.w3.org/TR/appmanifest/) vs [Browser Extension community spec](https://browserext.github.io/browserext/) are using different ways. WebApp manifest feels like JS specification whereas the other one is simple and specifies as an array of objects. I am hesitant to pick one. We could consider re-using the definition by linking to the other spec. Would prefer to not re-write the internals of algorithms that are already specified elsewhere +* [Daniel] Web App manifest is a working draft. We should not add links to resources that can go away. +* [Simeon] Makes sense. We should only reference published specifications from other groups. +* [Daniel] Agree to work on general things first. +* [Philipp] What are the next set of things we should work on? +* [Simeon] Follows naturally from work on manifest; Localization is an example. Do suggest if you have one. +* [Philipp] I was thinking about security and that leads towards content-script. +* [Simeon] Agree that CS seems like a good area to begin exploring. Volunteers welcome :) + +Future meetings in this time slot + +* [Rob] At the end of last week’s meeting we already mentioned the possibility of reducing the frequency of meetings in this time slot, since the other time slot has more participation. Any objections against doing so? +* [Simeon] Hesitant as this approach is more inclusive. But there is a practical benefit to having single time, so I reluctantly support consolidating on a single time slot. +* [Mélanie] I recall we discussed changing the cadence a few meetings ago. +* [Mukul] We discussed to change cadence of this slot only +* [Simeon] I do remember discussing changing the cadence of the meeting at this time. Probably best to discuss in an issue. +* [Rob] Outside of this time we can use github-issue to discuss. Should we open an issue? +* [Daniel] Chairs can call for consensus and make a decision +* [Simeon] Agreed. We should discuss in an issue and put it to a vote next meeting + +[Issue 1](https://github.com/w3c/webextensions/issues/1): What to do with the older CG? + +* [Simeon] Florian was not able to attend this call. We wanted to discuss the future of the resources in older CG. Maybe we can take the next step and drive to a conclusion. As an example, raise and submit the PR in the previous CG. +* [Daniel] Prev CG is officially extinct so creating a PR is not valid. +* [Simeon] Can we just have a PR in older CG that calls out the state of the CG i.e. it is retired and update the readme to call out the same. Followup with W3C staff to officially mark the group as inactive; update the blog to redirect to CG. +* [Mélanie] Should we create a new issue or use this issue number 1. +* [Simeon] We can use issue 1 unless the text is unclear. +* [Rob] Can we get Florian over any other channel and conclude the same. +* [Simeon] I will follow up with Florian on issue 1. + +Features that are in scope in this CG + +* [Krzysztof Modras] Is discussion on WebExtension features in the scope of interest of this WG? For example performance implication of Manifest V3 model +* [Krzysztof] Working for Ghostery. Want to discuss the perf implication of DNR and Service workers. Is this discussion in scope? +* [Rob] Yes, in the scope. Are you specifically referring to Service Workers? +* [Krzysztof] With Service Workers we need to instantiate state & objects on-demand. My first Q is that should we discuss in this meeting or should use another channel or issue +* [Rob] This topic has been raised before at https://github.com/w3c/webextensions/issues/51 and [open issues with "topic:service worker" label](https://github.com/w3c/webextensions/issues?q=is%3Aissue+is%3Aopen+label%3A%22topic%3A+service+worker%22) +* [Simeon] Agree that this is in the scope. We are talking about the future of the Browser Extension Model. As part of the group we are trying to capture the common parts so that the developers can target their work for multiple browsers. Feel free to discuss service-worker limitations and challenges in this group. I agree there are issues with SW and the Chrome team is interested in the use-cases and points of failures. There has been a lot of MV3 feedback, but much of it is lot of feedback and it would be useful to get feedback around service-worker model is not working currently, and we are trying to get to a solution that can work for browsers and developers +* [Krzysztof] Happy to hear that. There are some issues with our current implementation interacting with service-workers. +* [Daniel] I believe that the Side effects are well known to all and including the google team. The 5 minute limit is harsh. I am surprised by your reaction. +* [Simeon] The 5 minute cutoff is a sharp edge and the Chrome team wants to make it less dangerous. Probably not surprising that this has been a repeated topic of discussion. Interested in exploring ways to provide more reliable behavior v/s providing persistence. As an example one of suggestion is to provide a way for extensions to request service worker unload when it can be safely terminated +* [Daniel] Extension authors are trying multiple ways to increase (or workaround) the time limit as it is expensive to reload the state. Not everything can be stored in public storage as it may be security / privacy specific. Think of user impact - _seconds _of wait. +* [Simeon] Has heard some of them, in certain cases caused by front loading more work than necessary in an event-based model. In some cases re-architecture of the extension is necessary. Current implementations have been optimized with long-lived threads available. +* [Daniel] Optimized is not the correct term; have used what was available. WebExtension vendors used persistence of the background and in-memory storage because that’s what was available in v2 model. +* [Rob] Suggest to break this discussion in the interest of time. + +[Issue 30](https://github.com/w3c/webextensions/issues/30): Adding some form of deploy on PR to see the result + +* [Mélanie] Would be nice to get a preview. +* [Rob] We discussed this earlier to create the functionality to submit the PR - https://github.com/w3c/webextensions/issues/30 +* [Mukul] I would try to get the github actions work this week + +The next meeting will be on [Thursday, September 2nd, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=61301400,384). + \ No newline at end of file From f85a068f4b653b40180494c9409c7eaafdfe186c Mon Sep 17 00:00:00 2001 From: mpurohit Date: Fri, 20 Aug 2021 15:16:19 +0530 Subject: [PATCH 3/6] Few addional white-spaces removed --- _minutes/2021-08-19-wecg.md | 57 ++++++++++++++++++------------------- 1 file changed, 28 insertions(+), 29 deletions(-) diff --git a/_minutes/2021-08-19-wecg.md b/_minutes/2021-08-19-wecg.md index a3278953..41db312d 100644 --- a/_minutes/2021-08-19-wecg.md +++ b/_minutes/2021-08-19-wecg.md @@ -1,28 +1,28 @@ # WECG Meetings 2021, Public Notes—Aug 19, 2021 - + * Chair: Simeon Vincent * Scribes: Mukul Purohit - + Time: 11 PM PDT = https://everytimezone.com/?t=611d9f00,708 - + Call-in details: https://www.w3.org/events/meetings/7fc25ca5-a50c-498c-82e5-f48fc96e1637/20210805T150000 - + Zoom issues? ping @robwu (Rob Wu, Mozilla) in [chat](https://github.com/w3c/webextensions/blob/main/CONTRIBUTING.md#joining-chat) - + ## Agenda: [github issues](https://github.com/w3c/webextensions/issues) - + * [PR 59](https://github.com/w3c/webextensions/pull/59): Add `sidebar_action` to manifest keys * [Issue 60](https://github.com/w3c/webextensions/issues/60), [PR 61](https://github.com/w3c/webextensions/pull/61): Add the `name` and `short_name` prose - + ## Queue (add yourself at the bottom) - + * Meeting schedule * [Issue 1](https://github.com/w3c/webextensions/issues/1): What to do with the older CG? * Krzysztof Modras: is discussion on webextension features in the scope of interest of this WG? For example performance implication of manifest v3 model * [Issue 30](https://github.com/w3c/webextensions/issues/30): Adding some form of deploy on PR to see the result - + ## Attendees (sign yourself in) - + 1. Daniel Glazman (Dashlane) 2. Rob Wu (Mozilla) 3. Oliver Dunk (1Password) @@ -35,16 +35,16 @@ Zoom issues? ping @robwu (Rob Wu, Mozilla) in [chat](https://github.com/w3c/web 10. Andrew Beyer (1Password) 11. Krzysztof Modras (Ghostery) 12. Philipp Kewisch (Mozilla) - + ## Meeting notes - + [PR 59](https://github.com/w3c/webextensions/pull/59): Add `sidebar_action` to manifest keys - + * [Mélanie] Summary : sidebar action PR introduces a new key to the manifest * [Simeon] PR merged, thanks for adding this - + [Issue 60](https://github.com/w3c/webextensions/issues/60), [PR 61](https://github.com/w3c/webextensions/pull/61): Add the `name` and `short_name` prose - + * [Simeon] Submitted by Timothy, this PR adds more meaningful descriptions to these properties. Also raises a couple questions. * [Simeon] Chrome and Firefox take strings of arbitrary length, but both browsers' extension stores restrict the name to 45 chars. Should we capture that in the spec? Inclined to capture that as ecosystem is more than the browser (i.e. distribution channel) * [Mélanie] Maybe good idea to address the limitation @@ -55,16 +55,16 @@ Zoom issues? ping @robwu (Rob Wu, Mozilla) in [chat](https://github.com/w3c/web * [Simeon] No, name, shortname, icons, or any other property that has limitations imposed by parts of the ecosystem beyond the browser itself. * [Simeon] The text that Timothy provided is a big improvement over the current placeholder text, but it does raise questions about the scope of what we're specifying. We can use another discussion thread. We should have more folks for consensus * [Simeon] In the same PR, the concept of localization is introduced, we should capture that in another issue. Will file a new issue about this topic. Contributions welcome; otherwise I will eventually submit PR. - + [Issue 53](https://github.com/w3c/webextensions/issues/53): Decompose manifest.json spec work into action items members can PR - + * [Simeon] There are now few entries in the document for manifest keys. Issue 53 proposes that we decompose manifest json into actual actionable work. We can create the issues for each item or just do PRs. * [Daniel] Simpler the better. PRs only is fine * [Rob] We can add issues if identified else PRs are good * [Simeon] Consensus is to tackle individual properties as PRs. If you're interested in helping, feel free to open a new PR. - + Administrativia - + * [Rob] What is the process to select issues for this meeting? * [Simeon] Selecting the Agenda items that support the goal identified in the charter: specify a common core. Thought process was to focus on pursuing the common core in agenda items, then open discussion to topics of interest via the queue. Open to improving the process. * [Mélanie] Can we add agenda items? @@ -88,9 +88,9 @@ Administrativia * [Simeon] Follows naturally from work on manifest; Localization is an example. Do suggest if you have one. * [Philipp] I was thinking about security and that leads towards content-script. * [Simeon] Agree that CS seems like a good area to begin exploring. Volunteers welcome :) - + Future meetings in this time slot - + * [Rob] At the end of last week’s meeting we already mentioned the possibility of reducing the frequency of meetings in this time slot, since the other time slot has more participation. Any objections against doing so? * [Simeon] Hesitant as this approach is more inclusive. But there is a practical benefit to having single time, so I reluctantly support consolidating on a single time slot. * [Mélanie] I recall we discussed changing the cadence a few meetings ago. @@ -99,9 +99,9 @@ Future meetings in this time slot * [Rob] Outside of this time we can use github-issue to discuss. Should we open an issue? * [Daniel] Chairs can call for consensus and make a decision * [Simeon] Agreed. We should discuss in an issue and put it to a vote next meeting - + [Issue 1](https://github.com/w3c/webextensions/issues/1): What to do with the older CG? - + * [Simeon] Florian was not able to attend this call. We wanted to discuss the future of the resources in older CG. Maybe we can take the next step and drive to a conclusion. As an example, raise and submit the PR in the previous CG. * [Daniel] Prev CG is officially extinct so creating a PR is not valid. * [Simeon] Can we just have a PR in older CG that calls out the state of the CG i.e. it is retired and update the readme to call out the same. Followup with W3C staff to officially mark the group as inactive; update the blog to redirect to CG. @@ -109,9 +109,9 @@ Future meetings in this time slot * [Simeon] We can use issue 1 unless the text is unclear. * [Rob] Can we get Florian over any other channel and conclude the same. * [Simeon] I will follow up with Florian on issue 1. - + Features that are in scope in this CG - + * [Krzysztof Modras] Is discussion on WebExtension features in the scope of interest of this WG? For example performance implication of Manifest V3 model * [Krzysztof] Working for Ghostery. Want to discuss the perf implication of DNR and Service workers. Is this discussion in scope? * [Rob] Yes, in the scope. Are you specifically referring to Service Workers? @@ -125,12 +125,11 @@ Features that are in scope in this CG * [Simeon] Has heard some of them, in certain cases caused by front loading more work than necessary in an event-based model. In some cases re-architecture of the extension is necessary. Current implementations have been optimized with long-lived threads available. * [Daniel] Optimized is not the correct term; have used what was available. WebExtension vendors used persistence of the background and in-memory storage because that’s what was available in v2 model. * [Rob] Suggest to break this discussion in the interest of time. - + [Issue 30](https://github.com/w3c/webextensions/issues/30): Adding some form of deploy on PR to see the result - + * [Mélanie] Would be nice to get a preview. * [Rob] We discussed this earlier to create the functionality to submit the PR - https://github.com/w3c/webextensions/issues/30 * [Mukul] I would try to get the github actions work this week -The next meeting will be on [Thursday, September 2nd, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=61301400,384). - \ No newline at end of file +The next meeting will be on [Thursday, September 2nd, 8 AM PDT (3 PM UTC)](https://everytimezone.com/?t=61301400,384). \ No newline at end of file From 79ef6be2b08ac906dde068a8dc463fcba970a74d Mon Sep 17 00:00:00 2001 From: mpurohit Date: Mon, 23 Aug 2021 19:26:28 +0530 Subject: [PATCH 4/6] Add readme update and one additional nit --- _minutes/2021-08-19-wecg.md | 2 +- _minutes/README.md | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/_minutes/2021-08-19-wecg.md b/_minutes/2021-08-19-wecg.md index 41db312d..f96ab4a9 100644 --- a/_minutes/2021-08-19-wecg.md +++ b/_minutes/2021-08-19-wecg.md @@ -1,4 +1,4 @@ -# WECG Meetings 2021, Public Notes—Aug 19, 2021 +# WECG Meetings 2021, Public Notes, Aug 19, 2021 * Chair: Simeon Vincent * Scribes: Mukul Purohit diff --git a/_minutes/README.md b/_minutes/README.md index 93736b28..38ae2669 100644 --- a/_minutes/README.md +++ b/_minutes/README.md @@ -14,11 +14,12 @@ After the end of each meeting, meeting notes are published here. ## Upcoming meetings -* 2021-08-19 at 11 PM PDT = https://everytimezone.com/?t=611d9f00,708 * 2021-09-02 at 8 AM PDT = https://everytimezone.com/?t=61301400,384 +* 2021-08-16 at 11 PM PDT = https://everytimezone.com/?t=611d9f00,708 ## Past meetings +* 2021-08-19 ([minutes](2021-08-19-wecg.md)) * 2021-08-05 ([minutes](2021-08-05-wecg.md)) * 2021-07-22 ([minutes](2021-07-22-wecg.md)) * 2021-07-08 ([minutes](2021-07-08-wecg.md)) From f1828ec7283764216d4759c830964bad3af1a7d4 Mon Sep 17 00:00:00 2001 From: mpurohit Date: Thu, 26 Aug 2021 18:35:39 +0530 Subject: [PATCH 5/6] Readme update - nit --- _minutes/README.md | 1 - 1 file changed, 1 deletion(-) diff --git a/_minutes/README.md b/_minutes/README.md index 38ae2669..8aef5d11 100644 --- a/_minutes/README.md +++ b/_minutes/README.md @@ -15,7 +15,6 @@ After the end of each meeting, meeting notes are published here. ## Upcoming meetings * 2021-09-02 at 8 AM PDT = https://everytimezone.com/?t=61301400,384 -* 2021-08-16 at 11 PM PDT = https://everytimezone.com/?t=611d9f00,708 ## Past meetings From 0e6698f53748e60416d0c88ab601534643a09623 Mon Sep 17 00:00:00 2001 From: Simeon Vincent Date: Thu, 26 Aug 2021 10:08:18 -0700 Subject: [PATCH 6/6] Simplify document title --- _minutes/2021-08-19-wecg.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_minutes/2021-08-19-wecg.md b/_minutes/2021-08-19-wecg.md index f96ab4a9..9f39da6f 100644 --- a/_minutes/2021-08-19-wecg.md +++ b/_minutes/2021-08-19-wecg.md @@ -1,4 +1,4 @@ -# WECG Meetings 2021, Public Notes, Aug 19, 2021 +# WECG Meetings 2021, Public Notes, Aug 19 * Chair: Simeon Vincent * Scribes: Mukul Purohit