fidzu : thunderbird

Github Link

The following changes have been pushed to bugzilla.mozilla.org:

• Bug 2081856 - Migrate Bug REST resource to native Mojo API: attachments (attachments, add_attachment, update_attachment)
• Bug 2080901 - [BMO-ETL] When any table fails to export, the entire snapshot should be rolled back to avoid incorrect results in charts/dashboards
• Bug 2085028 - log_user_request logs empty request_url/user_agent and server "web" for native Mojo API routes
• Bug 2067852 - Migrate rst docs to markdown and host inside of bugzilla itself
• Bug 2085553 - Github logins are failing with JSON error after recent changes to Bugzilla
• Bug 2078938 - Message/Banner for people creating tickets under mozilla.org :: GitHub: Administration
• Bug 2086615 - Change the ability to see groups a user is a member of via /rest/user?names= to the group can_see_groups
• Bug 1883428 - Improve the needinfo email situation (use HTML, drop unnecessary emails)

Discuss these changes in the BMO Matrix Room

1 post - 1 participant

Read full topic

28 Oct 2026 9:15pm GMT

We are thrilled to announce that enterprise add-ons will launch on addons.mozilla.org (AMO) on December 1, 2026.

In response to input from enterprise organizations that distribute add-ons strictly via Firefox enterprise policies, we are establishing a dedicated enterprise release channel.

This tailored channel directly serves enterprise developers' requirements while freeing up resources to continue supporting non-enterprise developers.

Why enterprise add-ons need their own policies

Many organizations rely on Firefox add-ons to keep their people and data safe: security tools, data loss prevention, identity and access management, and internal productivity tools. These add-ons work very differently from the ones most people install from AMO:

• They are deployed, not discovered. IT administrators install them across managed fleets using Firefox enterprise policies.
• Their reach is large. A single enterprise developer can serve thousands of managed browsers inside one organization.
• Their release cycle matters. When a security vendor ships a fix, customers expect it to reach their fleet quickly and predictably.

Until now, these add-ons went through the same manual review queue as everyone else, under rules written for consumer add-ons. That slowed organizations relying on Firefox and took reviewer time away from the rest of the community without making a meaningful impact.

What is changing on December 1

• A new enterprise channel: Versions submitted in the enterprise channel follow the new enterprise add-on policies.
• Enterprise versions stay in the enterprise channel: Versions submitted through the enterprise channel are only available through that channel. They won't appear on AMO or be distributed by Mozilla in any other way.
• A lighter manual review queue: With a limited set of policies applying to enterprise add-ons, reviewers can spend more of their time on other add-ons.
• An updated agreement for everyone: To adopt the new policies, all developers must accept the updated Firefox Add-on Distribution Agreement.
• The same bar for safety: Enterprise add-ons are still Add-ons are subject to Mozilla's Acceptable Use Policy.

The full policy text will be published on Extension Workshop. Until December 1, the current policies remain in effect.

How to take advantage of it

If you build add-ons for organizations: Read the enterprise add-on policies, and get ready to submit your enterprise versions through the enterprise channel from December 1.

In a nutshell, you must self-declare the enterprise status via the specific manifest key

"browser_specific_settings": {
   "gecko": {
      "admin_install_only": true
   }
}

If you build public add-ons: Nothing changes in how you submit or how your add-on is reviewed. The only thing you need to do is accept the updated agreement when prompted.

Quick Q&A: Who is this for?

Who are the enterprise add-on policies for?

Developers whose add-ons are built for organizations and deployed to managed Firefox installations through enterprise policies.

I'm an individual developer with a public add-on on AMO. Does this affect me?

Your submission process doesn't change, but you will need to accept the updated developer agreement.

My add-on is used by companies, but people also install it themselves from AMO. Is it an enterprise add-on?

Only versions you submit through the enterprise channel are enterprise versions, and those are available only through that channel. To keep your add-on listed on AMO, keep submitting it the usual way.

I only build an add-on for my own company's employees. Is this for me?

It can be. You can use the enterprise channel, or choose self-distribution, which is often the simplest route for add-ons meant for a smaller population.

I'm an IT administrator, not a developer. Do I need to do anything?

No. You keep deploying add-ons with Firefox enterprise policies as you do today.

Do I really need to accept the updated agreement?

Yes. Every developer on AMO, enterprise or not, needs to accept it, because the new policies are part of it.

When does this take effect?

December 1, 2026.

The post Introducing enterprise add-on policies appeared first on Mozilla Add-ons Community Blog.

28 Oct 2026 5:14pm GMT

New release of Firefox DevTools MCP. Available on npm at https://www.npmjs.com/package/@mozilla/firefox-devtools-mcp

Added

• New --idle-timeout option (IDLE_TIMEOUT). It sets how many seconds a --connect-existing session waits without tool calls before it releases Firefox. The default stays 1800 seconds (30 minutes). Firefox accepts one client at a time, so a shorter delay lets other clients connect sooner

Fixed

• upload_file_by_uid works again. Since 0.10.5 it did not set any file. It now uses WebDriver BiDi input.setFiles, and no longer changes the style of a hidden file input
• --connect-existing now fails at once with a clear error when another WebDriver session already holds Firefox. Before, it failed after about 60 seconds with "unknown error"
• --connect-existing now gives up after 45 seconds when Firefox asks the user to allow the session and nobody answers. Before, it waited forever. The error points at the prompt
• Shutting down the server while Firefox waits for the user to allow the session no longer leaves geckodriver running
• set_viewport_size now only changes the viewport of the selected tab, instead of resizing the whole window. With --connect-existing, the resized tabs are reset when the session closes
• evaluate_script with a timeout above 10 seconds no longer stops after 10 seconds with a generic BiDi timeout error

Changed

• navigate_history now uses WebDriver BiDi
• BiDi command errors now include the message sent by Firefox
• The README explains how to run a --connect-existing Firefox in a dedicated profile, next to your everyday Firefox

Full changelog: Release v0.10.7 · mozilla/firefox-devtools-mcp · GitHub
Repository and issues: GitHub - mozilla/firefox-devtools-mcp: Model Context Protocol server for Firefox DevTools - enables AI assistants to inspect and control Firefox browser through WebDriver BiDi · GitHub
Public chatroom: https://chat.mozilla.org/#/room/#firefox-devtools-mcp:mozilla.org

1 post - 1 participant

Read full topic

28 Oct 2026 11:28am GMT