For now, if a developer want to provide a page like about:addons, about:config, ... He has to jungle between Tabs and an external library to implement an about: protocol. Or for most of them opening a document with an horrible URL resource://jig40594359-40350435/foobar-foo-my-extension-data/page.html It would be an API very close to Page-Worker. And it could be even more cool with bug 612726 fixed!

And as Tab.attach method is currently much less visible than entire page-mod API, many developers use page-mod to interact with their custom tab.

Irakli wrote a module for custom protocol handlers and an About page helper. Listed here: https://wiki.mozilla.org/Labs/Jetpack/Modules

We might land something like this as an experimental API for 1.0.

(automatic reprioritization of 1.0 bugs)

Marking anything that potentially looks like a feature request as "enhancement", sorry for the bugspam. :)

Re-prioritizing all 1.1-targeted feature requests to 1.2.

(Pushing all open bugs to the --- milestone for the new triage system)

I'm going to use this bug to provide following feature: https://wiki.mozilla.org/Features/Jetpack/Add-onTab-API

The current browser code that handles whether to hide the chrome or not is limited. It just calls this function: http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#4742 which tests the url against a specific list of urls to hide the chrome for. If we wanted we might want to make a change to this function to do other tests, maybe always hide for a specific protocol for example. Alternatively we can just add URLs to the whitelist whenever browser.xul is opened I imagine.

(In reply to Dave Townsend (:Mossop) from comment #9) > If we wanted we might want to make a change to this function to > do other tests, maybe always hide for a specific protocol for example. > Alternatively we can just add URLs to the whitelist whenever browser.xul is > opened I imagine. I can think of several options we can go about this: ## Option 1 ## Implement `resource` like `addon` protocol so that each jetpack add-on would get it's own `addon:{{id}}` url. For example `foo@jetpack.com` add-on will have associated `addon:foo@jetpack.com` URI pointing to a `foo@jetpack.com` add-on's `./data/index.html` file. All the other files in the data folder could be accessed via `addon:foo@jetpack.com/bar.html` like urls. This way `hideChromeForLocation` can be modified so that, if location is `addon:{{id}}` it would be hidden. With such API users will just have to provide `index.html` and everything else will be taken care of. ## Option 2 # Implement simple API in jetpack for registering URIs that must be hidden. `require('addon-page').register(require('self').data.url('./index.html'));` This way when page with url `require('self').data.url('./index.html')` is loaded chrome will be hidden for it. To implement this we'll probably have to define xpcom service for registering / unregistering / enumerating / addon-page uri's and extend `hideChromeForLocation` so that it will make use of this service. With this API users will have to register / unregister url's they don't wish to have browser chrome for. ## Option 3 ## Same as 2, but instead of defining XPCOM service, each add-on could keep track of each browser window and mutate `inContentWhitelist` array as necessary. ## Option 4 # Same as 2, but instead of XPCOM we could have a pref containing elements of `inContentWhitelist` that add-on's will mutate and `hideChromeForLocation` will look into to decide.

On the whole I like option 1, it makes the checks in browser.js very simple (they have to be as anything we do there impacts page load times) and doesn't require modifying inContentWhitelist in any way which runs the risk of getting out of sync somehow. Note that an earlier version of the patch for bug 571970 had Firefox looking into the loaded page to see if its root element contained a specific element and using that to decide whether to hide a page. That might be another option but we threw it out originally as we only needed something very simple and fast.

I really like first option too. It sounds like a great feature that may be commonly used by power users when they want to tune an addon. Like about:config, about:addons. I think that this addon protocol should be managed by Firefox itself, not by each jetpack addon individually. AddonManager should manage it and ask for the path/url to register though bootstrap.js or something alike. Then we may have to tackle all these little platform issues that lives around "simple URIs" and non regular HTTP URLs, otherwise we will have to land complex code into Firefox. Current about:* pages doesn't really care about all these issues, like relative path (images, css and links), indexedDB or some web framework like jQuery doesn't work by default with such URI. Here is some code that may be a good candidate to land in Firefox: https://github.com/ochameau/jetpack-runner/blob/master/lib/directory-protocol.js With no dependencies and shortest possible. It can be simplified as it support a special URL pattern to get some data in the URI: protocol:arg1:arg2:arg3:...

(In reply to Alexandre Poirot (:ochameau) from comment #12) > I really like first option too. It sounds like a great feature that may be > commonly used by power users when they want to tune an addon. Like > about:config, about:addons. > > I think that this addon protocol should be managed by Firefox itself, not by > each jetpack addon individually. I agree, that it would be nice to share this across add-on's, but landing it to firefox first will take longer than we desire. That's not to say we should not, but I'd prefer to land it into sdk first and then move part of implementation transparently to firefox itself. > AddonManager should manage it and ask for > the path/url to register though bootstrap.js or something alike. > Then we may have to tackle all these little platform issues that lives > around "simple URIs" and non regular HTTP URLs, otherwise we will have to > land complex code into Firefox. Current about:* pages doesn't really care > about all these issues, like relative path (images, css and links), > indexedDB or some web framework like jQuery doesn't work by default with > such URI. > Here is some code that may be a good candidate to land in Firefox: > > https://github.com/ochameau/jetpack-runner/blob/master/lib/directory- > protocol.js > With no dependencies and shortest possible. It can be simplified as it > support a special URL pattern to get some data in the URI: > protocol:arg1:arg2:arg3:... This code gives a system principals to all the pages under the mapped directory, which is I don't think is a good idea. Also, I worked hard to implement alternative https://github.com/Gozala/jetpack-protocol that is able to do the same but preserve original principals.

I had in person discussion with myk about these options & in particular we discussed idea of implementing option#1, via module that is shared across add-ons. To do so, module must be exposed as an XPCOM service that loader will reference if exists or register and then use if not registered yet. I also created bug 706590 to track progress of this separately.

(In reply to Irakli Gozilalishvili [:irakli] [:gozala] from comment #13) > (In reply to Alexandre Poirot (:ochameau) from comment #12) > > AddonManager should manage it and ask for > > the path/url to register though bootstrap.js or something alike. > > Then we may have to tackle all these little platform issues that lives > > around "simple URIs" and non regular HTTP URLs, otherwise we will have to > > land complex code into Firefox. Current about:* pages doesn't really care > > about all these issues, like relative path (images, css and links), > > indexedDB or some web framework like jQuery doesn't work by default with > > such URI. > > Here is some code that may be a good candidate to land in Firefox: > > > > https://github.com/ochameau/jetpack-runner/blob/master/lib/directory- > > protocol.js > > With no dependencies and shortest possible. It can be simplified as it > > support a special URL pattern to get some data in the URI: > > protocol:arg1:arg2:arg3:... > > This code gives a system principals to all the pages under the mapped > directory, which is I don't think is a good idea. Also, I worked hard to > implement alternative https://github.com/Gozala/jetpack-protocol that is > able to do the same but preserve original principals. Your protocol library is just better, more powerfull and more features. I was only suggesting this shortest-specific-custom implementation just in case we wanted to land it quickly in Firefox. Otherwise, it will be better to use yours, for sure! About landing in Firefox, I'd really like to see us working closer with Firefox team instead of rushing in our own codebase. And as dcm said, our Q4 goals are about landing patches, but not about having features shipped in releases. Having said that the XPCOM service will do the job and we already are 12/01, so, we may not have time to do it properly?

After running into multiple bottlenecks with a chosen implementation strategy, I have decided to work towards much more simplified version first and enhance it over time. At the moment plan is use WindowTracker to override each new window's `XULBrowserWindow.inContentWhitelist` array to include `data/index.html` of the loaded add-on. On the unload of an add-on all the tabs with `data/index.html` page of the given add-on will get closed to make sure there will be no attempt to load it after restart. I also plan to continue working on existing patches to later replace this minimal support with more enhanced version.

Pointer to Github pull-request

Commit pushed to master at https://github.com/mozilla/addon-sdk https://github.com/mozilla/addon-sdk/commit/8d34075d1c1feffa41f60670c7778d49725ac8aa Merge pull request #338 from Gozala/bug/simple-addon-page@644595 Bug 644595 - Implement very minimal support of add-on page API. r=@ochameau

This bug is fixed, right? It landed in Feb 2012? Please reopen if there's more needing to be done in here.