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:

• the options_page manifest field is not marked as deprecated in the Chrome doc pages related to it (in particular https://developer.chrome.com/docs/extensions/mv3/manifest/ and https://developer.chrome.com/docs/extensions/mv3/options/)
• the doc page specifically meant to guide MV3 extension developer to introduce an option page is described first and implicitly suggested as the preferred one when the extension doesn't need the options_ui.open_in_tab option

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

This bug is about considering aliasing options_page to options_ui.page 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 (crbug.com/414920), e.g. the original documentation can be found at https://web.archive.org/web/20180404040632/https://developer.chrome.com/extensions/optionsV2, 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 https://chromium.googlesource.com/chromium/src/+/6fc0deca376bc07e3745830bbdf26ceff83f2eb3
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: https://source.chromium.org/chromium/chromium/src/+/main:extensions/common/manifest_handlers/options_page_info.h;l=34-37;drc=60039d4d4bd70512e21a2dfe586602aca1d9d35e

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

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.

When we introduce support for options_page, we should make sure that we set addon.optionsBrowserStyle to false by default, at https://searchfox.org/mozilla-central/rev/3563da061ca2b32f7f77f5f68088dbf9b5332a9f/toolkit/mozapps/extensions/internal/XPIInstall.jsm#492

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

https://hg.mozilla.org/mozilla-central/rev/b6b08acac28d

https://hg.mozilla.org/mozilla-central/rev/b6b08acac28d

MDN content changes are ready for review:

• BCD Adding manifest options_page support in FF126 #22877
• content Doc and release note for manifest options_page key support #33212