{"id":8635,"date":"2019-03-26T18:52:49","date_gmt":"2019-03-27T01:52:49","guid":{"rendered":"http:\/\/blog.mozilla.org\/addons\/?p=8635"},"modified":"2019-05-31T09:16:56","modified_gmt":"2019-05-31T16:16:56","slug":"extensions-in-firefox-67","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/addons\/2019\/03\/26\/extensions-in-firefox-67\/","title":{"rendered":"Extensions in Firefox 67"},"content":{"rendered":"

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

Respecting User Privacy<\/h1>\n

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\u2019t in line with Mozilla\u2019s 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.<\/p>\n

Going Incognito<\/h3>\n

For extension developers, Firefox now fully supports the value\u00a0not_allowed<\/code> for the manifest `incognito` key<\/a>. \u00a0As with Chrome, specifying not_allowed<\/code> in the manifest will prevent the extension from running or receiving events from private windows.<\/p>\n

The Mozilla Add-on Policies<\/a> require that extensions not store browsing data or leak identity information to private windows. Depending on what features your extension provides, using not_allowed<\/code> might be an easy way to guarantee that your extension adheres to the policy.<\/p>\n

Note that Chrome\u2019s split<\/code> value for incognito<\/code> is not supported in Firefox at this time.<\/p>\n

Raising User Awareness<\/h3>\n

There are significant changes in Firefox\u2019s behavior and user interface so that users can better see and control which extensions run in private windows. \u00a0Starting 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.<\/p>\n

\"\"<\/p>\n

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.<\/p>\n

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.<\/p>\n

\"\"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.<\/p>\n

In addition, for each extension that is allowed to run in private windows, the Add-ons Manager will add a badge to the extension\u2019s card indicating that it has this permission, as shown below.<\/p>\n

\"\"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\u2019s card to bring up its details.<\/p>\n

\"\"On the detail page, the user can choose to either allow or disallow the extension to run in private windows.<\/p>\n

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.<\/p>\n

\"\"<\/p>\n

Proper Private Behavior<\/h3>\n

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<\/code> API to determine whether users have granted your extension permission to run in private windows.<\/p>\n

Note that some WebExtension API may still affect private windows, even if the user has not granted the calling extension access to private windows. The browserSettings<\/a> 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.<\/p>\n

Finally, there is a known issue<\/a> where some extensions that use the proxy.settings API<\/a> 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.
\n<\/a><\/p>\n

User Scripts Are Coming<\/h1>\n

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. \u00a0With the help of a user script extension such as Greasemonkey<\/a> or Tampermonkey<\/a>, users can find and install scripts that modify how sites look and\/or work, all without having to write an extension themselves.<\/p>\n

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<\/code>:<\/p>\n

extensions.webextensions.userScripts.enabled = true<\/code><\/p>\n

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\u2019s being mentioned now. Documentation on MDN is still being developed, but below is a brief description of how this feature works.<\/p>\n

Registering A User Script<\/h3>\n

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

const registeredUserScript = await browser.userScripts.register(\r\n   userScriptOptions \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\/\/ object\r\n);\r\n\r\n...\r\nawait registeredUserScript.unregister();<\/pre>\n
userScriptOptions<\/code> is an object that represents the user scripts to register. It has the same syntax as the contentScript<\/code> options supported by browser.contentScripts.register<\/code> that describe which web pages the scripts should be applied to, but with two differences:<\/p>\n