The first part of browser.xul consists of some standard declarations and functions. Keep going until you reach the entries labeled "command id". This is where we want to start our editing. The command id section consists of a series of global commands. These commands define common browser functions and most of the functions can be worked out from the name of the command id. What's special about command id's is that these ids apply to any number of browser interactions. For example, you can "View Page Source" in at least three different ways: the menu option "View - Page Source", CTRL+U and a right-click context menu option "View Page Source". All three involve different interactions with the browser but all three reference the same command id, "View:PageSource".
By commenting out this command id, we can effectively disable all three options. That saves us from having to find all of the locations where "View:PageSource" can be invoked. Instead, we comment it out in one location and it is disabled for all interactions with the browser. Because this step is so powerful, we need to be careful what we comment out. In some cases, we may want a function accessible from the main menus but not from a context menu or a keyboard shortcut. In those cases, we need to make those changes on an individual basis instead of globally by disabling the command id. Also, while we can disable commands globally, that doesn't mean a menu item won't appear for that command. While the menu may be disabled, it will still appear. In some cases, we'll also need to edit out the individual menu entries.
Let's get started by commenting out a number of unneeded command ids. We don't want users to be able to interact with the file system. To prevent that, we'll also disable those command ids related to that functionality. We also want to comment out any unneeded commands like "View Page Source" and other functionality that kiosk users do not need. As you browse the comments that I've added, you'll note that in some cases, we needed to work around functions that we wanted users to be able to access. In theory, we can shuffle the commands ids so that all of the disabled ids are together. However, I wanted to retain the original structure so that you can better follow the changes.
Now that we've made our first sets of edits to browser.xul, we'll want to test them out. Start by saving your changes to browser.xul. Next, start up your Zip utility. Choose the option to create a new archive and name it "browser.jar". Browse to the directory below the base directory, "content", of the files that we unpacked from browser.xul. WinZip will create the JAR file in this location. I would encourage you to create the JAR file in a location that you can easily locate and access. We want to include all of the files and subdirectories but we want them to be relatively references so don't include the full path information. With WinZip, we select the "Add with Wildcards" option to create our JAR file. Depending on your system resources, it should just take a minute or less to create the edited browser.jar.
Before we do anything with our new browser.jar file, we'll want to rename our original browser.jar file located in the Firebird chrome directory. This ensures that we have a backup in case something goes awry in our editing process. To keep things simple, I just rename it "browser-old.jar". Now we can cut and paste our edited browser.jar from the location where you asked WinZip to save it and into the Firebird chrome directory. I prefer to use a cut and paste versus a copy. This causes less problems for WinZip when we make further changes. If you want to live life dangerously or, if you created a copy of browser.jar but didn't rename the original, go ahead and allow the edited version to overwrite the original. If you are comfortable using the advanced features of WinZip, you can also use other options that allow you to only update the files that you have edited.
We can test our edits by starting up Firebird. If you added your comments correctly, Firebird should load without errors. We can test our edits by trying to invoke some of the commands that we commented out, like "View Page Source". Start by trying CTRL+U. If you made the change correctly, nothing should happen. Next, select "View - Page Source". While the menu item is displayed, the View Source window should not appear. Finally, try the right-click context menu "View Page Source". You might be surprised to see the "View Source" window appear. In this case, the context menu invokes a different command id that isn't available globally. We'll need to disable that option separately when we edit the context menus. As you can see, it's important to test all of your changes thoroughly.
If you made an error, Firebird will display an error indicating the line where the error starts and possible some information on the nature of the error. In some cases, the browser will then load but the interface may not display properly. If you do get an error message, go back and check your edits for unclosed comments or comments tags not typed correctly. Correct the error or errors and save the JAR file again. I encourage you to test your changes frequently. It's a lot easier to unravel a small error than to dig out an error discovered after a large number of edits.
Last updated: December 31, 2003
Created: December 1, 2002
If you are reading this, your browser probably doesn't support current HTML and CSS standards. While the site looks much better in a browser that supports web standards, you can still access all of the information that is here with any browser or Internet device.