Extensions in Firefox 69


In our last post for Firefox 68, we’ve introduced a great number of new features. In contrast, Firefox 69 only has a few new additions. Still, we are proud to present this round of changes to extensions in Firefox.

Better Topsites

The topSites API has received a few additions to better allow developers to retrieve the top sites as Firefox knows them. There are no changes to the defaults, but we’ve added a few options for better querying. The browser.topSites.get() function has two additional options that can be specified to control what sites are returned:

  • includePinned can be set to true to include sites that the user has pinned on the Firefox new tab.
  • includeSearchShortcuts can be set to true for including search shortcuts

Passing both options allows to mimic the behavior you will see on the new tab page, where both pinned results and search shortcuts are available.

User Scripts

This is technically an addition to Firefox 68, but since we didn’t mention it in the last blog post it gets an honorable mention here. In March, we announced that user scripts were coming, and now they are here. Starting with Firefox 68,  you will be able to use the userScripts API without needing to set any preferences in about:config.

The great advantage of the userScripts API is that it can run scripts with reduced privileges. Your extension can provide a mechanism to run user-provided scripts with a custom API, avoiding the need to use eval in content scripts. This makes it easier to adhere to the security and privacy standards of our add-on policies. Please see the original post on this feature for an example on how to use the API while we update the documentation.


  • The downloads API now correctly supports byExtensionId and byExtensionName for extension initiated downloads.
  • Clearing site permissions no longer re-prompts the user to accept storage permissions after a restart.
  • Using alert() in a background page will no longer block the extension from running.
  • The proxy.onRequest API now also supports FTP and WebSocket requests.

A round of applause goes to our volunteer contributors Martin Matous, Michael Krasnov, Myeongjun Go, Joe Jalbert, as well as everyone else who has made these additions in Firefox 69 possible.

The post Extensions in Firefox 69 appeared first on Mozilla Add-ons Blog.

Upcoming deprecations in Firefox 70


Several planned code deprecations for Firefox 70, currently available on the Nightly pre-release channel, may impact extension and theme developers. Firefox 70 will be released on October 22, 2019.

Aliased theme properties to be removed

In Firefox 65, we started deprecating the aliased theme properties accentcolor, textcolor, and headerURL. These properties will be removed in Firefox 70.

Themes listed on addons.mozilla.org (AMO) will be automatically updated to use supported properties. Most themes were updated back in April, but new themes have been created using the deprecated properties. If your theme is not listed on AMO, or if you are the developer of a dynamic theme, please update your theme’s manifest.json to use the supported properties.

  • For accentcolor, please use frame
  • For headerURL, please use theme_frame
  • For textcolor, please use tab_background_text

JavaScript deprecations

In Firefox 70, the non-standard, Firefox-specific Array generic methods introduced with JavaScript 1.6 will be considered deprecated and scheduled for removal in the near future. For more information about which generics will be removed and suggested alternatives, please see the Firefox Site Compatibility blog.

The Site Compatibility team also intends to remove the non-standard prototype toSource and uneval by the end of 2019.

The post Upcoming deprecations in Firefox 70 appeared first on Mozilla Add-ons Blog.

Extensions in Firefox 68


In Firefox 68, we are introducing a new API and some enhancements to webRequest and private browsing. We’ve also fixed a few issues in order to improve compatibility and resolve issues developers were having with Firefox.

Captivating Add-ons

At airports and cafés you may have seen Firefox asking you to log in to the network before you can access the internet. In Firefox 68, you can make use of this information in an extension. The new captive portal API will assist you in making sure your add-on works gracefully when locked behind a captive portal.

For example, you could hold off your requests until network access is available again. If you have been using other techniques for detecting captive portals, we encourage you to switch to this API so your extension uses the same logic as Firefox.

Here is an example of how to use this API:

(async function() {
// The current portal state, one of `unknown`, `not_captive`, `unlocked_portal`, `locked_portal`.
let state = await browser.captivePortal.getState();
// Get the duration since the captive portal state was last checked
let lastChecked = await browser.captivePortal.getLastChecked();
console.log(`The captive portal has been ${state} since at least ${lastChecked} milliseconds`);
browser.captivePortal.onStateChanged.addListener((details) => {
console.log("Captive portal state is: " + details.state);
browser.captivePortal.onConnectivityAvailable.addListener((status) => {
// status can be "captive" in an (unlocked) captive portal, or "clear" if we are in the open
console.log("Internet connectivity is available: " + status);

Note: if you use this API, be sure to add the captivePortal permission to your manifest.

Private and contained

We’ve made a few additions to the webRequest API to better support private browsing mode. You can now limit your webRequests to only include requests from private browsing mode. If instead you are interested in both types of requests it is now possible to differentiate them in the webRequest listener.

To improve the integration of containers, we’ve also added the container ID (cookieStoreId) to the webRequest listener.

Proxy new and proxy old

The two additional fields mentioned in the previous section are also available in the details object passed to the proxy.onRequest listener.

At the same time, we’d like to make you aware that we are deprecating the proxy.register, proxy.unregister and proxy.onProxyError APIs. As an alternative, you can use the proxy.onRequest API to determine how requests will be handled, and proxy.onError to handle failures. If your extension is using these APIs you will see a warning in the console. These APIs will ultimately be removed in Firefox 71, to be released on December 10th, 2019.

Timing is everything

We’ve changed the timing of tabs.duplicate for better compatibility with Chrome. The promise is now resolved immediately, before the duplicated tab finished loading. If you have been relying on this promise for a completed duplicated tab in Firefox, please adjust your code and make use of the tabs.onUpdated listener.


    • Since extensions cannot add bookmarks to the root folder, we’ve improved the error message you get when you try.
    • If you’ve been trying to remove indexedDB data via browser.browsingData.remove({}, { indexedDB: true }); and it failed in some cases, we’ve fixed this on our end now.
    • Removing cookies for IPv6 addresses has been fixed.
    • Fixes an issue when setting cookies with an IP address in the domain field, along with the url field being set.
    • Hard-to-debug performance issues using webRequest.onBeforeRequest with requestBody during large uploads have been solved.
    • An issue with identity.launchWebAuthFlow hanging after authentication has been resolved.
    • storage.onChanged is now fired when values are removed.

Thank You

We’ve had a great amount of support from the community. I’d like to thank everyone who has taken part, but especially our volunteer contributors Jan Henning, Myeongjun Go, Oriol Brufau, Mélanie Chauvel, violet.bugreport and Piro. If you are interested in contributing to the WebExtensions ecosystem, please take a look at our wiki.

The post Extensions in Firefox 68 appeared first on Mozilla Add-ons Blog.

Add-on Policy and Process Updates


As part of our ongoing work to make add-ons safer for Firefox users, we are updating our Add-on Policy to help us respond faster to reports of malicious extensions. The following is a summary of the changes, which will go into effect on June 10, 2019.

  • We will no longer accept extensions that contain obfuscated code. We will continue to allow minified, concatenated, or otherwise machine-generated code as long as the source code is included. If your extension is using obfuscated code, it is essential to submit a new version by June 10th that removes it to avoid having it rejected or blocked.

We will also be clarifying our blocking process. Add-on or extension blocking (sometimes referred to as “blocklisting”), is a method for disabling extensions or other third-party software that has already been installed by Firefox users.

  • We will be blocking extensions more proactively if they are found to be in violation of our policies. We will be casting a wider net, and will err on the side of user security when determining whether or not to block.
  • We will continue to block extensions for intentionally violating our policies, critical security vulnerabilities, and will also act on extensions compromising user privacy or circumventing user consent or control.

You can preview the policy and blocking process documents and ensure your extensions abide by them to avoid any disruption. If you have questions about these updated policies or would like to provide feedback, please post to this forum thread.

The post Add-on Policy and Process Updates appeared first on Mozilla Add-ons Blog.

Recommended Extensions program — coming soon


In February, we blogged about the challenge of helping extension users maintain their safety and security while preserving their ability to choose their browsing experience. The blog post outlined changes to the ecosystem to better protect users, such as making them more aware of the risks associated with extensions, reducing the visibility of extensions that haven’t been vetted, and putting more emphasis on curated extensions.

One of the ways we’re helping users discover vetted extensions will be through the Recommended Extensions program, which we’ll roll out in phases later this summer. This program will foster a curated list of extensions that meet our highest standards of security, utility, and user experience. Recommended extensions will receive enhanced visibility across Mozilla websites and products, including addons.mozilla.org (AMO).

We anticipate the eventual formation of this list to number in the hundreds, but we’ll start smaller and build the program carefully. We’re currently in the process of identifying candidates and will begin reaching out to selected developers later this month. You can expect to see changes on AMO by the end of June.

How will Recommended extensions be promoted?

On AMO, Recommended extensions will be visually identifiable by distinct badging. Furthermore, AMO search results and filtering will be weighted higher toward Recommended extensions

Recommended extensions will also supply the personalized recommendations on the “Get Add-ons” page in the Firefox Add-ons Manager (about:addons), as well as any extensions we may include in Firefox’s Contextual Feature Recommender.

How are extensions selected to be part of the program?

Editorial staff will select the initial batch of extensions for the Recommended list. In time, we’ll provide ways for people to nominate extensions for inclusion.

When evaluating extensions, curators are primarily concerned with the following:

  • Is the extension really good at what it does? All Recommended extensions should not only do what they promise, but be very good at it. For instance, there are many ad blockers out there, but not all ad blockers are equally effective.
  • Does the extension offer an exceptional user experience? Recommended extensions should be delightful to use. Curators look for content that’s intuitive to manage and well-designed. Common areas of concern include the post-install experience (i.e. once the user installs the extension, is it clear how to use it?), settings management, user interface copy, etc.
  • Is the extension relevant to a general audience? The tightly curated nature of Recommended extensions means we will be selective, and will only recommend  extensions that are appealing to a general Firefox audience.
  • Is the extension safe? We’re committed to helping protect users against third-party software that may—intentionally or otherwise—compromise user security. Before an extension receives Recommended status, it undergoes a security review by staff reviewers. (Once on the list, each new version of a Recommended extension must also pass a full review.)

Participation in the program will require commitment from developers in the form of active development and a willingness to make improvements.

How will the list be maintained?

It’s our intent to develop a Recommended list that can remain relevant over time, which is to say we don’t anticipate frequent turnover in the program. The objective is to promote Recommended extensions that users can trust to be useful and safe for the lifespan of the software they install.

We recognize the need to keep the list current, and will make room for new, emerging extensions. Firefox users want the latest, greatest extensions. Talented developers all over the world continue to find creative ways to leverage the powerful capabilities of extensions and deliver fantastic new features and experiences. Once the program launches later this summer, we’ll provide ways for people to suggest extensions for inclusion in the program.

Will the community be involved?

We believe it’s important to maintain community involvement in the curatorial process. The Community Advisory Board—which for years has contributed to helping identify featured content—will continue to be involved in the Recommended extensions program.

We’ll have more details to share in the coming months as the Recommended extensions program develops. Please feel free to post questions or comments on the add-ons Discourse page.

The post Recommended Extensions program — coming soon appeared first on Mozilla Add-ons Blog.

Extensions in Firefox 67


There are a couple of major changes coming to Firefox. One is in the current Beta 67 release, while the other in the Nightly 68 release, but is covered here as an early preview for extension developers.

Respecting User Privacy

The biggest change in release 67 is Firefox now offers controls to determine which extensions run in private browsing windows. Prior to this release, all extensions ran in all windows, normal and private, which wasn’t in line with Mozilla’s commitment to user privacy. Starting with release 67, though, both developers and users have ways to specify which extensions are allowed to run in private windows.

Going Incognito

For extension developers, Firefox now fully supports the value not_allowed for the manifest `incognito` key.  As with Chrome, specifying not_allowed in the manifest will prevent the extension from running or receiving events from private windows.

The Mozilla Add-on Policies require that extensions not store browsing data or leak identity information to private windows. Depending on what features your extension provides, using not_supported might be an easy way to guarantee that your extension adheres to the policy.

Note that Chrome’s split value for incognito is not supported in Firefox at this time.

Raising User Awareness

There are significant changes in Firefox’s behavior and user interface so that users can better see and control which extensions run in private windows.  Starting with release 67, any extension that is installed will be, by default, disallowed from running in private windows. The post-install door hanger, shown after an extension has been installed, now includes a checkbox asking the user if the extension should be allowed to run in private windows.

To avoid potentially breaking existing user workflows, extensions that are already installed when a user upgrades from a previous version of Firefox to version 67 will automatically be granted permission to run in private windows. Only newly installed extensions will be excluded from private windows by default and subject to the installation flow described above.

There are significant changes to the Add-ons Manager page (about:addons), too. First, a banner at the top of the page describes the new behavior in Firefox.

This banner will remain in Firefox for at least two releases to make sure all users have a chance to understand and get used to the new policy.

In addition, for each extension that is allowed to run in private windows, the Add-ons Manager will add a badge to the extension’s card indicating that it has this permission, as shown below.

The lack of a badge indicates that the extension is not allowed to run in private windows and will, therefore, only run in normal windows. To change the behavior and either grant or revoke permission to run in private windows, the user can click on an extension’s card to bring up its details.

On the detail page, the user can choose to either allow or disallow the extension to run in private windows.

Finally, to make sure that users of private windows are fully aware of the new extension behavior, Firefox will display a message the first time a user opens a new private window.

Proper Private Behavior

As a developer, you should take steps to ensure that, when the user has not granted your extension permission to run in private windows, it continues to work normally. If your extension depends on access to private windows, it is important to communicate this to your users, including the reasons why access is needed. You can use the extension.isAllowedIncognitoAccess API to determine whether users have granted your extension permission to run in private windows.

Note that some WebExtension API that may still affect private windows, even if the user has not granted the calling extension access to private windows. The browserSettings API is the best example of this, where an extension may make changes to the general behavior of Firefox, including how private windows behave, without needing permission to access private windows.

Finally, there is a known issue where some extensions that use the proxy.settings API require private browsing permission to use that API even in normal windows (all other proxy API work as expected). Mozilla is working to address this and will be reaching out to impacted developers.

User Scripts Are Coming

This is a bit of a teaser for Firefox 68, but after many months of design, implementation and testing, a WebExtensions user scripts API is just about ready. User scripts have been around for a very long time and are often closely associated with Firefox.  With the help of a user script extension such as Greasemonkey or Tampermonkey, users can find and install scripts that modify how sites look and/or work, all without having to write an extension themselves.

Support for user scripts is available by default in the Nightly version of Firefox 68, but can be enabled in both the current Firefox release (66) and Beta release (67) versions by setting the following preference in about:config:

extensions.webextensions.userScripts.enabled = true

This is a fairly complex feature and we would love for developers to give it a try as early as possible, which is why it’s being mentioned now. Documentation on MDN is still being developed, but below is a brief description of how this feature works.

Registering A User Script

The userScripts API provides a browser.userScripts.register API very similar to the browser.contentScripts.register API. It returns a promise which is resolved to an API object that provides an unregister method to unregister the script from all child processes.

const registeredUserScript = await browser.userScripts.register(
userScriptOptions       // object
await registeredUserScript.unregister();

userScriptOptions is an object that represents the user scripts to register. It has the same syntax as the contentScript options supported by browser.contentScripts.register that describe which web pages the scripts should be applied to, but with two differences:

    • It does not support a css property (use browser.contentScripts.register to dynamically register/unregister stylesheets).
    • It supports an optional property, scriptMetadata, a plain JSON object which contains metadata properties associated with the registered user script.

Providing User Script Functionality

To support injected user scripts, an extension must provide a special kind of content script called an APIScript. Like a regular content script, it:

The APIScript is declared in the manifest using the user_scripts.api_script property:

"user_scripts": {
"api_script": "apiscript.js",

The APIScript is executed automatically on any page matched by the userScript.register API called from the same extension. It is executed before the user script is executed.

The userScript API also provides a new event, browser.userScripts.onBeforeScript, which the APIScript can listen for.  It is called right before a matched user script is executed, allowing the APIScript to export custom API methods to the user script.


In the above API, listener is a function called right before a user script is executed. The function will be passed a single argument, a script object that represents the user script that matched a web page. The script object provides the following properties and methods:

  • metadata – The scriptMetadata property that was set when the user script was registered via the userScripts.register API.
  • global – Provides access to the isolated sandbox for this particular user script.
  • defineGlobals – An API method that exports an object containing globally available properties and methods to the user script sandbox.  This method must be called synchronously to guarantee that the user script has not already executed.
  • export – An API method that converts a given value to a value that the user script code is allowed to access (this method can be used in API methods exported to the userScript to result or resolve non primitive values, the exported objects can also provide methods that the userScripts code is allowed to access and call).

The example below shows how a listener might work:

browser.userScripts.onBeforeScript.addListener(function (script) {
script // This is an API object that represents the userScript
// that is going to be executed.
script.metadata // Access the userScript metadata (returns the
// value of the scriptMetadata property from
// the call to userScripts.register
// Export some global properties into the userScript sandbox
// (this method has to be called synchronously from the
// listener, otherwise the userScript may have been already
// be executed).
aGlobalPropertyAccessibleFromUserScriptCode: “prop value”,
myCustomAPIMethod(param1, param2) {
// Custom methods exported from the API script can use
// the WebExtensions APIs available to the extension
// content scripts
return 123; // primitive values can be returned directly
// Non primitive values have to be exported explicitly
// using the export method provided by the script API
// object
return script.export({{
objKey1: {
nestedProp: "nestedvalue",
// Explicitly exported objects can also provide methods.
objMethod() { ... }
async myAsyncMethod(param1, param2, param2) {
// exported methods can also be declared as async

Miscellaneous Items

It was a busy release and besides the two major features detailed above, a number of smaller features (and fixes) also made it into Firefox 67.

Thank You

Within the WebExtensions API, a total of 74 bugs were closed in Firefox 67. Volunteer contributors continue to be an integral part of the effort and a huge thank you goes out those that contributed to this release, including: Oriol Brufau, Shailja Agarwala, Edward Wu, violet.bugreport and rugk. The combined efforts of Mozilla and its amazing community members are what make Firefox the best browser in the world.

The post Extensions in Firefox 67 appeared first on Mozilla Add-ons Blog.

Extensions in Firefox 66


Firefox 66 is currently in beta and, for extension developers, the changes to the WebExtensions API center primarily around improving performance, stability, and the development experience. A total of 30 issues were resolved in Firefox 66, including contributions from several volunteer community members.

Major Performance Improvements for Storage

I want to start by highlighting an important change that has a major, positive impact for Firefox users. Starting in release 66, extensions use IndexedDB as the backend for local storage instead of a JSON file. This results in a significant performance improvement for many extensions, while simultaneously reducing the amount of memory that Firefox uses.

This change is completely transparent to extension developers – you do not need to do anything to take advantage of this improvement.  When users upgrade to Firefox 66, the local storage JSON file is silently migrated to IndexedDB. All extensions using the storage.local() API immediately realize the benefits, especially if they store small changes to large structures, as is true for ad-blockers, the most common and popular type of extension used in Firefox.

The video below, using Adblock Plus as an example, shows the significant performance improvements that extension users could see.

Other Improvements

The remaining bug fixes and feature enhancements won’t be as noticeable as the change to local storage, but they nevertheless raise the overall quality of the WebExtensions API and make the development experience better.  Some of the highlights include:

Thank you to everyone who contributed to the Firefox 66 release, but a special thank you to our volunteer community contributors, including: tossj, Varun Dey, and Edward Wu.

The post Extensions in Firefox 66 appeared first on Mozilla Add-ons Blog.

Google’s Proposed Chrome Changes Would Cripple Ad Blockers, Other Extensions

This site may earn affiliate commissions from the links on this page. Terms of use.

Google has proposed a series of changes to Chrome that, if adopted in their current form, could cripple how ad blocking works within Chromium-based browsers. The impact of the changes wouldn’t be limited to ad blocking — other projects like NoScript and a wide range of other extensions would, according to their authors, also be impacted.

Google’s proposed changes, detailed in its Manifest V3 document, would make significant changes to how extensions fundamentally work within Chrome. Extensions, for example, will no longer be permitted to load code from remote servers or to automatically apply to all sites (users will have an option to choose to run extensions on specific sites or on every site). But the biggest problems appear to be with Google’s plans to deprecate or limit the use of its webRequest API. As Ars Technica details, webRequest allows extensions to evaluate each network request that the extension is intended to monitor and to make decisions about what happens to it. Requests can be modified in-flight to change how the browser behaves in a wide variety of scenarios. Ad blockers, script blockers, and a number of various privacy-oriented extensions rely on this capability.

Google wants to replace webRequest with a new API, declarativeNetRequest. Using the old webRequest API requires that the browser ask the extension how content should be handled. The new API instead requires that the extension declare to the browser what it can do and how it does it. The problem is, the new API has a fraction of the capability of the old one. Extensions are also currently hard-limited to a constraint of 30,000 items to be filtered. As Ars notes, the current version of uBlock Origin ships with 90,000 filters by default and supports up to 500,000.


The advanced functionality of extensions like uBlock isn’t possible under the new rules.

Thus far, feedback from actual extension developers has been unilaterally negative. The hard-coded limit on blocked or redirected URLs has been criticized by almost everyone in the Google Chromium development thread. Anti-phishing and anti-malware extension developers are also concerned because the new rules require that extension data be stored in plaintext, whereas some security-related extensions store information in hashed form.

While there have been reports that AdBlock Plus will have an easier time functioning under these rules than extensions like uBlock Origin, one of the authors of that extension argues that even ABP will be harmed, noting that the declarativeNetRequest API “only covers the same limited subset of filter capabilities implemented in Adblock Plus that it does in uBlock Origin.” Instead of being able to implement powerful, custom rulesets, he argues that extensions would now be limited to “providing filter rules.” This would fundamentally limit the ability of extension developers to respond quickly to website efforts to bypass their work. Security extension developers also raised these concerns, noting that the new API disallows updating content-blocking lists in real time. This alone makes it impossible for security extensions to provide fast updates.

Google’s responses, thus far, have been fairly limited. The company has been stressing that the webRequest API will be sticking around in some capacity since declarativeNetRequest can’t handle everything. It’s still evaluating the contexts in which webRequest will be allowed to function, however.

Google’s claim that these changes will improve security and performance have been met with a gimlet eye overall. Several developers have pointed out that the performance impact of running uBlock or other ad blockers on websites is so large, any performance gains Google gets from adopting a faster API will be completely subsumed by the sharp limits on the amount of content those extensions are actually able to block. Speeding up page loads by 20 percent may not mean much if you’re loading 3-5x more data relative to using an ad blocker. Security extension authors have also argued that the security risk to breaking their own products is larger than the sum total of the improvements Google is hoping to gain.

For now, Manifest V3 remains a draft document. If Google decides to implement the current version of the standard, Firefox may see a sudden uptick in adoption. It’s now the only major cross-platform browser in active development that isn’t based on Chromium.

Now Read:

Extensions in Firefox 65


In lieu of the normal, detailed review of WebExtensions API coming out in Firefox 65, I’d like to simply say thank you to everyone for choosing Firefox. Now, more than ever, the web needs people who consciously decide to support an open, private, and safe online ecosystem.

Two weeks ago, nearly every Mozilla employee gathered in Orlando, Florida for the semi-annual all-hands meeting.  It was an opportunity to connect with remote teammates, reflect on the past year and begin sharing ideas for the upcoming year. One of the highlights was the plenary talk by Mitchell Baker, Chairwoman of the Mozilla Foundation. If you have not seen it, it is well worth 15 minutes of your time.

Mitchell talks about Firefox continually adapting to a changing internet, shifting its engagement model over time to remain relevant while staying true to its original mission. Near the end, she notes that it is time, once again, for Mozilla and Firefox to evolve, to shift from being merely a gateway to the internet to being an advocate for users on the internet.

Extensions will need to be part of this movement. We started when Firefox migrated to the WebExtensions API (only a short year ago), ensuring that extensions operated with explicit user permissions within a well-defined sandbox. In 2018, we made a concerted effort to not just add new API, but to also highlight when an extension was using those API to control parts of the browser. In 2019, expect to see us sharpen our focus on user privacy, user security, and user agency.

Thank you again for choosing Firefox, you have our deepest gratitude and appreciation. As a famous Mozillian once said, keep on rockin’ the free web.

-Mike Conca

Highlights of new features and fixes in Firefox 65:

A huge thank you to the community contributors in this release, including: Ben Armstrong, Oriol Brufau, Tim Nguyen, Ryan Hendrickson, Sean Burke, Yuki “Piro” Hiroshi, Diego Pino, Jan Henning, Arshad Kazmi, Nicklas Boman.


The post Extensions in Firefox 65 appeared first on Mozilla Add-ons Blog.

Extensions in Firefox 64


Following the explosion of extension features in Firefox 63, Firefox 64 moved into Beta with a quieter set of capabilities spread across many different areas.

Extension Management

The most visible change to extensions comes on the user-facing side of Firefox where the add-ons management page (about:addons) received an upgrade.

Changes on this page include:

  • Each extension is shown as a card that can be clicked.
  • Each card shows the description for the extension along with buttons for Options, Disable and Remove.
  • The search area at the top is cleaned up.
  • The page links to the Firefox Preferences page (about:preferences) and that page links back to about:addons, making navigation between the two very easy.  These links appear in the bottom left corner of each page.

These changes are part of an ongoing redesign of about:addons that will make managing extensions and themes within Firefox simpler and more intuitive. You can expect to see additional changes in 2019.

As part of our continuing effort to make sure users are aware of when an extension is controlling some aspect of Firefox, the Notification Permissions window now shows when an extension is controlling the browser’s ability to accept or reject web notification requests.

When an extension is installed, the notification popup is now persistently shown off of the main (hamburger) menu.  This ensures that the notification is always acknowledged by the user and can’t be accidentally dismissed by switching tabs.

Finally, extensions can now be removed by right-clicking on an extension’s browser action icon and selecting “Remove Extension” from the resulting context menu.

Even More Context Menu Improvements

Firefox 63 saw a large number of improvements for extension context menus and, as promised, there are even more improvements in Firefox 64.

The biggest change is a new API that can be called from the contextmenu DOM event to set a custom context menu in extension pages.  This API, browser.menus.overrideContext(), allows extensions to hide all default Firefox menu items in favor of providing a custom context menu UI.  This context menu can consist of multiple top-level menu items from the extension, and may optionally include tab or bookmark context menu items from other extensions.

To use the new API, you must declare the menus and the brand new menus.overrideContext permission. Additionally, to include context menus from other extensions in the tab or bookmarks contexts, you must also declare the tabs or bookmarks permissions, respectively.

The API is still being documented on MDN at the time of this writing, but the API takes a contextOptions object as a parameter, which includes the following values:

  • showDefaults: boolean that indicates whether to include default Firefox menu items in the context menu (defaults to false)
  • context: optional parameter that indicates the ContextType to override to allow menu items from other extensions in this context menu. Currently, only bookmark and tab are supported. showDefaults cannot be used with this option.
  • bookmarkId: required when context is bookmark. Requires bookmarks permission.
  • tabId: required when context is tab. Requires tabs permission.

While waiting for the MDN documentation to go live, I would highly encourage you to check out the terrific blog post by Yuki “Piro” Hiroshi that covers usage of the new API in great detail.

Other improvements to extension context menus include:

  • browser.menus.update() now allows extensions to update an icon without having to delete and recreate the menu item.
  • menus.create() and menus.update() now support a viewTypes property.  This is a list of view types that specifies where the menu item will be shown and can include tab, popup (pageAction/browserAction) or sidebar. It defaults to any view, including those without a viewType.
  • The menus.onShown and menus.onClicked events now include the viewType described above as part of their info object so extensions can determine the type of view where the menu was shown or clicked.
  • The menus.onClicked event also added a button property to indicate which mouse button initiated the click (left, middle, right).

Minor Improvements in Many Areas

In addition to the extension management in Firefox and the context menu work, many smaller improvements were made throughout the WebExtension API.

Page Actions

  • A new, optional manifest property for page actions called ‘pinned’ has been added.  It specifies whether or not the page action should appear in the location bar by default when the user installs the extension (default is true).


Content Scripts

  • Content scripts can now read from a that they have modified.


Private Browsing

Keyboard Shortcuts

Dev Tools

  • Extensions can now create devtools panel sidebars and use the new setPage() API to embed an extension page inside the devtools inspector sidebar.

Misc / Bug Fixes

Thank You

A total of 73 features and improvements landed as part of Firefox 64. Volunteer contributors were a huge part of this release and a tremendous thank you goes out to our community, including: Oriol Brufau, Tomislav Jovanovic, Shivam Singhal, Tim Nguyen, Arshad Kazmi, Divyansh Sharma, Tom Schuster, Tim B, Tushar Arora, Prathiksha Guruprasad. It is the combined efforts of Mozilla and our amazing community that make Firefox a truly unique product. If you are interested in contributing to the WebExtensions ecosystem, please take a look at our wiki.

The post Extensions in Firefox 64 appeared first on Mozilla Add-ons Blog.