Closed Bug 1816960 Opened 1 year ago Closed 2 months ago

Consider aliasing options_page to


(WebExtensions :: General, enhancement, P3)



(firefox126 fixed)

126 Branch
Tracking Status
firefox126 --- fixed


(Reporter: rpl, Assigned: rpl)



(Keywords: dev-doc-complete, Whiteboard: [addons-jira])


(1 file)

In the past we wontfixed bugs related to support options_page (e.g. Bug 1212684 and Bug 1341136) because we implemented options_ui (Bug 1250784) and we were assumption that Chrome was going to deprecate options_page and remove support from it.

That doesn't seem to have actually happened, and on the contrary:

And so some of the new MV3 extensions published in the Chrome WebStore seems to be using options_page instead of

This bug is about considering aliasing options_page to and support both in Firefox to reduce the amount of Firefox specific changes that may need to be applied to extensions being ported from Chrome MV3 to Firefox MV3.

The following are equivalent:

  • "options_ui": { "page": "options.html", "open_in_tab": true }
  • "options_page": "options.html"

options_page was considered deprecated for a very long while when options_ui launched (, e.g. the original documentation can be found at, and mentioned

Older versions of Chrome will only recognize options_page, and only open in tabs. Chrome 40 and onwards prefer to use the options_ui field if it's specified.
Chrome will continue to support the options_page manifest field, but new and existing extensions should use the options_ui to ensure that their options pages are displayed as intended.

If you specify both, Chrome 40 and onwards will ignore the value of options_page.

In a future version of Chrome, any extension which specifies options_page will change to match the options_ui behavior - most importantly, they will always be embedded in chrome://extensions - so migrate as soon as possible.

At the time of introduction of options_ui, options_page was still in use and therefore difficult to deprecate/remove. The manifest version bump would have been a good opportunity to finally get rid of it. For some strange reason, that did not happen. Instead, options_page became featured more prominently in 2018 (when the optionsV2 page was removed) in
The changeset was motivated by "There is currently false information on Options Version 2 doc related to deprecation of options manifest registration.". There are no bugs or sources supporting the un-deprecation of this. In fact, the source code still have many references about options_page being replaced in favor of options_ui, e.g. at:;l=34-37;drc=60039d4d4bd70512e21a2dfe586602aca1d9d35e

// Returns the URL to the given extension's options page. This method supports
// both the "" field and the legacy "options_page" field. If
// both are present, it will return the value of "".

Safari supports options_ui and options_page, according to the Timothy and the BCD.

SInce it now appears to be part of the platform and the implementation is trivial, it may make sense to just support it, for the ease of migration.

Severity: -- → N/A
Priority: -- → P3

When we introduce support for options_page, we should make sure that we set addon.optionsBrowserStyle to false by default, at

... otherwise, options_page would default to use browser_style: true, which is something that we want to remove (bug 1827910).

See Also: → 1827910
Assignee: nobody → lgreco
Keywords: dev-doc-needed
Pushed by
Add support for options_page as an alias for r=robwu,amejiamarmol,geckoview-reviewers,extension-reviewers
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 126 Branch

MDN content changes are ready for review:

You need to log in before you can comment on or make changes to this bug.