Ctrl+Click / Cmd+Click also opens in a new tab.
90 karma · joined October 12, 2019
It's not a huge improvement, but it sounds like one thing we could do to improve the communications process around build errors is to include a link to this documentation in the notification email sent to developers. I'll create a ticket for this now.
[1]: https://extensionworkshop.com/documentation/publish/source-c...
> Warning! The localStorage getter provides access to shared state. This specification does not define the interaction with other agent clusters in a multiprocess user agent, and authors are encouraged to assume that there is no locking mechanism. A site could, for instance, try to read the value of a key, increment its value, then write it back out, using the new value as a unique identifier for the session; if the site does this twice in two different browser windows at the same time, it might end up using the same "unique" identifier for both sessions, with potentially disastrous effects.
https://html.spec.whatwg.org/multipage/webstorage.html#intro...
For example, Firefox does not currently support the `optional_host_permissions` top level manifest key. To work around this, developers can declare their optional host permissions in both the `optional_host_permissions` array for Chrome compatibility and in the `optional_permissions` array for Firefox/Safari compatibility.
Another example is that currently only Chrome supports `background.service_worker` in stable releases. To work around this, developers can write their MV3 background scripts in a way that's compatible with both service workers and event pages, then declare both in the manifest like so:
```json { "background": { "scripts": ["background.js"], "service_worker: "background.js" } } ```
At the moment I don't believe any browser has features that notify end users of ownership changes.
[1]: https://support.google.com/chrome_webstore/contact/one_stop_... [2]: https://extensionworkshop.com/documentation/publish/add-on-o....
While what you described is possible, this process isn't required or the typical way an extension ID is generated. Typically developers just upload a ZIP file on their first submission, then CWS will generate and store a private key to sign the extension for public distribution.
> and the ID will change if any subsequent uploads include a different key.pem in their zip file
CWS should never change an existing extension's ID. The ID is what I uniquely identifies an extension. If the ID changed, Chrome clients wouldn't be able to request an updated version of that extension. CWS & Chrome do not support migrating users from one extension to another.
To the best of my knowledge CWS will reject an extension if the zip after the first submission contains a key.pem file.
> Therefore, if the extension ID changes, it's possible the owner changed.
If the extension ID changes, it's not the same extension.
> then the new owner could push changes without even needing access to that key.
This is mostly true, but there is one case where developers CANNOT update an extension without the PEM: if the dev signed the extension they submitted to CWS. To be honest I'm not even sure this is possible to do any more; as I recall this feature was a huge foot-gun and often ended up causing developers to lose their install base because they lost their private keys that they used to sign their own uploads.
While they solve similar problems, these are different systems with different constraints.
* In order to allow something through the review process without close examination, you need to be sure it will not compromise end users. The block, allow, and allowAllRequests actions are known to present minimal risk to user's web browsing activities. The same cannot be said for redirecting requests or modifying a request's headers.
* Dynamic rule registration logic can be statically analyzed for risk assessment purposes. For example, say you're looking at two extensions that both have dynamic rules. Extension A only dynamically register block rules based on remote configuration. Extension B has <all_urls> and passed an arbitrary JSON object to the updateDynamicRules call. Personally, I'd be very concerned about what Extension B could do at the developer's behest, whether intentionally or if the dev's servers are compromised. IMO Extension B may even cross the line on what store policy permits.
* Expectations for extension's static content are different from an extension's dynamic operations. If an extension has code that explicitly does something nefarious and that passes review, the review process will be raked over the coals by commentators. If an extension's static contents are benign but a developer makes it do something nefarious at runtime, there is more understanding that this behavior may not have been visible to reviewers during the review process.
I'm sure there are more differences worth mentioning, but I need to run.
As a final parting thought, if safe rules and fast track review were already implemented and dynamic rules were being proposed today, I expect we'd be having conversations about whether or not devs should be able to register unsafe dynamic rules. I think there's a realistic possibility that we wouldn't allow it. Or if we did, that this capability would be gated by a new permission with a warning.
Normally when browser folk talk about "cross-browser extensions," we're not focusing on the distributable package so much as the source code. As you suggest, there are a variety of reasons that browsers aren't terribly interested in having a single authoritative distribution channel. For that matter, the packaging format is explicitly not something we intended to discuss in the WebExtensions Community Group[1]. While we diversity in how extensions are marketed and distributed, we want the actual code of the extensions to be as reusable as (reasonably) possible.
A bit off topic, but as a co-chair of the WebExtensions Community Group[1] (WECG) I'm a bit touchy about the calling WebExtensions "standardized." A few years back the Browser Extensions Community Group[2] created a spec for WebExtensions, but it never reached a state that we'd normally refer to as a web standard. (Technically W3C community groups can only produce "Reports" and these documents are not on the standards track.[3])
FWIW, I'm very bullish about specifying and (hopefully) standardizing the WebExtensions platform. I'm especially excited about having a good chunk of dedicated time to sit with browser folks at TPAC 2023[4] and try to work out some open questions about where we're going and how we're going to get there.
[1]: https://github.com/w3c/webextensions/ [2]: https://browserext.github.io/ [3]: https://www.w3.org/community/about/faq/ [4]: https://www.w3.org/2023/09/TPAC/
It's a work in progress: https://bugzilla.mozilla.org/show_bug.cgi?id=1609923
> I decided to keep two foo-manifest.json versions in a manifest/ subdirectory, and copy one to ../manifest.json depending on which browser I'm testing. It's a bit tedious. Not sure if a better solution exists.
Personally, I favor having a build step that produces the final manifest. The basic idea is that you have a common manifest.json + paired down browser-specific files that override the general settings as necessary. It's not a perfect solution, but I think it makes maintenance a bit easier.
IMO something of value changes with every release. For example, in the most recent release (105) Chromium gained support for container queries and the :has() pseudo-class. Container queries allow web devs to change how styling is applied the contents of an element based on the size of the element itself. That's a major new tool for web developers & designers. 105 also supports the HTML Sanitizer API, which relieves the need to use libraries like DomPurify to protect against XSS attacks.
If you're interested in digging into what changes in each release, Chrome has a blog post series called New in Chrome[1] that summarizes changes. And to dive even further into changes, the Chrome Status[2] site allows you to filter platform feature changes by release milestone.
[1]: https://developer.chrome.com/tags/new-in-chrome/ [2]: https://chromestatus.com/features#milestone%3D104
[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=113549...
We discussed Chromium's current plan to support user scripts managers in Manifest V3 during our WebExtensions Community Group (WECG) session at TPAC[1] last week. The notes for that meeting haven't been merged yet, but there's an open PR[2] and when they are they will live here[3].
In short, the current plan in Chromium is to require end users and extension authors to opt into execution of arbitrary scripts via a Chromium UI setting and new permission, respectively. During the meeting Firefox folks raised some questions/concerns about this plan and it's probably best to try to align with them on next steps if possible.
And typing this out is making me realize we don't have a great tracking issue for this in the WECG repo. Just threw together a placeholder issue[4] to track discussion in this area.
[1]: https://www.w3.org/events/meetings/7bbba4a3-8305-45cd-a998-6...
[2]: https://github.com/w3c/webextensions/pull/277
[3]: https://github.com/w3c/webextensions/blob/main/_minutes/2022...
In short, an offscreen document is a temporary headless page that is instantiated for a given reason that requires DOM access. It is not meant as a long-lived background context.
[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=133938...
https://developer.apple.com/documentation/safariservices/saf...
First up, no, you don't need to maintain two completely different code bases. I'd recommend having a separate manifest.json for each browser or having a build step generate the per-browser manifest.json. A lot of the manifest changes are relatively small, like splitting "host_permissions" out from "permissions" and should be automatable. For example, a build step would merge these two arrays for the MV2 manifest.
As for your background scripts, if possible I'd recommend limiting the JS capabilities you use to the intersection of what all browsers support.
- Chrome supports background service workers - Safari supports event pages and I believe has service worker support in beta builds of their OSs - Firefox supports persistent background pages
In other words, target the capabilities available in both worker and page contexts. You'll also want to design your background logic to embrace ephemerality. This is required by Chrome, but it also benefits Firefox users in that it helps keep the browser responsive.
Best of luck!
Defaults matter. Based on what they've shared so far developers must qualify for and choose to enroll in this system. In other words, Apple isn't charging 15% for small businesses, they're charging 15% for Small Business Program participants. That's an important distinction.
It's also worth mentioning that if you have transferred an app to or from your developer account for any reason, you're not eligible for this program. https://developer.apple.com/app-store/small-business-program...