Configuring Firefox for Chrome and a Server

In this chapter, we will move our application from its home in a test directory to a setting that is more consistent with commercial implementations.

We will create two key pieces for implementing our application:

1. A local XUL application communicating with a Personal Hypertext Processor (PHP) server
   
2. A remote XUL application being served by PHP scripts

Both implementations will use an SQL database to hold user and password information to conduct the authentication process. Figure 4-1 shows a block diagram illustrating the relationship of the main elements of our design.

Figure 4-1.  NewsSearch information flow

This book uses the term XUL application to describe our NewsSearch project. This differs from conventional web applications that are designed to be served web pages that are rendered by web browsers. A XUL application, however, can be implemented as a page served to a XUL-capable browser, or it can be configured to run as an application local to the user’s machine. In the case of the latter, the files that comprise the application (JavaScript source, stylesheets, datafiles) are installed in a chrome directory and run as a chrome URL.

To date, the most popular XUL applications, such as the Firefox browser, Thunderbird mailer, and Sunbird calendar, are implemented as bundled applications running from the user’s chrome directory.

Web developers refer to traditional web applications as being subject to the rules of a security sandbox. Originating from the Java language’s security policy, the sandbox philosophy limits the reach of executable code to a certain area. For browsers, this means that unprivileged JavaScript can access data from a served document and from documents sharing its URL, but the browser infrastructure allows no access to the local filesystem or to potentially destructive operating system and network services.

There are cases when the local browser needs to store information on a user’s computer. This information may include bookmarks, runtime preferences, or other saved settings that would impair the user experience if not kept locally accessible; the sandbox is therefore expanded to include a controlled portion of the local filesystem. Applications that are registered within Firefox’s chrome are granted an area on the local disk to which full read/write access is granted.

In addition to meeting the security requirements imposed by the Firefox framework, a chrome application has a different look to it.

Before launching our code as a chrome application, we should change the testStyles.css stylesheet to provide a default background color for our window:

  window {
   background-color:white;
  }

(The default window color is needed when launching a chrome application from the command line.)

To see what our test application would look like as a chrome application, open a command window and launch Firefox from the command line, specifying the
–chrome option along with the pathname to the source file. The –chrome option directs the framework to display the source as a chrome window, not as a browser window.

On an OS X machine, the code would look like this:

  theUser% pwd 
  theUser% /Applications/Firefox.app/ Contents/MacOS
  theUser% ./firefox -chrome "file:Macintosh HD:tests:theWindowWithLogin.xul"

Our NewsSearch application now appears as a chrome window with none of the controls we associate with a browser (see Figure4-2 ).

Simply launching an application with the–chromeoption and a file URL will give us a chrome appearance, but to run it as a client/server chrome application, we will need to install the application as a chrome package, or serve the interface as a XUL page.

Figure 4-2.  Application launched as a chrome window