UserChrome.js

This page is to discuss the proposal to add the option for a userChrome.js file to all XUL applications. The relevant bug is bug 332529.

Bug Description

XUL applications can be customized in several different ways, from hacking the sources to installing extensions. userChrome.css sits at an intermediary level where for minor modifications neither hacking skills nor installing yet-another-extension are required. The many tip databases concerning CSS hacks are proof of its success.

However at the same level there is no corresponding file for JavaScript customization. Many minor needs could be fulfilled through a few lines of code run whenever a window is opened (as userChrome.css is always overlayed). While it is trivial to write an extension to that end, it shouldn't be necessary to install something worth about 10 lines of code for this.

userChrome.js could be a great help for developers (for testing hacks without having to modify core code/other extensions) and users (even finer grained control over how their browser behaves).

See the userChrome.js thread for possible use cases and an extension implementing those "10 lines of code".

Note that the above topic/thread mentions userChrome.js 0.8 for people using Firefox or Thunderbird 2.0 (and should be for 3.0 as well now) and who want to run code in "other windows than the main ones (without the WindowHook hack)" and that thread was broken and locked in the apparent "Great Data Loss" of October 18th (2007, it would seem), and was then continued on in the new thread which is also subtitled [support discontinued].

The most recent comment on the bug page mentioned in the first paragraph above (currently comment #12) seems to leave it open for "someone" to go ahead and implement this feature - but still assigned to "Nobody; OK to take it and work on it" - This seems to leave it a little unclear as to which example code is best/newest for someone wanting to try this out; as in - the 0.8 mentioned above, or the few other examples that can be found in the text and links on the bug page and the various linked threads and sites.

Points to Discuss

• While userChrome.css is applied to all XUL windows, it might be more effective to apply userChrome.js only to the application's main window (where most customization will happen). Making userChrome.js apply to all windows will require some boilerplate code to first figure out whether the code is applied to the correct window).

• userChrome.js might be run either as soon as possible or onLoad. Most customization I've seen so far requires for the chrome to be fully loaded. Applying it ASAP will require further boilerplate code to delay some code until the chrome is ready.

• Adding code snippets found on the net to userChrome.js might lead to security issues, since that would be a further attack vector for malicious code. OTOH, editing userChrome.js is more difficult than installing an extension - and adding a boilerplate warning to the file might reduce the risk to the same point users who don't read the Installation confirmation dialog are at.

• The simplicity of userChrome.js might get more people into simple JS programming. This can be an advantage (more users able to look after themselves) and a disadvantage (support nightmare for faulty userChrome.js - and a lot of requests for how-to-do-this and how-to-achieve-that).

userChrome.xul

Robert Strong raised the question whether to allow for userChrome.xul instead/in addition to userChrome.js.

Pro arguments

• Makes some customization tasks even simpler
• Allows the full flexibility of XUL/JS/CSS to be used in one file

Contra arguments

• The user has to know about XML/XUL and JS to achieve even the most basic hacks
• As a consequence, it's much easier to mess that file up
• An error in userChrome.xul quickly leads to an irritating gray border (whereas userChrome.js syntax errors just get you an entry in the Error console)