Publishing an Outlook-style compose ribbon (Experiment) on ATN, and possible upstream integration

Hi all,

I’m Vagner, from Bluecker (Brazil). We built “Faixa de Opções”, an add-on that recreates Outlook’s compose ribbon in Thunderbird, to help organizations move users from Outlook to Thunderbird.

What it does:

  • Message / Insert / Format Text / Help tabs, with Format Painter, Live Preview of fonts, colors and styles, Word-like styles, tables, Quick Parts, Outlook-style signatures per account, Check Names (Ctrl+K), delivery and read receipts, and Follow Up (flag for me / X-Message-Flag for recipients)
  • Keyboard navigation like Office (F6, arrows, Esc) and high-contrast support
  • Six languages: pt-BR, en-US, es, it, de, fr
  • Enterprise policies (3rdparty) for signatures, Quick Parts, support contact and defaults
  • Manifest V3 + WebExtension Experiment; built and tested on 153 ESR (also 156)

Why an Experiment: there is no WebExtension API to place UI inside the compose window, hide its toolbars, drive the editor with one undo step per command, or normalize the HTML at send time, so the ribbon runs as an Experiment in messengercompose.xhtml.

When I validate the XPI on ATN I get:

  • 1 error: “/experiment_apis: privileged manifest fields are only allowed in privileged extensions”
  • 21 warnings: “Invalid permissions compose” and " is not supported / has not been implemented by Firefox" (compose., windows.openDefaultBrowser and our own faixa. Experiment API)
  • Security, extension, locale and compatibility tests: all passed

Questions:

  1. Is this validator error expected for Experiment add-ons, and does it block a listed submission, or does it go to manual review? Is there anything we should change in the manifest?

  2. For a full-access Experiment of this size (~40 files, readable and unminified source, tests included), what does the review usually need from us?

  3. We would like to make the code open so Thunderbird developers can reuse parts of it, or integrate a ribbon-style compose UI into Thunderbird itself. We plan to release it under MPL-2.0. Is there interest, and where is the right place to start that conversation (Bugzilla, Phabricator, this list)?

    the ribbon:

Source: GitHub - vagner-dias/ThunderbirdComposeBar: ThunderbirdComposeBar · GitHub

Thanks!
Vagner — Bluecker

Hi @vagnerdias !

1. About the ATN validator error

Experiment APIs require manual review on Thunderbird Add-ons. The experiment_apis error is related to privileged extension functionality, so it isn’t necessarily evidence that your add-on is malformed. However, the validator output alone doesn’t guarantee approval. I’d recommend reviewing the Thunderbird Add-on Review Policy and waiting for the reviewer to clarify any submission-specific issues.

2. What to prepare for review

Since Experiments can access privileged Thunderbird internals, reviewers will need to understand exactly what your extension does and why those privileges are necessary. Your readable source code, tests, and compatibility information are a good start. I’d also provide clear installation and testing instructions, document the purpose of each custom Experiment API, and explain why the required functionality cannot be implemented using existing WebExtension APIs.

See the Thunderbird Experiment API documentation for additional guidance.

3. Open-sourcing and potential Thunderbird integration

I’d definitely encourage you to start a conversation with the Thunderbird developers about the broader idea.

Thunderbird Add-on Developer Community — a good starting point for discussing the technical approach.

Thunderbird development guide — explains how to propose and contribute changes to Thunderbird itself.

Thunderbird WebExtension Experiments repository — worth exploring if you identify reusable APIs that could benefit other extensions.

Bugzilla — appropriate for tracking a concrete feature request or implementation proposal after checking for existing issues.

One distinction worth keeping in mind: integrating the ribbon directly into Thunderbird would be a broader design and maintenance decision, whereas publishing the add-on under MPL-2.0 would let others inspect, reuse, and contribute to the code under that license.

Good luck with the submission! I’d be interested to see how the project develops.
Regards, AC1DST4R