Displaying a Web Page for Your Add-on Options

Update:I just want to clarify when this method can be used. Obviously a web page can’t update preferences in Firefox. We had a unique situation where a web page notified the browser of a change that allowed us to update a preference. It wasn’t a lot of preferences. There is a lot of debate over having web pages message add-ons in this manner.

A few of the add-ons I’ve developed use web pages for their options rather than having them in a dialog. Unfortunately, when you use a regular web page as an optionsURL in your install manifest, it’s opened up in a separate window that doesn’t have scroll bars and doesn’t work properly. Here’s a workaround.

Create a dialog that opens the web page in a new tab and then closes itself. Don’t forget to make sure it’s hidden. Here’s what it looks like:

<?xml version="1.0"?>
<dialog xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
  function displayOptionsPage() {
    var gBrowser = Components.classes['@mozilla.org/appshell/window-mediator;1']
    gBrowser.selectedTab = gBrowser.addTab("http://example.com/options");

You’ll see a quick flash in the middle of the screen, but otherwise it works. And it works really well on Firefox 4.

Hopefully future Firefox versions will detect that an optionsURL is a web address and simply open a new tab.

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *

2 thoughts on “Displaying a Web Page for Your Add-on Options

  1. This method is OK when your options are all implemented by a server, not stored locally, e.g. Facebook Options. You can also, for example, change localstorage content or cookies.

    It’s not appropriate for changing Mozilla prefs, because websites are not and should not be allowed to change the Mozilla preferences. That includes those Mozilla prefs used by the extension. Mozilla intentionally forbids that and extensions shouldn’t circumvent that restriction, for security reasons.

  2. Somehow when I select “Options” in the ForecastFox context menu, it opens http://www.getforecastfox.com/customize/13/ — the options are applied on the go, and remain applied (and saved locally AFAIK) when I close the page.

    Forecastfox has a lot of preferences so I suppose it isn’t the same extension Mike is talking about, but it might use the same method; the result is much nicer than a small modal dialog. Also, not much “privacy sensitive” information: the most “sensitive” is the place for which I want forecasts, and of course without that lat&long (which of course need not be where I live) I couldn’t get weather forecasts for “the place of my choice”. Not sure how it happens, javascript and/or cookies maybe. No XUL on the remote page of course since “remote XUL” doesn’t work in current trunk builds, and that extension does, including its remote “options page”.