Extensions in Firefox 71

Firefox

Firefox 71 is a light release in terms of extension changes. I’d like to tell you about a few interesting improvements nevertheless.

Thanks to Nils Maier, there have been various improvements to the downloads API, specifically in handling download failures. In addition to previously reported failures, the browser.downloads.download API will now report an error in case of various 4xx error codes. Similarly, HTTP 204 (No Content) and HTTP 205 (Reset Content) are now treated as bad content errors. This makes the API more compatible with Chrome and gives developers a way to handle these errors in their code. With the new allowHttpErrors parameter, extensions may also ignore some http errors when downloading. This will allow them to download the contents of server error pages.

Please also note, the lowercase isarticle filter for the tabs.onUpdated listener has been removed in Firefox 71. Developers should instead use the camelCase isArticle filter.

A few more minor updates are available as well:

  • Popup windows now include the extension name instead of its moz-extension:// url when using the windows.create API.
  • Clearer messaging when encountering unexpected values in manifest.json (they are often warnings, not errors)
  • Extension-registered devtools panels now interact better with screen readers

Thank you contributors Nils and Myeongjun Go for the improvements, as well as our WebExtensions team for fixing various tests and backend related issues. If you’d like to help make this list longer for the next releases, please take a look at our wiki on how to contribute. I’m looking forward to seeing what Firefox 72 will bring!

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

Security improvements in AMO upload tools

Firefox

We are making some changes to the submission flow for all add-ons (both AMO- and self-hosted) to improve our ability to detect malicious activity.

These changes, which will go into effect later this month, will introduce a small delay in automatic approval for all submissions. The delay can be as short as a few minutes, but may take longer depending on the add-on file.

If you use a version of web-ext older than 3.2.1, or a custom script that connects to AMO’s upload API, this new delay in automatic approval will likely cause a timeout error. This does not mean your upload failed; the submission will still go through and be approved shortly after the timeout notification. Your experience using these tools should remain the same otherwise.

You can prevent the timeout error from being triggered by updating web-ext or your custom scripts before this change goes live. We recommend making these updates this week.

  • For web-ext: update to web-ext version 3.2.1, which has a longer default timeout for `web-ext sign`. To update your global install, use the command `npm install -g web-ext`.
  • For custom scripts that use the AMO upload API: make sure your upload scripts account for potentially longer delays before the signed file is available. We recommend allowing up to 15 minutes.

The post Security improvements in AMO upload tools appeared first on Mozilla Add-ons Blog.

Extensions in Firefox 70

Firefox

Welcome to another round of new additions and changes to extensions, this time in Firefox 70. We have a new API, some improvements on existing APIs, and some great additions to Firefox Developer Tools to make it easier to debug your extensions.

Network Status

Firefox 70 features a new network status API. It can be used to determine if an internet connection is available and provides insight into what type of connection the user is on. A potential use case for this would be for developers to limit the data they are transferring on a mobile connection. Here is an example:

async function upload(url, buffer) {
let info = await browser.networkStatus.getLinkInfo();
let isMobile = ["wimax", "2g", "3g", "4g"].includes(info.type);
// Only sending every second byte on mobile. Clever savings, eh?
let body = buffer;
if (isMobile) {
body = body.filter((elem, index) => index % 2 == 0);
}
console.log(`Uploading via ${info.type} connection named ${info.id}`);
switch (info.status) {
case "down":
await handleOfflineMode(url, buffer);
break;
case "up":
case "unknown":
await fetch(url, {
method: "POST",
headers: { "Content-Type": "application/octet-stream" },
body: body
});
break;
}
}

There is also an onConnectionChanged event available that is called with the changed link info.

Downloads API Improvements

We’ve made a few improvements to the downloads API in Firefox 70. By popular request, the Referer header is now allowed in the browser.downloads.download API’s headers object. This allows extensions, such as download managers, to download files for sites that require a referrer to be set.

Also, we’ve improved error reporting for failed downloads. In addition to previously reported failures, the browser.downloads.download API will now report an error in case of various http 4xx failures. This makes the API more compatible with Chrome and gives developers a way to react to these errors in their code. [Edit: Sorry if I got your hopes up! This is actually coming in Firefox 71!]

Privacy API Improvements

If you are using the browser.privacy.network API and are modifying webRTCIPHandlingPolicy, we’ve made some compatibility changes to the disable_non_proxied_udp setting. This setting now better matches Chrome’s behavior. If your add-on relied on the Firefox-specific behavior, you can make use of the new setting proxy_only.

Extension Storage Inspector

Starting in Firefox 70, Firefox finally supports inspecting data from the browser.storage API using the Devtools Storage Inspector. When you inspect an add-on via about:debugging, you will find a new Extension Storage section in the storage panel. While changing the values is not currently supported, this will make debugging your add-ons even easier.

Firefox developer tools showing extension storage data in a multi-column list.

Extension Storage Inspector

Unsupported Theme Properties

The accentcolor, headerURL and text_color properties are now unsupported. Please make use of the replacement properties frame, theme_frame, and tab_background_text. You can find more information on our previous deprecation announcement.

Miscellaneous

  • When managing extension shortcuts, you will now be notified if a shortcut is already in use.
  • The browser.notifications.onClicked and browser.notifications.onShown event callbacks are no longer called with a superfluous second parameter.
  • Logging has been improved when the native messaging host manifest is missing.
  • Various performance improvements, making startup quicker for Firefox users with add-ons.

Special thanks this time goes to our volunteers Trishul Goel, Myeongjun Go, Graham McKnight and Tom Schuster. We’ve also received an awesome contribution from Mandy Cheang as part of her internship at Mozilla. Keep up the great work everyone!

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

Extensions in Firefox 69

Firefox

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.

Miscellaneous

  • 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.

Changes in Firefox 68

Firefox

Firefox 68 is coming out today, and we wanted to highlight a few of the changes coming to add-ons. We’ve updated addons.mozilla.org (AMO) and the Add-ons Manager (about:addons) in Firefox to help people find high-quality, secure extensions more easily. We’re also making it easier to manage installed add-ons and report potentially harmful extensions and themes directly from the Add-ons Manager.

Recommended Extensions

In April, we previewed the Recommended Extensions program as one of the ways we plan to make add-ons safer. This program will make it easier for users to discover extensions that have been reviewed for security, functionality, and user experience.

In Firefox 68, you may begin to notice the first small batch of these recommendations in the Add-ons Manager. Recommendations will include star ratings and the number of users that currently have the extension installed. All extensions recommended in the Add-ons Manager are vetted through the Recommended Extensions program.

As the first iteration of a new design, you can expect some clean-up in upcoming releases as we refine it and incorporate feedback.

recommended extensions card in about:addons

On AMO starting July 11, Recommended extensions will receive special badging to indicate its inclusion in the program. Additionally, the AMO homepage will be updated to only display Recommended content, and AMO search results will place more emphasis on Recommended extensions.

AMO recommended extension badge

As the Recommended Extensions program continues to evolve, more extensions will be added to the curated list.

Add-ons management and abuse reporting

In alignment with design changes in Firefox, we’ve refreshed the Add-ons Manager to deliver a cleaner user experience. As a result, an ellipsis (3-dot) icon has been introduced to keep options organized and easy to find. You can find all the available controls, including the option to report an extension or theme to Mozilla—in one place.

new about:addons look

The new reporting feature allows users to provide us with a better understanding of the issue they’re experiencing. This new process can be used to report any installed extension, whether they were installed from AMO or somewhere else.

report option in about:addonsselect issue type when reporting extension

Users can also report an extension or theme when they uninstall an add-on. More information about the new abuse reporting process is available here.

Permissions

It’s easy to forget about the permissions that were previously granted to an extension. While most extensions are created by trustworthy third-party developers, we recommend periodically checking what you have installed, what permissions you’ve granted, and making sure you only keep the ones you really want.

Starting in Firefox 68, you can view the permissions of installed extensions directly in the Add-ons Manager, making it easier to perform these periodic checks. Here’s a summary of all extension permissions, so you can review them for yourself when deciding which extensions to keep installed.

permissions panel in about:addons

In upcoming releases, we will be adjusting and refining changes to the Add-ons Manager to continue aligning the design with the rest of Firefox and incorporating feedback we receive. We’re also developing a Recommended Extensions Community Board for contributors to assist with extension recommendations—we’ll have more information soon.

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

Extensions in Firefox 68

Firefox

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.

Miscellaneous

    • 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.

Update Regarding Add-ons in Firefox

Firefox

Last Updated: 00:54 EDT May 5 2019

Updates:

  • Some users are reporting that they do not have the “hotfix-update-xpi-signing-intermediate-bug-1548973” study active in “about:studies”. Rather than using work-arounds, which can lead to issues later on, we strongly recommend that you continue to wait. If it’s possible for you to receive the hotfix, you should get it by 6am EDT, 24 hours after it was first released. For everyone else, we are working to ship a more permanent solution. (May 5, 00:54 EDT)
  • There are a number of work-arounds being discussed in the community. These are not recommended as they may conflict with fixes we are deploying. We’ll let you know when further updates are available that we recommend, and appreciate your patience. (May 4, 15:01 EDT)
  • Temporarily disabled commenting on this post given volume and duplication. They’ll be re-enabled as more updates become available. (May 4, 13:02 EDT)
  • Updated the post to clarify that deleting extensions can result in data loss, and should not be used to attempt a fix. (May 4, 12:58 EDT)
  • Clarified that the study may appear in either the Active studies or Completed studies of “about:studies” (May 4, 12:10 EDT)
  • We’re aware that some users are reporting that their extensions remain disabled with both studies active. We’re tracking this issue on Bugzilla in bug 1549078. (May 4, 12:03 EDT)
  • Clarified that the Studies fix applies only to Desktop users of Firefox distributed by Mozilla. Firefox ESR, Firefox for Android, and some versions of Firefox included with Linux distributions will require separate updates. (May 4, 12:03 EDT)

Late on Friday May 3rd, we became aware of an issue with Firefox that prevented existing and new add-ons from running or being installed. We are very sorry for the inconvenience caused to people who use Firefox.

Our team has identified and rolled-out a fix for all Firefox Desktop users on Release, Beta and Nightly. The fix will be automatically applied in the background within the next few hours. No active steps need to be taken to make add-ons work again. In particular, please do not delete and/or re-install any add-ons as an attempt to fix the issue. Deleting an add-on removes any data associated with it, where disabling and re-enabling does not.

Please note: The fix does not apply to Firefox ESR or Firefox for Android. We’re working on releasing a fix for both, and will provide updates here and on social media.

To provide this fix on short notice, we are using the Studies system. This system is enabled by default, and no action is needed unless Studies have been disabled. Firefox users can check if they have Studies enabled by going to:

  • Firefox Options/Preferences -> Privacy & Security -> Allow Firefox to install and run studies (scroll down to find the setting)

  • Studies can be disabled again after the add-ons have been re-enabled

It may take up to six hours for the Study to be applied to Firefox. To check if the fix has been applied, you can enter “about:studies” in the location bar. If the fix is in the active, you’ll see “hotfix-update-xpi-signing-intermediate-bug-1548973” in either the Active studies or Completed studies as follows:

You may also see “hotfix-reset-xpi-verification-timestamp-1548973” listed, which is part of the fix and may be in the Active studies or Completed studies section(s).

We are working on a general fix that doesn’t use the Studies system and will keep this blog post updated accordingly. We will share a more substantial update in the coming days.

Additional sources of information:

The post Update Regarding Add-ons in Firefox appeared first on Mozilla Add-ons Blog.

Extensions in Firefox 67

Firefox

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:

manifest.json
{
...
"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.

browser.userScripts.onBeforeScript.addListener(listener)
browser.userScripts.onBeforeScript.removeListener(listener)
browser.userScripts.onBeforeScript.hasListener(listener)

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).
script.defineGlobals({
aGlobalPropertyAccessibleFromUserScriptCode: “prop value”,
myCustomAPIMethod(param1, param2) {
// Custom methods exported from the API script can use
// the WebExtensions APIs available to the extension
// content scripts
browser.runtime.sendMessage(...);
...
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

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.

Extensions in Firefox 65

Firefox

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.