Closed Bug 1212684 Opened 7 years ago Closed 6 years ago
_page manifest property for open extension API
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?
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?
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…)
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Note that options v2 was implemented: https://bugzilla.mozilla.org/show_bug.cgi?id=1250784
You need to log in before you can comment on or make changes to this bug.