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 homepage for possible use cases and an extension implementing those "10 lines of code".

Comparable functionality with a different API can also be found in the Labs/Ubiquity project.

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)