2023-09-11-2023-09-14-tpac-extra.md

# Extra meetings at TPAC 2023, Sep 11 - Sep 14

These are meeting notes of the unscheduled in-person meetings of the WECG at TPAC 2023.

These extra meetings complement the scheduled meetings, whose minutes are published at:

* 2023-09-12 at TPAC ([minutes](2023-09-12-wecg-tpac.md))
* 2023-09-11 at TPAC ([minutes](2023-09-11-wecg-tpac.md))


## Sep 11, 2023


### Community Group Meeting Prep

 * Attendees: Apple (Kiara), Google (Devlin, Oliver, Patrick), Mozilla (Rob), Simeon
 * Discussion Prep
   * WECG Meeting Structure and Followup
     * Lead: Simeon
     * Abstract: How can we adjust our meeting structure to better support How do we improve the efficacy of our public meetings?
   * Automated Compatibility Testing
     * Lead: Rob
     * Abstract: How can we establish a cross-browser automated testing framework and suite, specifically in the context of verifying interoperability of extension APIs (like wpt)?  (Specifically out of scope: extension testing for end users.)
   * Open Web API Integration
     * Lead: Devlin
     * Abstract: Adding extension-specific capabilities in open web APIs allows us to leverage more stable, performant, and capable APIs and align with the existing ecosystem; in which APIs does it make the most sense to integrate?
   * Open Discussion / Flex Time
     * Lead: <NA>
     * Abstract: Continue discussion from previous discussions; things that came up during the day.


### Topics for discussion

 * [oliver] Alarms: What to do when the laptop closes
   * [WECG Issue 433](https://github.com/w3c/webextensions/issues/433)
   * Two issues
     * Can create an alarm in two ways: delay in minutes or "when"
       * If you put a delay of 5 minutes, then, after two minutes, put the device to sleep for two minutes, you need to wait 3 more minutes for it to fire
       * Happens for both "when" and "delayInMinutes"
     * Multiple extension alarms firing can cause recalculation, not taking into account device sleep
       * Non-controversial: Extension A's alarms should never affect Extension B
     * [rob] periodInMinutes minimum is 1. Is one-minute resolution a hard requirement, or is a lower resolution acceptable?
       * [devlin] Let's table for now.
     * [devlin]: Also non-controversial, firing for "when" should always fire at the time, not take into account device sleep
     * [devlin]: What about for delayInMinutes?  Around the table.
       * Unanimous consensus: should be wall clock
     * [devlin] Edge cases!
       * [rob] Device is asleep at the time
         * [tom] Delay in minutes has passed; should obviously run
         * [devlin] Should they?  Three possibilities
           * Fire them
           * Don't fire them
           * Fire them with a different (expired alarm) event
         * [oliver] With delayInMinutes, should fire, with "when" should probably still fire
         * [devlin] Devil's advocate: if it's time-sensitive, you may want to change handling.  onExpiredAlarm would be more clear
         * [oliver] It's easy enough to just calculate it
         * [rob] could introduce a new option
         * [devlin] eww.  Also not _that_ worried about breaking changes for this scenario, since it is already very broken for device asleep cases
         * [kiara] aligned on should fire on device wakeup?
         * [simeon] What's simplest to grok?  Firing immediately
         * [rob] What about periodInMinutes? (repeating timer)
         * [oliver] Ugh.  We shouldn't fire 100 alarms for 100 missed periods
         * [simeon] I would expect periodInMinutes to fire at least <N> minutes after last firing period.
         * [devlin] But then you get significant drift.  That was a past bug in Chromium we fixed.
         * [oliver] align with setInterval behavior if possible?  What is setInterval behavior?
         * [devlin] Or setTimeout behavior while laptop closed?
         * [oliver] Thinking about a use case with a 24 hour timer (e.g. syncing), we wouldn't want that to not fire just because you missed it by a minute
         * [devlin] Web Platform Behavior (in FF and Chrome):
           setInterval fires once for missed interval
           setTimeout fires for missed timeout
         * [tom] Unanimous that we should align with setTimeout and setInterval should behave similar ot the web?
         * [oliver] Looking at the spec unfortunately seems to contradict what Devlin saw in testing. We should speak to some people familiar with the spec to decide next steps.

Schedule

| Time (CEST) | Duration | Topic |
| - | - | - |
| 17:00 | 5 min | Intro |
| 17:05 | 20 min | WECG meeting structure and follow-up |
| 17:25 | 20 min | Automated compatibility testing |
| 17:45 | 10 min | Break |
| 17:55 | 20 min | Web API integration |
| 18:15 | 15 min | Open discussion |
| 18:30 | --- | End |


## Sep 12, 2023


### Community Group Meeting Prep

 * Attendees: Apple (Kiara), Google (Devlin, Oliver, Patrick), Mozilla (Rob, Tomislav), Simeon
 * Discussion Prep
   * Automated compatibility testing
     * Lead: Rob Wu
     * Abstract: Continuing from yesterday - concrete steps to work towards enabling extension API testing in wpt.
   * Declarative Net Request
     * Lead: Oliver
     * Abstract: What is the vision for DNR and where do we want to see it in 5ish years?
       * What are the next steps for the safe rules proposal?
       * Missing functionality
   * User Script API
     * Lead: Devlin
     * Abstract: We are still sticking to the documented plan (recap it).
   * WebAuthn RP ID
     * Lead: Devlin will kick-off and hand to other folks in the room
     * Abstract: Suggestion to allow extensions to use a manifest-specified origin as the RP ID in WebAuthn.

Schedule

| Time (CEST) | Duration | Topic |
| - | - | - |
| 17:00 | 5 min | Intro |
| 17:05 | 20 min | Automated compatibility testing |
| 17:25 | 25 min | Declarative Net Request |
| 17:50 | 20 min | User Script API |
| 18:10 | 20 min | WebAuth RP ID |
| 18:30 | --- | End |

 * Topics for discussion
   * [rob] user scripts
     * <missed minutes; TL;DR plan of record should work>
   * [kiara] wpt / automating extension tests
     * [kiara] attended the WPT this morning and we spoke about using WPT to run cross browser extension tests. They were receptive to it and asserted that it's just a matter of someone doing the work.
     * [patrick] Can I load unpacked extensions in Safari?
     * [kiara] There is a way to do it (internally)
     * [patrick] As a non-privileged extension, I would have to patch up xcode to do that?
     * [kiara] Yes.
     * [patrick] What is the least painful way to automate loading unsigned extensions?
     * [kiara] After using the resources to create the xcode project using the converter tool, you can manually allow the extension with unsigned extensions checkbox in developer preferences
     * [patrick] What is the overhead of building the extension after running the converter tool?
     * [kiara] Not too much.
   * [rob] Synchronous execution in main world from content script (Was: Remote code execution)
     * [rob] I'd like to talk about executing code synchronously from the context of content scripts. This has come up a few times before, and there are a number of use cases that can benefit from this primitive.
     * [rob] MV2 Chrome extensions can currently inject an inline script element, a primitive that is also built upon in the user scripts API. MV3 extensions can't do so due to the default CSP, and Firefox extensions cannot bypass the page's CSP to permit inline scripts either. Rather than disabling the script execution restrictions, I would prefer a dedicated API to run specific scripts from the content script.
     * [devlin] Why wouldn't the extension use scripting.executeScript?
     * [rob] if there's a way to directly invoke from a content script, this could be extended to pass a handle to communicate between the main and isolated world. There are classes of extensions that want to run a trusted piece in the main world and have a trusted piece of code in an isolated script.
     * [devlin] It's impossible to have a trusted main world script.
     * [rob] The main world script is not trusted, but the content script world is semi-trusted. If the main script is a function with a local scope, it can receive a handle to communicate synchronously with the script in the isolated world.
     * [devlin] Are we agreed that this is possible today if you don't mind proxying through the background content?
     * [rob] <thinking>
     * [oliver] Did you say you needed it to be synchronous?
     * [rob] Yes, need to be able to run / communicate synchronously.
     * [devlin] Ah, missed that it had to be synchronous.  Note that this isn't remote code execution at all, though – it's just synchronous execution of code (that could be in the extension)
     * [oliver] We also have [issue 414](https://github.com/w3c/webextensions/issues/414) which was about script injection at the user level from a content script. Proposal was a new API to inject in browser.dom. We wouldn't allow files as that is a security risk.
     * [devlin] Why are files a risk?
     * [rob] In another conversation you mentioned that we don't want to allow extensions to load an arbitrary resource.
     * [devlin] Depends on how it's being injected.
     * [rob] web_accessible_resources is a broad tool, using it may allow fingerprinting.
     * [devlin] What are the main use cases for this? Adblockers & scriplets?
     * [rob] Yes, I also have use case for rewriting URLs like copying URLs from Google search results, configurable through extension settings. Don't want to embed those checks in the page – want a somewhat trusted, isolated environment
     * [devlin] I wonder if we would ever see "file" used.
     * [rob] I proposed “file” because you're probably opposed to arbitrary strings. What about the func + args option?
     * [devlin] A function would be much faster and more in line with what you'd typically want to do. Would introducing dom.executeScript() that takes a function object an array of arguments be reasonably sufficient for these use cases?
     * [rob] Yes. Would also be nice to define the serialization method. In principle, are you okay with that?
     * [devlin] Yes. In my view this isn't equivalent to remotely hosted code because the content script has the extension's CSP and prevents things like inline script execution.
     * [rob] Okay great. How about CSS from the content script? In previous discussions you were favorable towards loading CSS from the content script ([issue 403](https://github.com/w3c/webextensions/issues/403)).
     * [devlin] dom.insertCss with an arbitrary string would be fine. Avoiding file for many of these use cases is clearly beneficial. It's faster, avoids extra IPC/overhead.
     * [rob] And to emphasize too - there is no privilege attached to code being executed. In contrast, an inline script element in Chrome bypasses the CSP of the web page to execute code. I wouldn't want the new capability to inherit privileges like this.
     * [devlin] Wouldn't classify that as the content script having those privileges. It would inject into the main world and the main world CSP applies. Similar to that, dom.executeScript would allow the script to execute and immediately apply the CSP
     * [rob] This could also be useful for content script managers that want to inject a snippet in another user scripts world. If there's a userscript API that synchronously returns storage values, the content script of the user script manager would maintain that storage and return values as requested. User script manager could inject the preamble to set this up and enable them to synchronously communicate.
     * [devlin] Not sure I agree with this case. If it's in the preamble, why not modify the code you're injecting from the start?
     * [rob] You want to get the handle to communicate across contexts. If comms are supported as part of the userScript API you don't need this. But otherwise this primitive would enable you to communicate between worlds (isolated world and user script world). In the userScripts API design, have you considered synchronous communication between user script and manager?
     * [oliver] is the reason for that to cancel an event?
     * [rob] There are user script APIs that are synchronous (GM_getValue), changing that would break existing scripts. Admittedly, without special API support, it would be possible to establish an initially secure communication channel between the isolated world and the user script world, by saving copies of prototypes and using a secret event name to communicate.
     * [devlin] Having a communication channel is something we'll pursue, but I don't know that I'd comment to it being synchronous. User scripts, I hope, won't have that much data associated with them. You could asynchronously update the data exposed by the user script manager.
     * [devlin] In this scenario and for the foreseeable future you'll have user script managers injecting additional code wrapping user scripts. That additional code can set up a listener to asynchronously load storage, then execute the user script and thereby expose sync storage.
     * [tomislav] What is the value of forcing the comm channel between two scripts in the same process/page to be async?
     * [devlin] It's not strictly necessary for IPC, so we're not blocking a loop, but it's still preferable to break the direct dependency. It's possible that one world is blocked at the time of execution, but the other world is not blocked.
     * [tomislav] does chrome have separate threads for worlds?
     * [devlin] No, but nested message loops can execute simultaneously. …
     * [rob] Side note, it is currently already difficult to expose synchronous APIs. User scripts were designed for the original Firefox API that were more powerful than Chrome's extension model. If the requirement of injecting scripts at document start and sync data retrieval was required, sync XHR was the only way to accomplish this.
     * [devlin] Recap: supportive of dom.executeScript with func+args, dom.insertCSS with arbitrary string, message channels between worlds, want to avoid committing to executing scripts in other worlds that aren't the main world (e.g. content script injecting a user script in another world) unless there is compelling reason to support it.
     * [rob] You'd also be in favor of supporting author stylesheets through this API (issue 403), right?
     * [devlin] author vs. user? Not ideal, but, yeah. I'm not thrilled with copying the options from the scripting API to this method, but I'm not opposed to the functionality.
     * [rob] Use cases with script execution based on e.g. CSS rules can be covered by this. Waking up the service worker or event page all the time isn't ideal, which is the current alternative.
     * [devlin] Depends on the use case for how undesirable this is, but the synchronous execution is compelling
     * [oliver] In the early stages of the proposal we were very clear that we only wanted user script managers to use this API. Is that still accurate?
     * [devlin] Yes. No strict definition of what a User Script Manager is, but we certainly don't want extensions to back-channel their own use.
     * [tomislav] But policy is not standardizable
     * [devlin] Agreed.
   * [tomislav] Custom element registry meeting
     * https://www.w3.org/events/meetings/e5cc2d3f-6da6-4751-9417-18b80a524893/
     * https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md
     * [tomislav] Seems relevant to our interests. Would like at least one person to attend.
     * [rob] Does Chrome keep track of which world created the dom element?
     * [devlin] No
     * [tomislav] I'm suggesting we ask them to keep track of the world.
     * [rob] Not sure that's the best way to support custom elements. Could add a new method to the dom namespace to register.
     * [tomislav] Could clash with the dom
     * [rob] Yes, but content script can always clash with the dom.  …
     * [devlin] If we introduce a dom.executeScript method, couldn't you just inject your custom element definition into the main world.
     * [rob] dom.executeScript wouldn't cover this use case, because the global APIs may be unreliable due to web page's modifications to the main world. (..) but they shouldn't do that anyway.
     * [devlin] … Seems like that might solve this.
     * [tomislav] Does a custom element registered by a content script get exposed in the main world?
     * [devlin] Only way to register a custom element is in the main world. Not sure I see the benefit of supporting this in the isolated world. Need compelling use cases.
     * [rob] Firefox already supports exposing values across worlds through wrappers.
     * [oliver] Another issue I've heard from developers is interacting with custom element properties e.g a custom element is registered in the main world and exposes a function, and the content script world calls it. But I think this is solved by having dom.executeScript and getting a handle on the element.
     * [devlin] Yes. Not a handle though.
     * [oliver] You could use document.querySelector.
     * [devlin] Yes.
     * [rob] You could pass a reference to the element via the args parameter.
     * [devlin] Yuck.
     * [rob] What's your concern with passing a reference to an element?
     * [devlin] Complexity of mapping the JS variable to the DOM element in the isolated world, and then back to a JS handle in the main world.
     * [rob] That should be safe.
     * [devlin] yes, but there are other problems. … If in my JS I set data on an element, pass a reference to another world, and try to access that data in my other world scfript, would not see the data I set
     * [rob] That is expected, a normal part of the isolated world concept.
     * [devlin] Yep, exactly – but it's more surprising if I pass an element reference and get an element reference that those are totally different.  If I pass an ID and then re-fetch that element in the main world, it's more intuitive that they are different values.
     * [rob] So you want to use structured cloning? Generally a copy of everything? I can agree with that reasoning.
   * [rob/devlin] DNR: future vision (where do we want it in 5 years)
     * [oliver] Are we concerned about malicious extensions adding dynamic rules?
     * [rob] Unless there's something sensitive, let's save this topic for the public meeting.
     * [devlin] +1
   * [kiara] browser namespace
     * [Issue 113](https://github.com/w3c/webextensions/issues/113): Proposal: Make extension APIs browser neutral
     * [kiara] In short, I asked about supporting the browser global
     * [oliver] I effectively said we're good with this except for the need to work out what we do with externally connectable
     * [devlin] Historically, Chrome has done a lot of work to make sure that everything exposed on the global window object be standardized except for the "chrome" namespace, and even then we try to keep it as tight as possible.
     * [oliver] Can we just keep it as chrome for this specific case?
     * [tomislav] Talking about two different things, the namespace in extensions and the namespace in web pages.
     * [devlin] Let's start at the beginning.
     * [kiara] Can we support "browser" in extension contexts.
     * [devlin] Potentially, but we would still have the same issue
     * [simeon] Sounds like we could support chrome and browser. Breaking for developers we can address in manifest version bumps.
     * [devlin] That introduces a new global, which violates the existing Chrome global variable practices.
     * [simeon] Even if only in extension contexts?
     * [devlin] Yes.
     * [tomislav] lets separate externally_connectable from this, and only focus on the extension world. Safari does not support externally connected right?
     * [kiara] no, we do support it
     * [tomislav] oh, ok. I was out of date. Can we discuss the two concepts separately
     * …
     * [devlin] What if we had different namespaces for background scripts, content scripts, service workers, workers, etc. That's too much inconsistency and unpredictability for developers.
     * [tomislav] developers understand that in different context, there are different bindings. Let me ask you like this - is it not confusing to keep track of different top level namespaces
     * [devlin] I think for developers its a single line of code - browser = browser || chrome. I find it odd to have different globals in different contexts that both map to chrome APIs (and even the same chrome APIs for messaging).
     * [tomislav] Do you think its too much for developers to adapt to different namespaces across browsers?
     * [devlin] Developers can do browser = chrome || browser
     * [tomislav] It's unnecessarily confusing to developers that Chrome is special cased and they can't use the common practice of "browser" in Chrome.
     * [devlin] There are two different concerns. 1, (not mine) window.browser is not compatible with web spec. If we can convince other Chrome people that this is okay, I'm on board. If we expose chrome<dot> in window contexts and browser<dot> in extension contexts, that introduces inconsistencies across contexts and has a migration problem.
     * [tomislav] that is all chrome specific issues, not a WECG issue though. You are bringing private issues to the community group
     * [oliver] I think we can drop the chrome apis from the web, except for the ones required on the web side of things
     * [devlin] but we still then need to support both "chrome" and "browser"
     * [devlin] What do we do about the chrome global in pages? There's still inconsistency there. We have chrome, but what about Edge?
     * [kiara] Safari supports the browser global in web pages
     * [rob]  why do you tie it so closely together - if 99% of usage is a browser thing, rather than a chrome specific thing, it seems reasonable
     * [devlin] I'm not entirely sold. It ends up taking up the browser namespace for a non standard thing
     * [rob] If there's prior art that multiple browsers support the browser global, that signals adoption and the web platform reserving the name.
     * [patrick] Is there a reason we can't expose browser as an alias?
     * [devlin] That's largely what we're discussing.
     * [patrick] But what else blocks?
     * [devlin] Besides what we discussed (2 main issues above), it introduces inconsistency.
     * [rob] I don't think that's a major concern.
     * [sam] I'm fairly new to this, but … web extension polyfill ships with types that match Firefox. It's a DevExp concern because your IDE prevents you from writing code that doesn't match the
     * [rob] So where do we go from here?
     * [devlin] If we can get platform owner buy-in to globally replace chrome with browser, then I'm on board with that. I'm not comfortable splitting
     * [tomislav] I assume it would be a much lower lift to just address this in extension contexts, correct?
     * [devlin] Yes, but I'm not comfortable with that. That introduces more confusion and complexity for a class of developers.
     * [tomislav] How big is that class? How does it compare to developers working on cross-browser extensions.
     * [oliver] Can't we take a concrete step toward the desired path and delay resolution of the second half?
     * [devlin] <look of fear>
     * [simeon] I'm very hesitant about pushing forward without a plan. That's how you get fragmented, half consistent APIs.
     * <Rick Byers enters the room>
     * [devlin] I seem to recall we have had a very concerted effort to remove non-standard globals. Safari, firefox, edge all support Chrome's extension platform. All other browsers support a browser global. Since everyone else supports this model & we're actively working to align across browser.  How would you feel about exposing a `browser` property on the global?
     * [rick] I don't care what you do in the extension global namespace.
     * [devlin] Yep, but this would also be on the web.
     * [rick] I think it would be good to write up a little spec that defines the shape of the surface area you want to expose, and then just says "this is a user-agent specified thing". If we can agree between Apple, Mozilla, and Google then we can probably move forward. If we can reserve the global and get buy in from other browsers, we can leave the global for the extensions platform to use as appropriate.
     * [devlin] Do you have a recommendation on how to approach this? Is this a new spec, tagged onto an existing spec?
     * [rick] Probably a separate spec.
     * [patrick] …
     * [rick] We can probably also use this as a step on the path to remove the chrome object as well, but no promises there. I can see starting with a WICG spec and and identifying it as a work item from the WECG.
     * [tomislav] Can we just have a spec from our group, since they're both CGs?
     * [rick] Probably, yeah.
     * [rick] You can probably define the public API and shim out empty objects and functions.
     * Resolution: we need to write a spec proposal, then move it to a WICG to propose standard extension. After that, implementation can follow.


## Sep 13, 2023

Discussion

 * Attendees: Simeon, Devlin, Rob, Oliver, Richard Worth
 * [richard] Specification work
   * [richard] Suggest we each take a few minutes to identify ~10 items in a few minutes
   * [devlin] Would be hesitant about trying to come up with 10 and 10.
   * [TPAC 2023 - Spec breakout](https://docs.google.com/document/d/1q9hQgwTVvyujEhvr52ALeTtuYxyzFhQPfRwPg_hBXlI/edit)

After lunch

 * Attendees: Simeon, Devlin, Rob, Oliver, Tomislav, Kiara, Richard Worth, Carlos
 * [rob] Proposal for labels: consensus:approved, consensus:mixed, consensus:opposed
   * [devlin] Do we need consensus:opposed?  Isn't that just wontfix?
   * [rob] For symmetry.
   * [devlin] Fine by me.
 * [kiara] Do we agree to avoid browser specific naming in APIs?
   * [devlin] I would not say we should avoid this but we should be very cognizant of when we do that. I could imagine certain fields in the manifest like an app store developer ID.
   * [kiara] Omnibox. We all have a similar feature, but the name is Chrome.
   * [devlin] I think this would depend on how different or similar the functionality is. With sidebar_action or sidePanel there was a section in the proposal on the fact that the features are different enough because there are hooks into the browser feature which has different functionality and behavior across browsers. Rob gave the search API as an example where the behavior is very similar, which should indeed be the same API.
   * [devlin] I think this is something to solve case by case depending on if the thing is significantly different.
   * [simeon] An example is incognito and if we use a different name across browsers. Should we use private instead?
   * [devlin] Incognito is not private so would not want private naming, we try to be careful about this in Chrome. We also use the terminology “off the record” in the Chromium source, don't think that is the right term but something similar would be good.
   * [rob] For this topic we decided to stay with incognito. In the future we will keep browser generic terms in mind.
   * [devlin] I'm inclined to continue using "incognito" for similar capabilities in the future. For example, if Reading List had a list that was only exposed in incognito mode, we should continue using the same name for that concept.
   * [rob] The incognito concept has the same name regardless of API.
   * [tomislav] The devil is in the details. Omnibox doesn't feel appropriate to keep the browser-specific name because there is a core set of common functionality. Seems feasible to keep the same name and then build on top of it for specific behavior that is browser specific.
   * [devlin] I think sidepanel/sidebar are on the edge. I don't think other browsers have tab-specific side content.
   * [tomislav] You can have a tab-specific sidepanel in Firefox. We get bugs in Firefox whenever Chrome diverges.
   * [devlin] We get bugs in Chrome regarding divergences as well.
   * [devlin] Going forward we should determine whether there is sufficient overlap and if so align on one namespace. In the past we have done differently. Sidepanel is on the edge. I don't think that we're going to change.
   * [tomislav] I think it's a good example of what could have been done. It was already a shipping feature in Firefox. For compatibility and consistency for developers, what's the path forward?
   * [devlin] We still don't have a well established proposal process. There wasn't a good way to bring forward an API.
   * [tomislav] Yes, but we didn't even have a discussion about it.
   * [rob] It was mentioned, but the stance was expressed that it was sufficiently different.
   * [devlin] If there's sufficient overlap, we should align. In this case I think that the behavior of these was sufficiently different that it justified not aligning. The other aspect is that it's a user-facing name in Chrome.
   * [rob] Same could be said about Omnibox then
   * [devlin] Just an example, but Smart Search is similar to but different from Omnibox. These UI surfaces are browser vendor specific and each browser may want to expose features that are browser specific.
   * [rob] If two out of the three browser vendors agree, and one differs, then how do we reach consensus here?
   * [devlin] If any of the implementers disagree, we don't spec it.
   * [carlos] Would it makes sense to move these browser specific settings into the "browser_specific_settings" key in the manifest?
   * [devlin] I don't like how that impacts the structure of the manifest, particularly when there are multiple browsers implementing a feature.
   * [carlos] The idea was to implement it to …
   * [tomislav] That works until we have to adopt another browser's API due to market pressure.
   * [devlin] That's an antagonistic view, but it's also relevant when we realize dang, we do want to implement that after all.
   * [...]
   * [oliver] Related question. Say we get a browser global. Would we also move the chrome-specific stuff into that?
   * [devlin] I think so, yes.  We've talked in the past about having only the spec'd / standardized stuff on `browser` and the other stuff on `chrome`, but I think that just results in confusion and prevents an easy "upgrade" path from browser-specific to shared.
   * [tomislav] That's currently the case in Firefox for User Scripts. We have the old user scripts API, so now we'll have two different approaches in the same namespace. Let's acknowledge the inequality here. You can push forward something and we have to support it, but if we diverge you don't have to adopt.
   * [rob] I imagine in the future two vendors will support something and another will not. A way to get this in the “spec” is to include a note that this is specific to X and Y, and/or not supported by Z.
   * [devlin] I suspect that we'll have a better idea once we proceed further down the path towards specification. I suspect there will be nuances we will need to discover.
   * [carlos] I want to push back against the browser prefix reference. If it's specific to one browser and sufficiently different, like omnibox, then it makes sense to put it in the browser-specific settings.
   * [rob] I worry about the ease of breaking backwards-compatibility. We shouldn't unnecessarily touch existing APIs, but we can apply the new principles to new APIs.
   * [devlin] There are a number of things that don't quite fit there, like permissions. Chrome-specific permissions and top level permissions. That gets us into a very weird state. For top level APIs, I'd want to avoid having them in a browser-specific-settings. In the past "chrome-overrides" would be an example, but now everyone implements them.
   * [tomislav] We haven't yet seen implementing browser specific settings from other browsers.
   * [devlin] don't you implement chrome url overrides?
   * [tomislav] yes, but we don't do anything in browser-specific-settings.
   * [rob] It looks like there is consensus on not putting APIs under browser_specific_settings - I agree with that.
   * [rob] Is consulting the WECG part of Chrome's New API Proposal process?
     * [devlin] yes, in theory consulting the group is part of the process of introducing new APIs. That said, extensions are used for private pieces of Chrome. For new public APIs, that's part of the process.
     * [richard] Should that be documented in the WECG?
     * [devlin] It's documented in Chrome process. We should define a WECG proposal process. Perhaps we should start with Chrome's API overview doc. There are some things that are chrome-specific, but for public items there's good prior art here.
     * []
   * [rob]  Kiara, anything else to mention, since you introduced the topic?
   * [kiara] I feel like there's still gray area about how things behave across different browsers. I'm not aware of how Omnibox is meaningfully different from what we offer.
   * [devlin] If we would restart with the omnibox API, it would probably be called address bar. If we redid sidebar/sidepanel, we may or may not have aligned – there's still significant differences in the API that it's unclear we'd align on.
   * [tomislav] I want to go back to a complete example, like event page. If any browser is strictly opposed, it shouldn't be documented
   * [devlin] Didn't say it shouldn't be documented, it shouldn't be specced as part of the main spec. I need to brush up on how browser incompatibilities are handled in other specs.  I think a) things should be written down somewhere and b) it should be clear which set of functionality is intended to be the same and shared across browsers and which aren't.
   * [tomislav] There are specs where differences are defined and when you don't provide a given capability, you just ignore that section.
   * [devlin] I don't want to commit to a specific approach, but I think we're all aligned on writing down in a clearer way the different approaches we use and where there is incompatibility. I would even say if there's only one implementer, we may want to have it written down.
   * [tomislav] Not a relevant topic for the group until there are at least two interested parties.
   * [rob] … I don't think it makes sense to bring a browser-specific API to the group that others won't adopt.
   * [devlin] I don't think we can reach consensus on this today. Would you be comfortable documenting something that's exposed in Opera? It's the same engine, but a different browser
   * <mixed reaction>
   * [devlin] I feel strongly that there should be a clear way for us and developers to see what we agree on and what we don't agree on, and that we should write down the stuff we don't agree on somewhere.
 * (Carlos and kiara leave)
 * [oliver + simeon] Service worker fetch events
   * [oliver] Chrome supports fetch events in the service worker, Safari does not.
   * [rob] We should probably wait for Kiara to return.
   * [simeon] The other chunk I wanted to call out was how browsers load extension assets. For example, content scripts injected into a page do not hit the extension service worker. From the web developer perspective this is surprising as service workers are the intermediary for all resources being loaded on a given origin.
   * [devlin] This should not go through the service worker. It's a different type of resource being loaded. In the case of content scripts, you specify a relative path of a file inside the extension. Beyond that, there are legitimate reasons not to expose this to the extension, namely that this makes it easy for extensions to
 * [devlin] Bug Bash
   * https://github.com/w3c/webextensions/issues/438
     * [rob] Extensions want to be able to load web content as if it is the top level in extension documents. They currently do so by countering the frame busting mechanism (e.g. removing XFO header). Any opinions on this use case?
     * [devlin] I am supportive of bypassing XFO, but that's not this issue – this issue is about allowing top-level web content in the side panel or allowing extensions to run in web frames in the panel so you get ad blockers / user scripts / etc running on that web content.
     * [rob] It's not just XFO, also first-party/third-party API aspects (e.g. cookies).
     * [devlin] And we already consider a frame first-party if embedded in an extension with the host permission.
     * Separate issues
       * Host permissions bypassing x-frame-options
       * Allowing other extensions in iframes in extensions.
     * …
     * [oliver] Commented at https://github.com/w3c/webextensions/issues/438#issuecomment-1717725419
   * https://github.com/w3c/webextensions/issues/251
     * [rob] DNR dynamic rules are kept after updates in practice, despite Chrome's code intending to delete on update.
     * [devlin] Given that this is the universal behavior, I'm inclined to keep the current behavior.
     * Consensus: Chrome to keep the behavior, Rob to comment on issue and file crbug.
     * [rob] Commented at https://github.com/w3c/webextensions/issues/251#issuecomment-1717758523
   * https://github.com/w3c/webextensions/issues/338
     * [devlin] Supportive of Promise as return value in runtime.onMessage
     * [devlin] Commented at https://github.com/w3c/webextensions/issues/338#issuecomment-1717760378
     * [rob] I also commented on https://bugs.chromium.org/p/chromium/issues/detail?id=1185241#c5
   * https://github.com/w3c/webextensions/issues/431
     * [devlin] Opposed.  "Active tab" is hard to determine and inconsistent, and also is inherently racy.  Instead, we try to make this easy for most cases we see, like action.onClicked, contextMenus, commands, etc.  I would be supportive of supporting the popup use case with an api like tabs.getCurrent
     * [rob] E.g. by returning the initial tab in tabs.getCurrent() instead of undefined (currently only returns anything when it is a tab).
     * [devlin] I would want to do something like that. Chrome closes the popup when the tab closes, so there's no risk of returning the wrong tab
     * [rob] What if the active tab changes?
     * [devlin] Also closes.
     * [rob] What if the focused window changes?
     * [devlin] Stays open.
       * [rob] That is not always the case, from experience.
     * [rob] What if the tab navigates?
     * [devlin] Then the popup stays open. The popup can be tab-specific, but not document specific
     * [rob] In Firefox, when the tab navigates, closes or changes active state, the popup stays open. When the window focus changes, the tab closes.
     * [carlos] Safari follows Chrome's behavior here.
     * [devlin] I feel strongly that a tab-specific popup should be closed when the tab changes, and for consistency a non-tab-specific popup.
     * [rob] Action popups can be window-specific in Firefox.
     * [devlin] Not in Chrome.
     * [carlos] How about a new constant to inject in the active tab, e.g. -3.
     * [devlin] It is still as racy. The active tab may not the same as the tab that was active at the time of clicking the popup.
     * [rob] How about mapping -3 to the return value of getCurrent? It's well-defined.
     * [devlin] Too much magic. Would be supported in popup but not in service worker.
     * [devlin] Commented at https://github.com/w3c/webextensions/issues/431#issuecomment-1717824871
     * [carlos] Filed https://github.com/w3c/webextensions/issues/450
     * [kiara] I previously filed an [issue](https://github.com/w3c/webextensions/issues/316) about tabs.getCurrent() returning undefined in chrome.
   * https://github.com/w3c/webextensions/issues/316
     * [kiara] Safari returns the currently active tab.
     * [devlin] Sanity check: what does getCurrent do from an iframe?
     * [carlos] (tested) Returns the tab hosting the iframe.
     * [rob] Makes sense.
     * [devlin] Sanity check: what does Safari do when a background tab calls getCurrent() when there is another tab in the foreground.
     * [kiara] It returns the tab that called tabs.getCurrent().
     * [rob] I am in favor.
     * [rob] Carlos, could you test the behavior of tabs.getCurrent() when the tab activeness changes, and when the tab is closed?
     * [carlos] Thanks.
     * [devlin] Commented at https://github.com/w3c/webextensions/issues/316#issuecomment-1717858832
     * [rob] https://github.com/w3c/webextensions/issues/316#issuecomment-1717863435
   * https://github.com/w3c/webextensions/issues/293
     * [oliver] Rob has posted detailed thoughts before
     * [rob] At https://github.com/w3c/webextensions/issues/293#issuecomment-1310203017.
     * Discussion on blob:-URLs where Rob explains how blob:-URLs work.
     * [rob] Want to use postMessage primitive with transferable semantics.
     * [devlin] Supportive in general; using web messaging APIs for extension purposes is one of the areas I want to explore for modifying web specs for extensiony things.
   * https://github.com/w3c/webextensions/issues/387
     * [oliver] Would we consider implementing sidebar action for compatibility reasons.
     * [devlin] probably not.
     * [carlos] What should be the expected behavior? Say it's implemented in Opera, Brave, and Firefox. There should be a clear behavior so that developers can rely on that.
     * [kiara] We are supportive of switching to a block list. (reference to previous issue discussion -scribe)
     * [oliver] the other two questions on this issue are even if there are separate APIs, should we standardize on requiring a permission? The other question is what should we do with this issue? I'd suggest closing it as we can't take action, but open to thoughts
     * [carlos] Would be odd to require "sidepanel" for a different API namespace. Would also introduce a breaking change. Might also be good to open a separate issue to discuss what should happen when both are defined.
     * [oliver] At the moment no browser supports both.
   * https://github.com/w3c/webextensions/issues/440
     * …
     * [devlin] one of the reasons DNR is fast is because it happens in the browser process. Parsing is inherently dangerous and therefore cannot happen in the browser process. As a result any time we want to parse a CSP, we'd have to spin that work out to another processes.
     * [carlos] What about 439?
     * [devlin] Unlike 440 this is much easier to implement, but in all other ways it's less desirable
     * [tomislav] Regex is not the right tool for this job.
     * [carlos] Is there no way to run some code to modify the request?
     * [devlin] we've discussed ideas of creating some kind of black box without network access that restricts what can be done inside the box, but anything like that is years away and comes with significant challenges.
     * …


## Sep 14, 2023

Discussion
Attendees: Simeon, Devlin, Oliver, Patrick, Tomislav, Kiara, Carlos

 * Message Format 2
   [GitHub - unicode-org/message-format-wg: Developing a standard for localizable message strings](https://github.com/unicode-org/message-format-wg) [discussed on 13 sep]
   * [tomislav] Addendum to previous discussion. Firefox has more integration with this. The way it would be exposed to the web is mostly as just an API. … Instead of adapting to a new standard later, we should consider it now in order to influence it in case we need adaptations for our use. If we'd like to have this be a topic in our session, I can ask him to join.
   * [devlin] Not sure how impactful that would be. First step: someone take the action item to look at the API and consider what we'd need with it. Not comfortable trying to fit that in a small time slot
 * [oliver] BFCache
   * [oliver] Brief recap: bf cache = back forward cache. When you navigate away from a page, it's pushed into the cache. Page is frozen. Messages sent to the cached page could be handled a variety of ways, currently inconsistent across browsers. In Chrome,
   * [tomsilav] We drop the ports as soon as the page is cached.
   * [devlin] Do you fire ondisconnect? <yes> in the background context? <yes> in the page when it's restored?
   * [tomislav] Not sure.
   * [kiara] Not sure of our current behavior.
   * [oliver] I believe Timothy said this wasn't explicitly considered. Would like to align on behavior.
   * [devlin] We're seeing messaging to pages as a major reason for cache eviction. Firefox's behavior is potentially breaking to how Chrome extensions work. Extensions would need to know about and adapt to a potential change.
   * [devlin] We've considered other ways to handle this. Queuing messages: no one was happy with this solution – it's complex and not clear it would be any better for compatibility. A lot of eng work for no clear benefit. Option that has most potential interest is adding a suspend event to a port. Fire "onSuspend" in a background context and when a page is restored from cache "onResumed" fires.  This seems interesting, but doesn't work well because ports can be many-to-one with receivers-to-opener.
   * [tomislav] Can you allow a script when the page is frozen to run?
   * [devlin] Don't want to allow any JS to run in cache. Main challenge with on suspend is the message channel.
   * [tomislav] As soon as you break one side of a many to one port, we close the port. We just found out this is inconsistent with Chrome, but haven't heard about this causing bugs.
   * [devlin] There's appetite to improve our messaging APIs. Leaning towards creating separate APIs for broadcast and 1:1 messaging.
   * [tomislav] Can parts of a page still run while the top frame is in bfcache? Iframes? <devlin: no> Not quite sure about Firefox behavior.
   * [devlin] IMO we shouldn't introduce anything new for bfcache yet.  We should disconnect the port and align with Firefox's behavior, which solves the problem of cache eviction. Given that developers can handle page hide events and you can just reconnect when a page comes back, this is a recoverable state for developers.
   * [tomislav]
   * [oliver] If we introduce something that mostly works but occasionally breaks, developers may not notice. I'm almost more in favor of breaking more visibly.
   * [devlin] That's why I think we should disconnect the moment it enters cache.
   * [oliver]  Yeah. We can also consider other ways to make it more visible, like logging a warning on the disconnect the first time for a 1:1 port.
   * [devlin] That could be something like a disconnect reason; that could be helpful outside of bfache, too – "the port was closed because the tab closed", "the port was closed because it entered bfcache", "the port was closed because you called disconnect". Sounds like we have general alignment on how to proceed.
   * [tomislav] I will also investigate what happens on the content script side.
   * [devlin] It would maybe be nice to send a disconnect event in the content script
   * [tomislav] Could dispatch an event on the same event loop as the page hide event.
   * [devlin] Challenge there would be whether it happens before or after the page hide event and I don't like either. If we fire it before, it's not clear why the ports are disconnecting (you're not in the cache yet) if we fire it after, you're already in cache and can't run code. I think the contract is after that event fires you don't get to run any more. I think it would be easiest to get a disconnect event on restoring a page.
   * [tomisalv] do you do it before or after the show event?
   * [devlin] I would think after.
   * [kiara] There haven't been any bugs reported with Firefoxes behavior?
   * [tomislav] Not to my knowledge.
   * [simeon] going back, I don't think script execution terminates after entering cache
   * [devlin] I think it does – otherwise, you could trivially have an always-running page in the cache, which is a security / privacy concern
   * [oliver] Would it be useful to expose bfcache entry/exit in webnavigation. oncompelted considered dispatching an event oncompleted.
   * [devlin]
   * [oliver] Gives devs a chance to see when the caching occurs and react.
   * [tomislav] Can't reliably reconnect from the background. Should be handled from the content script.
   * [devlin] you could reconnect from the background if you had events showing when a page enters or is restored from cache. That said, don't think we should introduce this functionality until its necessary. Don't think we should do this API until there's evidence that people need it.
   * [tomislav] Only bad thing about it is it's a change that potentially breaks current behavior. If this is how it behaved from the start, I agree that it's perfectly reasonable.
   * [kiara] I'll follow up on the Safari side.
   * [kiara] (follow up a few hours later): We believe that we match FireFox here and disconnect the port once the page enters the BFCache, but haven't tested. Regardless, we are in favor of matching what FireFox does and are in favor of not firing the onDisconnect event and seeing how extensions react to this behavior.
   * [devlin] Recap: For BFCache, on Chrome we're okay with immediately disconnecting. Going to find out what Firefox does in content scripts, but probably won't fire ondisconnect in content scripts. We could potentially introduce background events, but won't until there's evidence we need it.
 * [oliver] Service worker fetch events
   * [oliver] Chrome supports service workers and the ability to register a fetch event handler.
   * [devlin] Requests that go through normal web flows will hit this event handler.
   * [oliver] The two exceptions I can think of are requests initiated in the service worker. Content scripts. What else?
   * [devlin] scripting.executeScript with a file
   * [tomislav] Basically anything that uses a URL to access goes through the extension
   * [oliver] There are a small number of use cases for this event handler. Don't know if it makes sense to remove.
   * [tomislav] We don't currently support extension background service workers. I'm pretty sure we don't support registration of service workers for an extension because the protocol isn't supported.
   * [kiara] i don't think we support this either but can follow up
   * [devlin] It's logical to support fetch events. I don't want to hide the fact that it's a service worker. It just makes sense that this would work. I think it would be more surprising if it didn't. Developers might not intuitively know that you can.
   * [oliver] I don't think they don't know, I think it feels like there's undefined behavior.
   * [devlin] I think we can reasonably explain it. Finding a better way of saying "webby things go through the service worker, non-webby ones don't"
   * [oliver] Compelling use cases?
   * [devlin] Anything that SWs can do on the web except offline. Being able to dynamically serve responses is cool. Serving an API from your service worker.
   * [tomislav] even for one across the web with web accessible resources
   * [simeon] Can't do that for the web, though. Only handles fetch events on your own origin. You'd need foreign fetch for that. Maybe we can talk about bringing that back for extension service workers
   * [devlin] Let's… table that.


## Topics Parking Lot

 * WebAuthn and password managers [12 sep public session]
   * [WebExtensions should use asset links model for WebAuthn RP ID · Issue #238](https://github.com/w3c/webextensions/issues/238)
 * protocol_handlers field [oliver: spoke with Igalia attendee, they'll continue on the crbug]
   * [Support "protocol_handlers" in manifest · Issue #365](https://github.com/w3c/webextensions/issues/365)
   * [64100 - New Extension API: protocol_handlers - chromium](https://bugs.chromium.org/p/chromium/issues/detail?id=64100)
 * Standardization
   * browser.sidebar_action vs chrome.sidePanel [discussed on 13 sep]
   * Support for the browser object in Chrome [discussed on 12 sep]
 * Message Format 2
   [GitHub - unicode-org/message-format-wg: Developing a standard for localizable message strings](https://github.com/unicode-org/message-format-wg) [discussed on 13 sep, addendum 14 sep]
 * [oliver] BFCache [discussed on 14 sep]
 * [oliver + simeon] Service worker fetch events [raised on 13 sep and deferred]
 * Credentials API - allowing password managers to integrate with browser provided UI