Skip to content

Latest commit

 

History

History
121 lines (99 loc) · 9.95 KB

2023-06-22-wecg.md

File metadata and controls

121 lines (99 loc) · 9.95 KB
Raw

WECG Meetings 2023, Public Notes, Jun 22

  • Chair: Simeon Vincent
  • Scribes: Rob Wu

Time: 8 AM PDT = https://everytimezone.com/?t=64938f00,384 Call-in details: WebExtensions CG, 22nd June 2023 Zoom issues? Ping @zombie (Tomislav Jovanovic) in chat

Agenda: github issues

The meeting will start at 3 minutes after the hour.

  • Carry-over from previous meetings
    • Issue 394: [DNR] Add support for wildcards in initiatorDomains and excludedInitiatorDomains fields
  • Other new issues
    • Issue 399: setUninstallURL length update
    • Issue 400: Inconsistency: runtime.getManifest() and missing keys
    • Issue 401: Expose SHA256 value of DownloadItem
  • Open discussion queue (add yourself at the bottom)
    • None
  • Check-in on ongoing issues
    • Issue 282: Proposal: declaring background scripts in a neutral way

Attendees (sign yourself in)

  1. Rob Wu (Mozilla)
  2. Jason Waterman (Mozilla)
  3. Patrick Kettner (Google)
  4. Richard Worth (Capital One)
  5. Simeon Vincent (Incremental Software)
  6. Tomislav Jovanovic (Mozilla)
  7. Benjamin Bruneau (1Password)
  8. Dmitriy Seregin (AdGuard)
  9. Maxim Topciu (AdGuard)
  10. Carlos Jeurissen (Jeurissen Apps)
  11. Kiara Rose (Apple)
  12. Timothy Hatcher (Apple)
  13. David Johnson (Apple)
  14. Mukul Purohit (Microsoft)

Meeting notes

Issue 394: [DNR] Add support for wildcards in initiatorDomains and excludedInitiatorDomains fields

  • [rob] We have discussed this before. What's there left to discuss here?
  • [maxim] Last time we discussed this topic, I was asked to provide examples, which I did.
  • [simeon] I have to read the issue before I can meaningfully discuss this.
  • [tomislav] I asked for examples before, thanks for these examples.
  • [rob] Reviewed this in advance. I'm not against this. Open to implementing this in Firefox, but want to get cross-browser support before taking that on.
  • [patrick] No update on Chrome side. Still neutral on our side.
  • [timothy] I haven't had a chance to talk to our engineering folks on the WebKit side yet, so I don't have an update either.
  • [rob] We will pause this topic and resume once the browser engineers have had a chance to evaluate the feasibility of the request.

Issue 399: setUninstallURL length update

  • [patrick] Came up on a mailing list discussion. Bumped limit from 255 to 1023. Rob helped land a change in Firefox.
  • [patrick] Safari's setUninstallURL does not have any limit.
  • [simeon] Why 1023?
  • [patrick] Previous was 255 (256 - 1). Request was for > 300. This value covers the 98 percentile of URLs used in Chrome.
  • [patrick] Not sure if setUninstallURL does anything in Safari. I haven't got it to work.
  • [timothy] We recognize the key but don't do anything with it. In Safari, the extension is loaded from an app installed outside the browser, so the browser does not immediately know whether the extension is uninstalled.
  • [patrick] I can take the action item to update MDN to reflect Safari's current state.
  • [rob] Is this just temporary or an intentional long-term aspect of extensions in Safari.
  • [timothy] Due to our architecture it's not feasible to change this, and we have shipped this for 3 years.

Issue 400: Inconsistency: runtime.getManifest() and missing keys

  • [anton] Some browsers use undefined or null for undefined values; some browsers add extra attributes, whereas others don't.
  • [tomislav] In Firefox the return value is the parsed value of manifest.json.
  • [patrick] We were surprised that null is returned. The current documentation merely states that the return value is the deserialized value of manifest.json
  • [anton] if you call Object.keys() on the manifest, you will sometimes get a property name that has a value of null. In Chromium they use undefined.
  • [rob] Is there any impact?
  • [anton] Sometimes it's convenient to use this as feature detection for support of manifest keys.
  • [rob] Is there interest in browser vendors to drop unrecognized keys from the return value of runtime.getManifest().
  • [patrick] I believe that this is Chrome's behavior. (later in the meeting:) I just tested manually and observed that unrecognized values in the manifest.json are included.
  • [timothy] We return the raw value of the manifest.json.
  • [rob] Would you be interested in excluding unrecognized keys? Basically returning a parsed form of the manifest file.
  • [timothy] If everyone agrees we'd be in favor of that. Decent amount of work as we don't currently have JSON schema parsing like Firefox.
  • [rob] Calling back to discussion of unrecognized keys, it sounds like we shouldn't error on unknown keys (=extensions should not refuse to load). Combined with the discussion here, getManifest() should exclude unrecognized keys.
  • [timothy] Makes sense to me.
  • [tomislav] FYI we have default values for some complex values, e.g. empty arrays for content scripts. This is just an implementation detail.
  • [timothy] I will file a bug in Safari for this. The request to drop unknown keys is easier than returning the browsers' interpretation of the manifest.
  • [rob] Sounds more realistic than returning the representation, which is implementation-defined.
  • [partick] I'll follow up with the Chrome team.
  • [simeon] I expect this to be neutral to supported, but low enough priority to only be supported if an external contributor adds this.
  • [patrick] The original report here also refers to lack of documentation. Should we document this on MDN?
  • [simeon] Yes. That is the place for cross-browser documentation.

Issue 401: Expose SHA256 value of DownloadItem

  • [patrick] A request from Eric Law about including the sha256 in downloads.DownloadItem. Rob, you had a request to expose this behind a permissions. Can you share more?
  • [rob] I elaborated in a comment on the issue: Current implementation makes SHA 256 easier, but a function would make it easier to support other algorithms in the future. Potential privacy concern, which is why I want a permission even if we don't have a warning associated with it now.
  • [tomislav] Not a small thing. Need to consider domains for which you do/do not have host permissions for.
  • [patrick] Only open question I had was around supporting other hashes. Were you imaging an object that you'd pass in to request other hash methods?
  • [tomislav] For now it can be sha-256 and in the future we can add others.
  • [rob] We could add an explicit parameter for the hash. Even if we don't do that now, we can introduce it in the future.
  • [patrick] Don't anticipate pushback on that request. Is there anything you'd get from the SHA that you wouldn't get from the browser downloads return value?
  • [rob] Yes. You get the size in the download object, but the sha provides an oracle for the remote resource.
  • [patrick] Haven't participated when user facing warnings have been previously discussed. Is that a browser concern or a group one?
  • [tomislav] It's a browser decision, especially the choice of phrasing the warning message.
  • [rob] But if it's a concern for one browser it's likely for others as well.
  • [patrick] So we need to verify that we're okay with putting this behind a permission, that this is exposed with a function, and whether to have an options parameter. Is there anything else?
  • [rob] More things. Time of check and time of use issue. Do we want to check if this returns the hash of the downloaded value or the hash of the file on disk at time of call? What happens if the file is modified or deleted? Should be considered and specified.
  • [tomislav] Also an implementation design consideration because if it's time of download, this would have to be pre-computed.
  • [patrick] In Chrome I expect the hash to be provided by the implementation without reading the file again.
  • [rob] If the file has been deleted at some point, the API method could eventually reject with an error.

Issue 282: Proposal: declaring background scripts in a neutral way

  • [carlos] In the past we talked about accepting background.scripts and background.service_worker in one manifest. Is there any status update here?
  • [rob] Consensus was to not introduce preferred_environment, but to allow scripts and service_worker to co-exist. The main task there is for Chrome to not refuse the load of the extension when an extension. This is on Oliver Dunk's or my list of things to work on (I have contributed to Chromium's source before).
  • [carlos] What is the benefit for supporting both in a single manifest if browsers always default to service workers?
  • [rob] Cases where browsers don't support SWs. For example, Firefox currently does not support SWs in MV3 extensions. If a developer wants to target a specific execution environment, they can still differentiate using a custom manifest for that browser.
  • [carlos] Will Firefox offer support for selecting a specific key?
  • [rob] The cross-browser consensus is to use service_worker if specified and supported (currently: Chrome, Safari), and use event pages as a fallback when supported (Firefox, Safari). Background scripts that only use extension APIs should behave identically regardless of environment. If developers want to use event pages, they should drop the service_worker key from the manifest.

The next meeting will be on Thursday, July 6th, 8 AM PDT (3 PM UTC).