Solution for XHR ERROR: Response_Code = -1 Error_Message = Request Error

Problem: When trying to open a URL using Selenium RC 1.0.3 with Firefox 3.6, the following error is reported through the server log:

XHR ERROR: Response_Code = -1 Error_Message = Request Error

after which the browser windows disappear and the session is aborted. Interestingly, this only happens when trying to access remote sites, not sites from localhost.

Workaround: This error seems to be caused by something in the Firefox profile template provided with option -firefoxProfileTemplate. I temporarily edited selenium-browserbot.js within the selenium-server.jar to make it ignore the error (new line highlighted in red):

    this.isNewPageLoaded = function() {
        if (this.pageLoadError) {
            LOG.error("isNewPageLoaded found an old pageLoadError");
            var e = this.pageLoadError;
            this.pageLoadError = null;
            throw e;
        }

        if (self.ignoreResponseCode) {
            return self.newPageLoaded;
        } else {
            if (self.isXhrSent && self.isXhrDone) {
                if (self.xhrResponseCode == -1) return self.newPageLoaded;
                if (!((self.xhrResponseCode >= 200 &&
                    self.xhrResponseCode <= 399) ||
                    self.xhrResponseCode == 0)) {

With this change, the error ceased to be reported. I could no longer reproduce the problem later after removing this temporary fix.

Solution for Selenium RC Firefox startup crash

Problem: A Selenium RC server under Linux starts a Firefox 3 (or 3.5) process, which then crashes immediately. A useless error dialog mentioning Gnome bug-buddy appears, the test script hangs. When started manually, the same version of Firefox works without flaw (including the Selenium IDE add-on).

Solution: (note: this was written for Selenium RC 1.0.1; you may wish to try the most current version (eg. 1.0.3) before troubleshooting)

1. Check your ~/mozilla/.plugins and remove plug-ins (symlinks) that you don't need. In my case, the Java 1.4.2 Plug-in caused the crash.
2. If the above doesn't help, gathering more information related to the crash may provide a clue, as described in the following steps.
3. Write a little wrapper for the firefox script. Save it in /usr/local/firefox/firefoxg or somewhere else:

   #!/bin/sh
   exec /usr/local/firefox/firefox -g $*
   

   If you start Firefox using this wrapper, you will notice that instead of the browser a debugger opens, in my case, the ddd debugger frontend. You can then launch the executable by typing run in the debugger console. In case of a crash (segmentation fault), you will see a stack trace which may contain interesting clues.
4. Update your Selenium RC test script to reference the wrapper, e.g. browser => "*firefox /usr/local/firefox/firefoxg".
5. In the shell where you launch the Selenium RC server, set the environment variable GNOME_DISABLE_CRASH_DIALOG=1, so that Gnome bug-buddy doesn't bother you on crash.
6. Go ahead and start the test script. The debugger will open. Actually, two instances of the debugger will open, the second one only after the first one is terminated. Type run in the debugger console to continue execution in each case. In my environment the first instance just crashed gdb. However, the second instance produced a backtrace which helped to put blame on the Java plug-in as shown below: