Updates about the webextension-polyfill - #2401
Conversation
| ### WebExtension browser API Polyfill | ||
|
|
||
| When creating extensions you want to work in Firefox and Chrome, this library enables you to use the Firefox Promise-based APIs and have them run on Google Chrome with few, if any, changes. | ||
| When creating extensions you want to work in Firefox and Chrome, this library enables you to use the Firefox promise-based APIs and have them run on Google Chrome with few, if any, changes. |
There was a problem hiding this comment.
Promise-based. I think that your spell checker did not recognize that this was referring to an API name? Or is it the convention to use lower case?
| When creating extensions you want to work in Firefox and Chrome, this library enables you to use the Firefox promise-based APIs and have them run on Google Chrome with few, if any, changes. | |
| When creating extensions you want to work in Firefox and Chrome, this library enables you to use the Firefox Promise-based APIs and have them run on Google Chrome with few, if any, changes. |
There was a problem hiding this comment.
While I couldn't find a definitive statement, references to the built-in global class or constructor should be capitalized, but references to the concept or instance should be in lowercase, see https://promisesaplus.com/ “promise” is an object or function with a then method whose behavior conforms to this specification.
Co-authored-by: Rob Wu <rob@robwu.nl> Co-authored-by: rebloor <git@sherpa.co.nz>
| - **Namespace**: | ||
| - `browser.*`, the standard for the extensions API used by Firefox, Safari, Chrome (from 148), Opera (from 121), and Edge (from 136). Note: `browser.*` [isn't supported for DevTools extensions](https://developer.chrome.com/docs/extensions/develop/concepts/browser-namespace) until Chrome 152, Opera 125, and Edge 140. For support, see the [webextension-polyfill](https://github.com/mozilla/webextension-polyfill). | ||
| - `chrome.*` supported by all browsers. | ||
| - **Asynchronous APIs**: Promises are used by Firefox and Safari. Chrome, Opera, and Edge began introducing promises with Manifest V3, and they are available for all relevant APIs in Chrome 152. |
There was a problem hiding this comment.
This is not really the right framing. The right frame is that Chrome used to not support promises (which is why many extensions and samples may be using callbacks), but that nowadays Chrome does support promises.
Technically you are right that Chrome 152 has completed promise support, but that could also imply that earlier versions did not. That is not the right signal to send. The devtools situation is a special exception.
Please also review the content on the whole page, there are other parts that are now inaccurate.
For namespace, and Promise support specifically, the short version is really "Firefox and Chrome used to have differing capabilities, but now all browsers have the same baseline for namespace and Promise support (that Firefox already supported from the beginning, and Chrome also adopted)".
Co-authored-by: Rob Wu <rob@robwu.nl> Co-authored-by: rebloor <git@sherpa.co.nz>
| - **Namespace**: | ||
| - `browser.*`, the standard for the extensions API used by Firefox, Safari, Chrome (from 148), Opera (from 121), and Edge (from 136). Note: `browser.*` [isn't supported for DevTools extensions](https://developer.chrome.com/docs/extensions/develop/concepts/browser-namespace) until Chrome 152, Opera 125, and Edge 140. For support, see the [webextension-polyfill](https://github.com/mozilla/webextension-polyfill). | ||
| - `chrome.*` supported by all browsers. | ||
| - **Asynchronous APIs**: Promises are used by Firefox and Safari. Chrome, Opera, and Edge began introducing promises with Manifest V3, and they are available for all relevant APIs in Chrome 152. |
|
|
||
| All you need to create extensions for Firefox is a [text editor](https://developer.mozilla.org/docs/Learn/Common_questions/Available_text_editors) and [a version of Firefox](/documentation/develop/choosing-a-firefox-version-for-extension-development/) to support your testing. Mozilla and the Firefox extension developer community have also created a number of [extension development tools](/documentation/develop/browser-extension-development-tools/) that can simplify the coding and testing of your extension. | ||
|
|
||
| ### Chromium-based browser extensions |
There was a problem hiding this comment.
@Rob--W not quite sure why GitHub has shown this as a complete deletion and replacement. The only change I've made here is to delete this section, given that we're archiving the tool and it's no longer needed for future future develop future development.
Rob--W
left a comment
There was a problem hiding this comment.
My remaining feedback is trivial to address, so approving with that addressed.
| You reference all extensions APIs using a namespace. For example, `browser.alarms.create({delayInMinutes});` creates an alarm that goes off after the time specified in `delayInMinutes`. | ||
|
|
||
| There are two API namespaces in use: | ||
| From mid-2026, all major browsers support the `browser` namespace and promises for asynchronous methods. Previously, Chromium-based browsers (such as Chrome, Opera, and Microsoft Edge) used only the `chrome` namespace with callbacks. |
There was a problem hiding this comment.
This statement suggests that pre mid-2026, Promises were not supported in Chromium. That is inaccurate. If it is awkward to mention it well, I would be okay with separate sections on namespaces and callback/promise behavior, because they have different "timelines".
There was a problem hiding this comment.
@Rob--W I've reworded this, but haven't split out separate sections for namespace and callback/promise. I'll merge if there's no further feedback by the end of Monday
Co-authored-by: Rob Wu <rob@robwu.nl>
Co-authored-by: Rob Wu <rob@robwu.nl>
Description
These changes are designed to emphasize that the webextension-polyfill is now only needed when an extension targets Chrome 147 or earlier.
Related issues and pull requests
Related changes to MDN content in mdn/content#44951.