1212684 - Implement options_page manifest property for open extension API

Status: RESOLVED WONTFIX

(WebExtensions :: Untriaged, defect)

Description

[Dan Callahan [:callahad]]

https://developer.chrome.com/extensions/options

Relatively straightforward: it just takes a path that gets opened in a new tab when you click "Preferences" in the add-on manager.

Unfortunately, this API was recently deprecated in favor of options_ui, which supports embedding the options in a modal on the extension page: https://developer.chrome.com/extensions/optionsV2

The migration note on that page mentions that:

1. options_ui trumps options_page when both are specified
2. future versions of Chrome will eventually start applying the options_ui behavior to the deprecated options_page property.

However we choose to implement this should be done in a way to make the future migration to options_ui as easy as possible. Heck, maybe just implement the final, post-deprecation state, where options_page behaves like options_ui by embedding a modal, rather than being on its own tab?

Comment 1

[Mindaugas <LA-MJ>]

If options.html page is opened in a tab manually it seems it is assigned a totally unprivileged context where neither |chrome.*| nor |ChromeWindow| APIs are available.

However, when |page_action| popup.html is opened in a tab, it gets full access to the extension background process and |chrome.*| APIs.

Is adding chrome APIs to the options page in the scope of this bug or should I create a new one?

Comment 2

[Blake Winton (:bwinton) (:☕️)]

Just as a note, this API is also used by https://github.com/notwaldorf/github-canned-responses/blob/master/manifest.json#L13 so it would be nice to have for that reason, too.  (Although I think Monica would accept a pull request that updated it to the new options_ui, if we were going to implement that instead…)

Comment 3

[Andy McKay]

Note that options v2 was implemented: https://bugzilla.mozilla.org/show_bug.cgi?id=1250784