#MOZILLA FIREFOX EXTENSIONS SETTING HOW TO#
#MOZILLA FIREFOX EXTENSIONS SETTING UPDATE#
#MOZILLA FIREFOX EXTENSIONS SETTING CODE#

Extensions can use webRequest listeners to observe their own requests initiated by the downloads API.

If more changes to add-ons are necessary we will reach out to developers individually or announce the changes here. We encourage you to subscribe to our blog to stay up to date on the latest developments. We will continue to monitor changes that will require add-ons to be updated.

If you need help or have any questions, come find us on our community forum or Matrix. We’re working to make the transition to Fission as smooth as possible for users and extension developers, so we need your help: please test your extensions with Fission enabled, and report any issues on Bugzilla as blocking the fission-webext meta bug.

#MOZILLA FIREFOX EXTENSIONS SETTING UPDATE#

If you are the developer of an extension that uses one of these features, we recommend that you update your extension in the coming months to avoid potential breakages. You should switch to the captureTab method, which we are looking to extend with more functionality to provide a sufficient replacement.

The synchronous canvas drawWindow API will be deprecated, since it’s unable to draw out-of-process iframes.

The recommended pattern, as always, is to use postMessage and extension messaging instead.

Content scripts injecting extension iframes (from a moz-extension:// url) and accessing them directly via the contentWindow property will be incompatible with Fission, since that iframe will run in a different process.

So far, we have identified two changes with Fission enabled that will impact extensions: The platform team is planning to begin roll-out to Nightly and Beta users later this year. This new model, nicknamed Fission, is currently available for opt-in testing in Nightly. The Firefox platform team has been working on a new security architecture that isolates sites from each other, down to separating cross-origin iframes from the tab’s process. Firefox site isolation coming later this year

#MOZILLA FIREFOX EXTENSIONS SETTING HOW TO#

Also, if you are getting support requests from users related to stored preferences you may want to keep this change in mind and support them in filing a bug as necessary.įor more information and how to file a bug in case you come across issues with this change, please see the blog post.

#MOZILLA FIREFOX EXTENSIONS SETTING CODE#

We encourage you to make your code resilient while your storage needs grow by checking for quota errors. There is no immediate action required if you don’t use the storage.sync API or are only storing small amounts of data. Storage quotas for the storage.sync API are now being enforced as part of backend changes we’ve introduced for better scalability and performance. We’ve blogged about this recently, but given this is part of Firefox 79 I wanted to make sure to remind you about the storage.sync changes we’ve been working on.

It is merely a performance improvement when the tab switch can be anticipated, such as when hovering over a button that when clicked would switch to the tab. Note this API does not work on discarded tabs and does not need to be called immediately prior to switching tabs. With the new tabs.warmup function, tab manager extensions will be able to benefit from the same perceived performance improvements. Switching to it then feels much more instantaneous. When Firefox anticipates that a tab will be activated, the tab is “warmed up”. To optimize resource usage, render information on inactive tabs is discarded. We have a little more news this release: a new API method, a reminder about a recently announced change, a preview of some things to come, and a few interesting improvements.

Mozilla firefox extensions setting