Publish minutes of 2022-01-06 meeting

_minutes/2022-01-06-wecg.md

@@ -0,0 +1,152 @@
+# WECG Meetings 2021, Public Notes, Jan 6
+
+ * Chair: Simeon Vincent
+ * Scribes: Rob Wu
+
+Time: 8 AM PST = https://everytimezone.com/?t=61d63100,3c0
+Call-in details: [WebExtensions CG, 6th January 2022](https://www.w3.org/events/meetings/d7bbce8f-549f-46ea-b440-ea6902f8707c/20220106T080000)
+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.
+
+ * **Meta-discussion [15 min]**
+   * Simeon to share some thoughts on how we run these meetings, changs to maximize our time together. [5 min intro, 10 min discussion]
+ * **Carry-over from previous meetings [15 min]**
+   * Simeon: Quickly touch on [5 min]
+   * Carlos: move browser specific settings to browser_specific_settings key (https://github.com/w3c/webextensions/issues/115) [10 min]
+ * **Other new issues [1 min]**
+   * None created since our last meeting [1 min]
+ * **Open discussion queue (add yourself at the bottom) [29 min]**
+   * Oliver (1Password): We're in the early stages of creating a proposal for a WebExtension API to access the keychain. If this would be useful to you, please reach out so we can collaborate.
+   * <add yourself - topic and name>
+ * **Meeting wrap up [5 min]**
+   * Brief review of the meeting and next steps [3 min]
+   * Next meeting [2 min]
+
+
+## Attendees (sign yourself in)
+
+ 1. Rob Wu (Mozilla)
+ 2. Nick McGuire (1Password)
+ 3. Krzysztof Modras (Ghostery)
+ 4. Philipp Claßen (Ghostery)
+ 5. Alexei (Privacy Badger)
+ 6. Oliver Dunk (1Password)
+ 7. Simeon Vincent (Google)
+ 8. Mukul Purohit (Microsoft)
+ 9. Nir Nahum (WalkMe)
+ 10. Jack Works (Sujitech)
+ 11. Timothy Hatcher (Apple)
+
+
+## Meeting notes
+
+Meta-discussion: thoughts on running this meeting
+
+ * [simeon] Prepared message, pasted below:
+ * [simeon] For the scribes, I'm going off of some notes I've prepped. I'm pasting them into the doc now so you don't have to worry about trying to keep up.
+
+   I wanted to talk a bit about how we conduct these meetings. I'm going to be soapboxing for a bit here, so bear with me.
+
+   Since our last session, I have been thinking about how we can make our meetings more productive
+
+   Chartered Scope of Work
+   - An extensions model
+   - A permissions model
+   - WebExtensions APIs
+   - A packaging format
+   - Native Messaging
+
+   Chartered deliverables
+   - Specifications
+       - WebExtensions
+       - (possibly others?)
+   - Non-Normative Reports
+   - Test Suites and Other Software
+
+   We can and should consider other topics related to WebExtensions, but we should not do so to the exclusion of our declared reason for existence. I'm currently thinking we should try to keep at least half our meeting time focused on our work and deliverables.
+
+   In an effort to try to keep us on track and productive, I want to try a couple changes to our process.
+
+   1) The meeting agenda. Timothy and I plan to prepare the agenda in this doc give 2+ days before the meeting in order to give group members time to prepare.
+
+   2) Time box topics. I've annotated topics with maximum time for a given topic before we have to move on.
+
+   3) Topic structure. To maximize our sync time together, I want to try to keep our topics objective focused. Topics should have a goal.
+       To that end, my goal here is to share my tentative plan on how I plan to conduct myself as co-chair and to get initial feedback on the direction I'm planning to steer us.
+
+   4) Stewarding projects. In my personal experience projects that don't have someone driving them often suffer from lack of clear objectives and follow-through. To that end, I'd like to explore the possibility of having members steward well defined chunks of work.
+
+   This afternoon I plan to create an issue to discuss this in more detail. If you're interested in helping guide a scoped bit of work, please comment on that issue. Otherwise, I'll use it as a launching point for trying to organize my own contributions.
+
+   Aaand that's it. I know I just threw a lot at you all, but if I may I'd like to get a quick show of emoji reactions to see how folks feel, then open it up to discussion.
+ * [mukul] Does the 2-day-in-advance proposal cover community topics too, or just the chairs?
+   * [simeon] My intent was just to cover the chairs. Other participants can add their comments at any time.
+ * [nir] Some topics can be covered offline. It would be more efficient if browser participants go over issues and respond to them.
+   * [simeon] Agree. Part of why I mentioned about "stewarding projects" was a desire to improve my own engagement with our GH issues.
+ * [krysztof] How do we show progress on Github issues? E.g. tagging or getting feedback from vendors.
+   * [simeon] Part of what you touched on sounds like making better use of tags to organize and coordinate our work. Please
+ * [alexei] Concerned about ignoring the elephant in the room. If the MV3 deadline wasn't burning down the house of extensions, this would be fine. But MV3 exists.
+ * [simeon] Agree that we should continue discussing Manifest V3 issues, but the problem is that this CG is chartered to work on a common base that spans manifest versions (e.g. manifest structure, localization, content scripts, etc.). The charter is meant to guide what we do and the chairs are responsible for pursuing that work. If we want to change our focus, it may be best to discuss modifying the charter. [_Notes that we are over time and should follow up on this topic later._]
+ * [alexei] DOM issues are just some of the issues with MV3. Plus, what Google does also affects Firefox and Safari. If we are here to help the extensions community, we need to focus on addressing MV3.
+ * [jack] Question: Chrome is going to retire MV2 in about a year. Is there still a value in specifying MV2?
+   * [simeon] A lot of what we've covered so far is independent of the manifest version. We shouldn't be specifying MV2, but rather the common parts of the platform across all implementations.
+ * [rob] There are a bunch of proposals on how this meeting is run. Things I like are more focus on the productivity of our meetings. Time boxing, guidance in the meeting are tools to the objective of keeping the meetings on track. That said, the way you've proposed to address that could be interpreted as chairs forcing a specific, biased direction. You were going to create a proposal. Let's discuss that in an issue before enforcing it now.
+ * [rob] One of the items you mentioned was shepherding projects. Let's see if there's interest in that area before pushing it too hard. Being conscious of the time during synchronous meetings would be good to do regardless.
+ * [mukul] Should provide the community with the opportunity to influence topics and time. Perhaps we could create an agenda issue and aim to resolve it at least 2 days before.
+ * [simeon] Hadn't considered that, but would like to explore it more. Could you create an issue?
+
+DOM-based use cases (part of [issue 120](https://github.com/w3c/webextensions/issues/120))
+
+ * [simeon] Last meeting I asked Devlin to attend in order to discuss a proposal we're preparing to address some background DOM-based use cases in Manifest V3. Unfortunately we didn't spend much time discussing that. To that end, the summary is that we are offering a counter-proposal/augmentation to the Limited Event pages proposal ([issue 134](https://github.com/w3c/webextensions/issues/134)). We're trying to modify the contract to make it more clear to developers when and how the background page can run.
+ * [alexei] Why does Mozilla's limited event page proposal not work for Chrome?
+ * [simeon] As I understand the limited event page proposal, one of the core assumptions is that the background page will be there as long as the extension does work. That's not a guarantee that Chrome can continue to make given our engineering objectives.
+ * [rob] In the design of limited event pages, the background will be around as long as possible. If there are pressures outside the browser's control, the page may be terminated.
+ * [krzystof] Making Google's rationale public would really help with your stated goal of transparency. As is, we have to guess the real, unstated reasons.
+ * [alexei] Didn't get an answer: why are Limited event pages from Mozilla not enough for Google?
+ * [simeon] _(trying to answer but can't find the words)_. Rob, we've discussed this a bit; could you try to reframe Chrome's concerns as you understand them?
+ * [rob] Google wants (service) worker-first extensions, and in limited event pages the background would be on the main thread.
+ * [simeon] Chrome is also targeting constrained environments where, despite our fundamentally multi-process model, we need to be more aggressive about limiting concurrent processes.
+ * [alexei] Doesn't need an answer right now, but it would be great to get an answer, possibly on an issue later.
+
+[Issue 115](https://github.com/w3c/webextensions/issues/115): Proposal: move browser specific settings to browser_specific_settings
+
+ * [simeon] Without Carlos here I'm not sure what there is left to discuss. I suggest we shelve it for the next meeting.
+
+Other new issues
+
+ * [simeon] There haven't been new issues filed since the last meeting.
+ * [rob] Lack of new issues does not mean that we don't have issues that we haven't discussed. There are still issues that we need to discuss, e.g. [issue 139](https://github.com/w3c/webextensions/issues/139) about the lack of APIs to support user script managers.
+
+Password manager API
+
+ * [oliver] Oliver (1Password): We're in the early stages of creating a proposal for a WebExtension API to access the keychain. If this would be useful to you, please reach out so we can collaborate.
+ * [oliver] Thinking about webextensions APIs that would give us access to biometrics and other secure operating systems capabilities. If that sounds interesting to anyone else here, reach out on Matrix or Twitter to discuss/collaborate on a proposal
+ * [timothy] Interested on Apple's behalf.
+ * [jack] The ability to store data in an encrypted store sounds useful.
+ * [rob] Do you want to post on Github first, or collaborate with stakeholders to refine the proposal first?
+ * [oliver] Haven't thought about that, was polling for interests at this point. Looking forward to chats on Matrix.
+ * [simeon] Very interested to see what you have in mind.
+ * [oliver] _(shared on Matrix after the meeting)_ “Proposal: browser.secureStorage API” https://docs.google.com/document/d/11ERMp8ErCF2_l-V1YSE73UKKZeGoBC3QeMUoCTACElc/edit
+
+[Issue 139](https://github.com/w3c/webextensions/issues/139): Do not outlaw dynamic code
+
+ * [rob] Let's talk about this.
+ * [simeon] In broad strokes, to enable user script managers we'd like to offer a secondary opt-in similar to how Chrome extensions can receive access to file:-URLs, and offer user script management capabilities on the scripting API.
+ * [nir] From the enterprise use case, would be nice to be able to enable this flag through enterprise policies, for specific extensions instead of a global flag.
+ * [simeon] From the extension design POV, an important consideration is that user script capabilities are not always available, and extensions need to account for this, e.g. show the user how to opt in.
+ * [simeon] No design doc for user scripts yet. Planning to land the feature before Chrome's MV2 deprecation, but don't have anything more concrete to share at the moment.
+ * [simeon] Sounds like a reasonable request for managed environments. Big concern from our POV is that arbitrary code execution is a dangerous capability that most Chrome users don't understand. We want to offer this capability without putting most Chrome users at risk. Other browsers focusing on power users Other browsers focusing on power users may take a different approach to enable this capability.
+ * [krysztof] Having multiple layers of permissions / opts-in can cause confusion and cause users to incorrectly believe that they're protected. E.g. use case of content blocking extension: if a user fails to opt-in at one step, the user thinks that they're protected against tracking but are not, which gives them a false sense of security.
+
+[Issue 12](https://github.com/w3c/webextensions/issues/12): allow to retrieve a frameID from an <iframe> element
+
+ * [rob] Mozilla has landed `runtime.getFrameId` in Firefox 96.
+ * [timothy] Interested in implementing this in Safari, what's the signature?
+   * [rob] `browser.runtime.getFrameId(target: WindowProxy | HTMLIFrameElement): number` https://github.com/w3c/webextensions/issues/12#issuecomment-1005164103
+ * [simeon] We have [crbug.com/1256872](https://crbug.com/1256872) for this. (Thanks for the link, Rob!)
+
+The next meeting will be on [Thursday, January 20th, 8 AM PST (4 PM UTC)](https://everytimezone.com/?t=61e8a600,3c0).

_minutes/README.md

@@ -10,11 +10,12 @@ After the end of each meeting, meeting notes are published here.
 
 ## Upcoming meetings
 
-* 2022-01-06 at 8 AM PST = https://everytimezone.com/?t=61d63100,3c0
 - 2022-01-20 at 8 AM PST = https://everytimezone.com/?t=61e8a600,3c0
+* 2022-02-03 at 8 AM PST = https://everytimezone.com/?t=61fb1b00,3c0
 
 ## Past meetings
 
+* 2022-01-06 ([minutes](2022-01-06-wecg.md))
 * 2021-12-09 ([minutes](2021-12-09-wecg.md))
 * 2021-11-11 ([minutes](2021-11-11-wecg.md))
 * 2021-10-28 ([minutes](2021-10-28-wecg.md))

_minutes/export-minutes.html

@@ -167,6 +167,17 @@
         prefix += " * ";
     }
     li.prepend(prefix);
+
+    // The structure is li > p > span, with the span containing the line content.
+    // When the li contains multiple lines (e.g. shift-Enter in Google docs),
+    // there may be multiple span elements (potentially containing just a single <br>)
+    for (let br of li.querySelectorAll(":scope > p > span > br")) {
+        // Indent the (text) content at the next span.
+        if (br.parentNode.nextElementSibling) {
+            br.after(" ".repeat(prefix.length));
+        }
+    }
+
     let isNewList = li.parentNode.previousElementSibling?.tagName !== li.parentNode.tagName;
     if (level === 1 && listIndex === 1 && isNewList) {
       // Insert blank line before top-level list.