Skip to content

Latest commit

 

History

History
464 lines (432 loc) · 34.8 KB

2024-09-24-wecg-tpac.md

File metadata and controls

464 lines (432 loc) · 34.8 KB

WECG TPAC Sep 24, 2024

Agenda

Tuesday: https://github.com/w3c/webextensions/wiki/TPAC-2024-Coordination#tuesday

  • 09:00 - 10:30
    • [5 min] Agenda review
    • [45 min] Experimental APIs
    • [55 min] Community prioritization of medium-scoped features we've all agreed are reasonable (Oliver)
  • 11:00 - 12:30
    • [90 min] Leads sync (closed session)
  • 14:00 - 15:00
    • (original agenda canceled due to power outage)
  • 15:00 - 17:00
    • [120 min] Issue triage & backlog cleanup

Attendees

  • Rob Wu (Mozilla)
  • Christos Bacharakis (Eyeo)
  • Timothy Hatcher (Apple)
  • Kiara Rose (Apple)
  • David Johnson (Apple)
  • Elijah Sawyers (Apple)
  • Brian Weinstein (Apple)
  • Simeon Vincent (Mozilla)
  • Mukul Purohit (Microsoft)
  • Devlin Cronin (Google)
  • Carlos Jeurissen (Jeurissen Apps)
  • Oliver Dunk (Google)
  • Patrick Kettner (Google)
  • Jordan Spivack (Capital One)
  • Casey Garland (Capital One)
  • George Henderson (Capital One)
  • Tomislav Jovanovic (Mozilla)

Notes

Session intro

  • [oliver] Yesterday we met with the Internationalization group, about i18n.getPreferredSystemLanguages and others. If the API name has user preferences in it, we should return the user preferences and not the default. Also talked about MessageFormat2. They are going to join us on Thursday.
  • [rob] FYI I met with James Graham from the Browser Tools and Testing group, because there is a PR about adding installation of extensions to WebDriver-bidi at w3c/webdriver-bidi#778. We'll meet with them on Thursday.

Experimental APIs

  • [devlin] Recap of experimental APIs. experimental namespace in Chrome has baggage, prefer not using it. How to introduce experimental APIs without avoiding namespace conflicts in the future? Options include namespacing, suffixing APIs (e.g. Private suffix in Chrome).
  • [timothy] Are these on by default in shipping?
  • [devlin] Depends on definition in shipping.
  • [timothy] Enabled by default in Canary.
  • [devlin] Recent example, e.g. prompt AI, which they would like to eventually be exposed on the web. But they want to prototype as an extension API first and remove later. How to do this without long-lasting impact on extensions? Currently has a long name I can't recall. Another example is experimental AI data API. Intended to be used by anyone, but currently requires a CLI flag.
  • [timothy] All experimental features in Safari/WebKit have experimental flags, mostly disabled by default. Having a way to toggle them is a go-to, not name prefixes.
  • [devlin] (...) AI data API example not enabled by default in production. Prompt AI expected to need a different toggle, for use in extensions. Having a toggle does not preclude collisions. Segmentation here is valuable here.
  • [timothy] What about underscore prefixes?
  • [devlin] Typically used for internal / reserved use.
  • [simeon] What if extensions can input their custom name, for the API/namespace?
  • [devlin] Biggest issue is requiring a CLI flag.
  • [simeon] Thinking of about:config in Firefox for example.
  • [devlin] Would not work for all extensions.
  • [devlin] Personal preference right now is a new namespace, but differently than “experimental”.
  • [patrick] e.g. chrome.temporary.
  • [devlin] E.g. “chrome.donotusethis”. Name to discourage usage and emphasize that it may be temporary.
  • [patrick] If the goal is to discourage people from using it, the name should be verbose and clear, e.g. chrome.experimentalThisWillGoAwaySoon.
  • [simeon] browser.THIS_IS_EXPERIMENTAL.
  • [timothy] E.g. “unsafe” or something like that.
  • [devlin] Long and verbose sounds good, but some of them would probably not go away. Internally the Chromium code base sometimes include “DoNotUse” suffix to deprecate/discourage, but there may still be valid remaining use cases.
  • [patrick] Maybe names like chrome.thisWillGoAwayBySomeDate
  • [devlin] Could incorporate the second bucket into the API namespace.
  • [jordan] How about “unstable”?
  • [devlin] Good candidate. Exact name does not matter. Can bikeshed async.
  • [devlin] Do we want to use the separate bucket idea for this?
  • [simeon] And this is independent of yesterday's discussion on origin trials, right?
  • [devlin] Yes, yesterday is about APIs that we do not have the intention of breaking, this is about APIs that we do not want to ship to stable.
  • [rob] To clarify, this is for features that we don't want to ship to stable?
  • [devlin] Not mainline, may still reach stable release channel.
  • [rob] What would be the extension store policy for accepting these?
  • [devlin] Store decision per API. There may be some that we want to expose publicly. That's part of why we can't use experimental – the experimental permission is auto-rejected.
  • [rob] When I asked my team about names, “trials” was one of the suggestions for the namespace. It is not verbose though.
  • [devlin] And may be confused with origin trials. I prefer alternatives such as “unstable”, “exploratory”.
  • [devlin] Tentative decision: use a namespace (name to be selected) for experimental APIs. I'll take the action item to write this up.
  • [devlin] Would other browsers expect adoption?
  • [timothy] Yes, would be useful.
  • [rob] Yes.
  • [devlin] To what extent do we want to raise these in the WECG? On Chrome's side it may be a FYI.
  • [timothy] Heads-up would be good. E.g. “Do you have plans for names in this road”, to avoid sidebar/sidepanel issue.
  • [david] Since we are thinking of this as likely not conflicting, do we want to think this as reserving a namespace where each browser can do something on their own?
  • [devlin] That's what it will likely end up being. Hopeful we won't collide, but should communicate to devs that if it happens it doesn't necessarily mean anything.
  • [simeon] A challenge there is that there is no reliable way to distinguish browsers.
  • [devlin] Almost no developer should be using this API unless they really want to use this API. Separately, I appreciate the challenge of identifying the browser, we should discuss how to address it later.
  • [carlos] Reliable way is to check the protocol of the origin (chrome-extension, moz-extension, etc.)
  • [oliver] Even more so, between browser engines we should give heads-up. E.g. no two Chromium forks with the same name.
  • [devlin] My stance is that if extension developers are using these APIs, they should exactly know what they are doing. It should target specific browsers.
  • [patrick] The idea is that these APIs would not be added to main extensions.
  • [rob] As an extension developer, I often look for a way to accomplish my goal and will use whatever API is available to accomplish it.
  • [devlin] If you're truly determined and your users are truly determined, then you can do it, but if that doesn't work in a fork I have limited sympathy.
  • [simeon] I am not convinced; are you saying that a large extension with large user bases should fork their main code base into a separate extension to use such APIs?
  • [devlin] … For example, with the experimental AI API we are planning to fully remove it.
  • [rob] Would you consider timebombs in API? Auto-disable a namespace after a certain date, and require extensions to put the expected time in the manifest.
  • [devlin] Could be considered on a per-API basis.
  • [rob] Recap?
  • [devlin] Seems we're aligned on browser.<SOMETHING> (namespace to be decided). (…)
  • [rob] What prevents APIs added to this namespace from becoming de facto required to be implemented in other browsers, due to Chrome's market share?
  • [devlin] Main thing is that anything requires some form of toggle, to prevent use by arbitrary extensions.
  • [timothy] Goes with notifying other browsers of experimental APIs. Gives a chance for us to call out conflicting names/plans.

Action items

  • [devlin] Propose concrete naming, attributes of new namespace bucket, process for new things getting added, and create an issue (first)
    • [rob] I created: Issue 702: Namespace for experimental APIs

Community prioritization of medium-scoped features we've all agreed are reasonable

  • [oliver] Conversations in Chrome, about medium-priority feature requests, that we think would be useful to do, but no time to implement yet. E.g. runtime.onEnabled, userScripts.execute. We have an internal list, but it may not match an external list. Idea is to get a separate list. E.g. we could spend time on listing issues today and discuss which to focus on.
  • [oliver] Perhaps we can search for supportive:chrome supportive:safari supportive:firefox in our Github issues?
  • [timothy] That would exclude implemented:safari labels.
  • [rob] OR is supported with commas, e.g. label:”supportive: chrome”,”implemented: chrome”
  • [oliver] I added a “Community Interest” section to this document; interested extension developers could provide suggestions here. 10 minutes.
  • [timothy] Maybe anything implemented in one to implement in another?
  • [devlin] I don't think that you mean that.
  • [timothy] Things like storage.getAllKeys()
  • [devlin] Would be an attribute that adds value, but not automatic.
  • [rob] browser namespace is not in the query output, but I think that it is one area that Chrome could work on for cross-browser. w3c#532
  • [rob] Historically we have not been good to close issues. Since #369 (extensions' ability to block requests from other extensions in DNR) is universally implemented, I suppose that we can close this now?
  • [devlin] Yes.
  • [timothy] Yes.
  • (everyone collects issues)
  • [oliver] Everyone votes on three topics, below.
  • (discussion notes included in the list below)
  • [oliver] I'll make sure that everything on this list is also represented internally.

Candidates

  • icon_variants (for Chrome, Firefox?) #229
    • Capital One (Casey)
    • Oliver Dunk
  • Proposal: Decode regexFilter matches in Declarative Net Request as query parameters #636
  • User Scripts toggle in chrome://extensions instead of developer mode requirement
    • TL;DR: Instead of requiring developer mode, we could introduce a per-extension toggle in the "details" page for the extension, similar to "allow on file URLs" and "allow incognito"
    • [rob] Who put this here? Do we have an issue tracking this?
    • [devlin] Me, no issue yet; in response to developer feedback in the mailing list
  • runtime.onEnabled / runtime.onExtensionLoaded #353
    • Votes
      • Sim
      • Capital One (Casey)
      • Mukule
      • Christos
    • Notes
      • [simeon] There is currently no way to do this.
      • [rob] In my extensions I use the storage.session API for this - read storage.session, run (async) initialization logic, save flag.
  • Use match_origin_as_fallback by default for scripting.executeScript #673
    • Kiara
  • Support Promise as return value from runtime.onMessage callback #338
    • Oliver Dunk
    • Capital One (Jordan)
  • Proposal: Add alias for tabs permission #619
  • Proposal: StorageArea.getAllKeys() #517
    • Christos
  • sidePanel API: sidePanel.close() and sidePanel.toggle() #521
  • Extensions API to query the current browser theme #680
    • [devlin note] May not be straightforward
  • Determine the nuances of aliasing chrome and browser #532
    • Oliver Dunk
    • Rob Wu
    • Capital One (Jordan)
  • Inconsistency: Persistence of alarms in browser.alarms API #406
    • Capital One
    • Rob Wu
  • Add API to switch focus from sidePanel to main document to enable accessibility features #693
  • Proposal: declaring background scripts in a neutral way #282
    • Votes
      • Timothy
      • Brian
      • Jeurissen Apps (Carlos)
      • Kiara
    • Notes
      • [devlin]: preferred_environment is unlikely to be implemented in Chrome (since we only support SWs)
      • Carlos: But Chrome could support scripts array and generate a SW script
      • Devlin: Ack; let's talk more
  • Introducing browser.i18n.getOSLanguage #252
    • Votes
      • Jeurissen Apps (Carlos)
      • Timothy
      • Mukul
      • Capital One (Jordan)
    • Notes
      • [oliver] Any use cases?
      • [jordan] Internationalization purposes.
      • [simeon] Is there a meaningful difference between OS and browser language? Capital One?
      • [george] We don't have a localized extension currently, so this is future-facing.
      • [oliver] Far to say that this is a lower priority?
      • [capital one people] Yes.
  • Proposal: i18n.getLanguageDictionary #274
    • Votes
      • Jeurissen Apps (Carlos)
      • Timothy
      • Simeon
      • Capital One (Jordan)
    • Notes
      • [oliver] Similar to getOSLanguage in terms of priority.
        • Carlos: For capital one it seems? Not for other developers/companies

Issue Triage

Candidates for Discussion

Criteria:

  • Issues should be things we can discuss and make progress on in 5 - 10 minutes
  • Goal is triage, not necessarily completion or resolution
  • Candidates types
    • Determining general browser supportiveness for small - medium issues
    • Updating labels on existing issues (e.g., marking as implemented)
    • Closing out issues that are fixed or WontFix
  • Avoid
    • Discussions of entire new API namespaces (unless proposing we WontFix them)
    • Fundamental changes to the platform

Discussed issues

  • Issue 693: Add API to switch focus from sidePanel to main document to enable accessibility features
    • [devlin] What would switching to the main document look like?
    • [carlos] Switching tabs causes the tab to be focused again.
    • [simeon] Firefox does that too.
    • [rob] Would we introduce a new method to focus the main content area?
    • [devlin] Basically yes. Another question is whether to focus individual frames too.
    • [timothy] Focusing the tab focuses whatever frame was focused last.
    • [devlin] Allowing developers to control focus very directly can potentially cause clickjacking issues.
    • [simeon] Jackie mentioned that the sidebar is not focused when it is opened. I don't think that we need a general API to focus the sidepanel.
    • [timothy] Opening again should be OK.
    • [oliver] If there is a field in a page, and you close the sidepanel, it does not focus the input field again. I would expect some focus to be remembered.
    • [devlin] I would envision this to be an API on tabs, not sidepanel.
    • [simeon] Focus here is on focusing the window, not the sidepanel.
    • [rob] I think that we do not need to specify the focus behavior too closely, following the defaults of the browser would make sense.
    • [rob] If the address bar was focused and you call this method, what happens?
    • [devlin] It focuses the main content in the tab (document tree in Chrome, webview in Safari) - whatever was the active frame is focused.
    • [oliver] Same question with popup.
    • [devlin] I expect the popup to be closed.
    • [devlin] I have more concerns with stealing tab focus.
    • [timothy] We could require a user gesture.
    • [oliver] Should we make it so the side panel gets focus when it first opens?
    • [devlin] Yes, I would lean towards this.
    • [timothy] And calling open when it was already open, focuses.
    • [devlin] Maybe?
    • Resolution: Add method to focus tab (tabs.focus()), opening sidebar should focus the sidebar, possibly even when it was already open.
    • Action item: Oliver to reply on issue
  • Issue 689: I hope browsers can provide an API to hide/show the bookmarks bar
    • [devlin] Not interested in doing this.
    • [simeon] Firefox supports the browserSettings API. Rob, thoughts?
    • [rob] Use case?
    • [devlin] Screen sharing.
    • [rob] What they could is modify the video to remove the content.
    • [timothy] Use case is video streaming in general, more content would have to be culled than just bookmarks bar.
    • [devlin] Not much appetite on the Chrome side to allow extensions to hide browser UI. I see utility in the use case, but that is not something we would write an extension API for.
    • [timothy] You could almost do this now with window.open and fiddly window flags.
    • [devlin] If you wanted a clean demo of a feature in the browser, reducing chrome wouldn't serve you.
    • [devlin] The class of issues - customize browser - is within the realm of extensions. The specific user-facing sessions are not user controllable. Exceptions exist, such as privacy features. Core browser settings cannot be modified.
    • [simeon] I can get onboard with that for the bookmarks bar, how about management API to manage the pinned state of extension button.
    • [devlin] Don't love the management API in general. Don't particularly like having extensions manage the install or disable state of extensions.
    • Resolution: Chrome/Firefox/Safari opposed, Close as won't fix. Enterprise policy can manage pinned state.
    • Action item: Devlin to reply on the issue [done]
  • Issue 694: [DNR] in opposition to webRequestBlocking, declarativeNetRequest rules are not applied if the request is redirected
    • [rob] Firefox's behavior makes sense IMO - it is a different request.
    • [devlin] Agreed. We fixed it in DNR.
    • [rob] Is Chrome's webRequest behavior intentional?
    • [devlin] No
    • [rob] DNR and webRequest share the backend in Chrome, is the observed result really accurate?
    • [devlin] Yes they share the same stack, should check again.
    • Action item: Devlin to confirm that the headers should not be added from webRequest
    • Action item: Brian to confirm that DNR does not add headers in Safari after a redirect.
      • [brian] It appears DNR in Safari adds the headers to redirect.
  • Issue 274: Proposal: i18n.getLanguageDictionary
    • [carlos] We talked about the proposals yesterday; Rob was in favor of async initialization and then allow synchronous getMessage.
    • [rob] Could we address this by switching the language across all contexts.
    • [carlos] Could have a content script that you want to match the page content.
    • [rob] Is that a use case that should have first-class support in extension APIs?
    • [carlos] Being able to use it could enable re-use.
    • [devlin] Don't like the pattern of set, get message, set back. Creates some raciness.
    • [devlin] Don't think this is the right time to introduce custom return types in extension APIs. It doesn't introduce new performance issues – getMessage is already sync.
    • [rob] I'm surprised that it would not introduce perf issues - the languages may not be available in memory.
    • [devlin] That's why I said new issues.
    • [oliver] How does that work with fallbacks? Do we collapse it all into one bundle?
    • [timothy] That is what we do.
    • [oliver] My understanding was Firefox would only support this asynchronously.
    • [rob] We could do it sync if we want to by blocking the content process, but that is not good design. The perf issue is not present with the default language, because the locale data can be computed in advance and be shared with all processes via shared memory.
    • [timothy] That's essentially what we do.
    • [carlos] In theory it would only need to block the first time.
    • [oliver] For proposal D, either this is synchronous and the browser handles blocking behind the scenes, or this asynchronous and the developer needs to wait for promises to resolve building their UI. Would rather the complexity be on the browser side.
    • [devlin] Rob, how opposed are you with synchronous getmessage with a locale param?
    • [rob] Can be convinced, but don't think it's a great design. Every new locale creates a blocking lookup. It's like sync XHR. It exists, but we'd rather it didn't.
    • [devlin] There's no utility in calling it for 100 languages. Sync XHR has *lots* of utility.
    • [rob] Can we make this opt in via a permission? Seems not great for every extension to be able to do this.
    • [devlin] Would be opposed to a permission.
    • [oliver] Would hope this will be fairly quick.
    • [timothy] If a spinning disk is involved we're potentially fetching 4 files from disk.
    • [devlin] (...) Can cache results in the renderer process for the duration of the session.
    • [rob] Not a question of *can* it be sync, but *if* it should be sync. How would a developer know when the pessimistic case will happen?
    • [devlin] If we're talking about augmenting getMessage or returning a dictionary of strings.
    • [rob] How would Safari feel about a permission?
    • [timothy] Not applicable to our implementation due to auto-grant of permissions.
    • [rob] I'll go with a neutral position if we are going with sync getMessage + locale option..
    • [devlin] Carlos, do you need this in a content script?
    • [carlos] Yes.
    • [oliver] For clarity, what do you mean by neutral, Rob?
    • [rob] I don't like the design, but if everyone else implements it we likely will as well.
    • [carlos] What's the concern with custom data types?
    • [devlin] Don't have an existing pattern in Chromium of returning objects that aren't plain JS. There are a lot of other questions that this raises: can you instantiate your own objects, can you modify the prototype chain, (...)
    • [devlin] Carlos, for the suggestion of returning a function, I think returning a dictionary is more natural. Would be open to B.
    • [timothy] I'm open to B
    • [simeon] I prefer B because it makes the async operation clear and provides sync access to data after.
    • [oliver] For clarity, B would be a plain JavaScript object with property values that are the resolved strings, correct?
    • [devlin] Yes.
    • [simeon] For clarity, how would substitutions be handled in the returned object?
    • [timothy] The return message format strings.
    • …
    • [oliver] If a developer decides that our message format isn't robust enough, they could use their own string resolution algorithm in combination with MessageFormat2
    • [devlin] We are well beyond triage at this point. Let's move on.
    • Resolution: Chrome/Firefox/Safari supportive of option B.
  • Issue 646: userScripts API: method to get matching ids for a URL
    • [devlin] There is a work-around, but not perfect.
    • [timothy] If this were to be added, it should be on scripting. I voiced it before, userScripts should have been in scripting.
    • [devlin] Rob, if I understood your comment, it is basically a URL does not equal injection.
    • [rob] Yes.
    • [simeon] Is the hesitation that the proposal target by URL and not documentId or another concept?
    • [rob] Might not always have a URL or tab.
    • [rob] userScripts API does not support match_origin_as_fallback.
    • [devlin] We could add it to the userScripts API too.
    • [oliver] Another option is a method to get contexts that have been injected into, which would take some kind of context parameter.
    • [devlin] Tophf proposed get matching IDs for a URL, you noted that URL is insufficient to target. Is there an alternative?
    • [rob] I suggested more targeting information.
    • [devlin] Sounds like you're saying “given this set of conditions, what scripts would be injected?” But that's not quite what's being requested. They don't want to guess what might be injected, but to know what has been injected.
    • [rob] Match patterns and glob patterns could help. A script may match but not inject. Devlin noted that match origin as fallback is not supported, but could be.
    • [devlin] Even if we add match patterns and glob patterns and so on, but the use case is to know what has been injected. Asking the developer to climb the frame tree to get all the context, that sounds unnecessarily complex.
    • [oliver] We've discussed getContexts in the past. If we included both content and user scripts, would that address it?
    • [devlin] With user scripts there can be multiple injected in separate worlds in the same page.
    • [rob] When a script is injected, there's no trace.
    • [devlin] Impl detail, you could trace it.
    • [rob] Stepping back, are we in all inclined to add a method that returns whether scripts are injected in a specific frame/document?
    • [devlin] Should either have two places or a unified method. Setting aside the namespace and method name, we should have a way to get the scripts that are injected into a given frame/tab/frametree/etc. We should figure out naming, namespacing, properties, etc. later.
    • Action item: Devlin to reply on the issue [done]
  • Issue 533: Enhance browser.storage.local to allow storing binary data directly
    • [oliver] As a note, session storage is unique in Chrome. Due to how we implemented it we do support a larger range of data types than we do in other storage areas.
    • [timothy] Interesting to know, we do not. We use an in-memory SQL database.
    • [oliver] We use a key-value store.
    • [rob] On Firefox side we use structured clone for storage.session.
    • [oliver] How hard would it be in Chrome to implement this?
    • [rob] IndexedDB also supports structured cloning, which you also support.
    • [devlin] Extension storage is not great. Would prefer web APIs.
    • [oliver] Not all features are available in service workers.
    • [devlin]
    • [timothy] We prefer extensions to use extension storage. Mostly for tracking purposes, we have different APIs, clearing extension storage is clearly attributed to extensions. I'd like us to explore structured clone. That said, we haven't seen much demand for it, that's why it is not a priority.
    • [devlin] It is less a (...). The more we make chrome.storage not suck, the more people would use it and its performance isn't great.
    • [oliver] So we are neutral?
    • [devlin] No inherent objection to it, but I don't know if we are going to do it anytime soon.
    • [oliver] Commented.
  • Issue 534: Inconsistency with indexedDB in browser extensions
    • [devlin] (reading issue description out loud)
    • [devlin] Sounds like Firefox is effectively running permanently in incognito mode when “Never remember history” is enabled.
    • [rob] Yes.
    • [oliver] I'm not familiar with never remember history. If I went to 3 sites and went to the History viewer, I wouldn't expect to see data.
    • [rob] Extensions are not enabled in private by default. Never remember history is a sort of permanent private browsing.
    • [devlin] I think Oliver is mostly saying the naming is weird.
    • [devlin] What's the right behavior for extensions with web storage in private / regular mode for Safari. I don't like the idea of clearing web storage outside of Incognito mode.
    • [rob] That's not what the table in the issue is saying.
    • [timothy] Safari clears IndexedDB data when an origin is not used after 7 days.
    • [devlin] They are looking at spanning mode. Not clear what happens with split.
    • [devlin] With split mode, if you store data in web APIs while in incognito mode, when you close the incognito session the profile is deleted and therefore so is the data. Mostly true that this is a feature as it allows extensions to store data in web storage that behaves like the web context does, but persistent data can be stored in extension storage.
    • [rob] Does Safari support split?
    • [timothy] No. The table is correct.
    • [rob] Firefox also does not support split. Only recently added the ability for extensions explicitly marked as split to load.
    • [devlin] Does anyone have interest in implementing split mode?
    • [timothy] No one has asked for it.
    • [rob] Not a priority.
    • [devlin] In that case, the behavior we'd expect is for a spanning mode extension web storage is persisted but in split incognito the regular
    • [rob] The underlying issue is that developers want a reliable way of storing data in IndexedDB.
    • [devlin] We're largely happy with Chrome's current behavior of keeping web data in spanning mode, destroying it in split. Seems like Firefox needs to decide what the extension behavior in general when “never remember history” is enabled.
    • [rob] Never remember is permanent private mode, so destroying data is appropriate. Any appetite for providing a way to get a persistent indexedDB session?
    • [devlin] No.
    • [tomislav] I think Devlin is saying Firefox is free to handle this however it wants given the lack of consistency.
    • Resolution: None!
    • Action item: Devlin to add rationale for current Chrome behavior [done]
    • Action item: Firefox to decide how they want to handle IndexedDB in “never remember” mode.
  • Issue 570: Inconsistency: dns.resolve()
    • [oliver] Only action item here was to check with the Chrome security team to see if we could expose our existing dns API implementation. I haven't done that and will try to do it in the future.
    • Action item: Oliver to follow up.
  • Issue 507: Support $schema in manifest.json
    • [devlin] What's the request?
    • [carlos] Allow extensions to use a “$schema” key in the manifest.
    • [oliver] Doesn't throw an error, but does return a warning.
    • [david] There seems to be some confusion. Users reported that it threw an error when uploading but later stopped returning an error.
    • [carlos] There are more keys that could raise warnings. Like browser_specific_settings.
    • [oliver] Browser specific settings is a feature we don't support, but has some value elsewhere. “$schema”
    • [devlin] we warn on browser_specific_settings because we don't support it. Developers try to specify it expecting it to … Sorry, was thinking browser overrides, not browser specific settings.
    • [rob] Would you consider not warning on browser_specific_settings?
    • [timothy] Safari also uses it.
    • [devlin] Open to it.
    • [devlin] Back to this issue, hesitant to support arbitrary fields used by some random tools. Worried about proliferation of everyone's pet keys.
    • [timothy] $schema is a standard.
    • [tomislav] Agreed with reasoning.
    • [devlin] If this is used by a large amount of the community, I'm in favor of ignoring it.
    • [rob] So we are committing to maintaining a list of intentionally recognized properties even if ignored, starting with browser_specific_settings and $schema.
    • [devlin] Yes.
    • [rob] There is already a Chromium issue for this at https://issues.chromium.org/issues/40196501.
    • Resolution: Agreement that $schema should not be warned about.
    • Resolution: Chrome to intentionally ignore browser_specific_settings and $schema instead of warning.
  • Issue 115: Proposal: move browser specific settings to browser_specific_settings
    • [rob] Are you neutral or opposed towards adding chrome to browser_specific_settings?
    • [devlin] What is put there?
    • [rob] E.g. putting strict_min_version.
    • [timothy] We use it in that way too.
    • [rob] Chrome could then add a browser_specific_settings.chrome.strict_min_version key with the semantics of minimum_chrome_version.
    • [devlin] No objections, would not be a priority to implement.
  • Issue 12: request: allow to retrieve a frameID from an <iframe> element
    • No updates; Oliver to follow-follow-up
    • Action item: Oliver to follow up
  • Issue 8: executeScript API may inject scripts in an unexpected target at runtime
    • [rob] Chrome has implemented documentId, so could we put chrome: implemented here, and supportive in Firefox and Safari?
    • [devlin] Sounds good to me.
    • [rob] I've updated the labels.
  • Issue 1: What to do with the older CG?
    • Resolution: Timothy to handle the proper procedure to update pointers and close the group
  • Issue 483: Proposal: API to embed pages in WebExtension bypassing CSP
    • [devlin] What's the CSP we need to bypass
    • [oliver] frame-ancestors
    • [devlin] I'm good with bypassing all of that
    • [oliver] I need to create a proposal for this.
    • Resolution: Oliver to create a proposal.
  • Issue 688: dev_permissions / self_permissions key in manifest
    • [devlin] Request here is support for a manifest key.
    • [rob] optional_permissions could be used.
    • [devlin] Or a separate build.
    • [simeon] Is there interest for other browsers to support them as optional?
    • [devlin] Yes, I am supportive of making all permissions optional.
    • [rob] So our consensus is to not support this, and encourage a separate build or optional permissions?
    • [devlin] Yes, and support all permissions as optional where feasible.
    • Resolution: Close
    • [devlin] Jordan, are you okay with this resolution?
    • [jordan] Yes.
    • [simeon] Closed & commented.