persistent, site-specific prefs prototype

I’ve been investigating options for improving user control over content, including persisting user decisions about appearance and behavior and overriding global preferences on a site-specific basis.

To test some ideas about how to do these things, I put together a prototype that implements a basic service for persisting site-specific preferences to a profile database.

The prototype also includes some experimental UI in the form of a sidebar into which controls for twiddling site-specific preferences can be placed. The sidebar currently contains one such control: a slider that sets the text zoom value (i.e. what View > Text Size > Increase/Decrease/Normal sets).

I’ve bundled up the prototype into an extension called (boringly) Content Preferences for Firefox 2 and up and posted it to addons. While it undergoes review on that site, the eager among you can get it from my web site: Install Content Preferences.

It should go without saying that this is early, rough alpha code, and you should exercise all due caution when testing it. To try it out, do the normal install and restart thing, then select View > Sidebar > Content Preferences.

Your feedback is welcomed.

Some voluminous notes for the compulsive informaddicts among you:

View > Text Size Impact

Once you install the extension, the View > Text Size menu items and their keyboard shortcuts also become site-specific and profile-persistent (i.e. lasts as long as your profile does). So even if you never open the sidebar, you still get the benefits of the extension with the existing text zoom UI.

If you uninstall the extension, that UI goes back to the way it was before (i.e. tab-specific and tab-persistent). No permanent harm done (AFAICT, YMMV, etc.).

The Slider

The sidebar slider’s magnification range is 1-400%, which is somewhat smaller than the View > Text Size commands’ range of 1-2000%, but the smaller range seemed more usable. The slider will follow any changes you make via View > Text Size as far as it can, then it’ll sit there lonely at the end of its range until you come back to it.

What is a Site?

A “site,” for the purposes of this early prototype, is the set of pages hosted at the exact same domain name (f.e. everything on

As David Baron has pointed out, figuring out what constitutes a site is an important component of an endeavour like this, so future prototypes will experiment with TLD+1 (* sites, www-optional sites ( ==, and anything else that seems promising.

Perhaps multiple domains secured by certificates granted to the same organization should count as one site?

Fixing Font Size on the Web

Finally, I’m aware of multiple proposals for fixing the font size settings in Firefox so they’re easier to use and get things right more of the time. And I’m also aware that the more we can get stuff like font size right without making users configure it themselves, the better.

This prototype doesn’t constitute a proposal for dealing with font size, it’s more an experiment in how to improve usability with persistence and site-specificity. I picked on text zoom only because itty-bitty fonts seem to be among the commoner complaints about the web, and also because hacking into text zoom seemed like a good testbed.

Even if we solve text size issues some other way, there will be other uses for the core service this extension provides. For example, Dave Camp overheard me describing this experiment a couple days ago and mentioned that he’s been looking for a way for users to grant additional DOMStorage space to particular sites. A site-specific preference service sounds like just his ticket.


Myk Melez

Myk is a Principal Software Architect and in-house entrepreneur at Mozilla. A Mozillian since 1999, he's contributed to the Web App Developer Initiative, PluotSorbet, Open Web Apps, Firefox OS Simulator, Jetpack, Raindrop, Snowl, Personas, Firefox, Thunderbird, and Bugzilla. He's just a cook. He's all out of bubblegum.


9 thoughts on “persistent, site-specific prefs prototype

  1. Pretty cool concept, I just have one minor suggestion for the text zoom demo and that is to delay calls to mozIContentPreferencesService.setPref() for a bit when changing the zoom level. Otherwise you end up hitting the disk about 900 times moving from one zoom extreme to the other 😉

  2. Note that DOM storage doesn’t fully implement the “what’s a site” thing as specified on globalstorage property, as the TLD logic is still to be done. Somewhere I found a bug on that, but I don’t recall the bugnumber right now.


  3. On the trunk you could presumably use nsIEffectiveTLDService to decide what constitutes a site. Using tld+1 is of course utterly broken for .uk and similar

  4. I’d find this useful for existing preferences too – pop-up blocking, cookie settings, etc., like Opera’s Site Preferences. I believe such a thing was suggested as a Google SoC project.

  5. How are you going to decide what settings to add first? Maybe you should collect some suggestions and then conduct a survey of which site specific settings people would find most useful.

    I’d like to to see the Advanced JavaScript Settings be site specific. I usually turn them all off except Disable or replace context menus but I might be willing to turn Change status bar text back on if I could just do it for sites I trust. I leave Disable or replace context menus on for ajax applications but there are some sites I’d like to turn if off for sites that disable the context menu (e.g. hush technologies grrr)

  6. This is very helpful for the Character Encoding setting, but I would like to see this updated for Firefox 3, please.

Comments are closed.