The Add-on SDK should support loading of files other than browser.xul as top level native windows. For example, I want to create an addon that is a prototype of a replacement for the Bookmark Manager window.

I guess to be useful there also needs to be a good way to package chrome:// files with the add-on, so marking this as depending on bug 559306.

We actually forewent this API intentionally, because it doesn't seem like a common use case, and because we didn't want to encourage addons to create OS windows, since they burden users with window management (which is why other Firefox windows like the Add-ons Manager are becoming pages that open in browser tabs). Nevertheless, there could be a good use case for such an API, and it should be relatively easy to implement as a third-party API by someone who needs the functionality for their own addon or wants to provide it to other addons. If such an API were implemented by a third-party, and it subsequently became popular among addon developers, we'd certainly consider including it in the core SDK package at that time. FWIW, an API for this shouldn't need a chrome.manifest file and chrome/ directory. Instead, it can solicit the URL to a file in the data/ directory, which addons can obtain via require("self").data.url(), and open that URL in a new window. That doesn't support overriding an existing window with a new one, but the chrome.manifest support for overrides isn't restartless in any case, so it's not a great way to implement such a feature. For the specific use case of prototyping a replacement for the Bookmark Manager window, my recommendation would be to implement it as a page that opens in a browser tab, just like the native Add-ons Manager.

(In reply to comment #2) > FWIW, an API for this shouldn't need a chrome.manifest file and chrome/ > directory. Instead, it can solicit the URL to a file in the data/ > directory, which addons can obtain via require("self").data.url(), and open > that URL in a new window. That doesn't support overriding an existing > window with a new one, but the chrome.manifest support for overrides isn't > restartless in any case, so it's not a great way to implement such a feature. It may not absolutely NEED to be chrome, but it is very highly desirable. Using a data file means that an unnecessary message passing interface has to be crossed to pass the tree of current bookmarks to the data page, and pass all editing actions back to the privileged add-on code. There's really no need for the data page to be restricted to chrome privs, so a chrome:// URL would make the add-on a lot simpler. > For the specific use case of prototyping a replacement for the Bookmark > Manager window, my recommendation would be to implement it as a page that > opens in a browser tab, just like the native Add-ons Manager. It's not possible to replicate what the Add-ons Manager currently does with tabs, because to do that you'd want to open a tab without an address bar or any toolbars.

Filed bug 658973 on supporting opening of a tab without showing the address bar or any toolbars.