User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 The R Project uses a Java applet to search its help system. When the help system is installed locally so file:// links are used, the relative links it generates don't resolve properly. When the same files are installed on a web server and http access is used, they work fine. This sounds a lot like bug 317586 from 2005, but I can't reproduce it using their recipe. To reproduce it I need our more complicated scheme. I have been told this is a problem of all browsers based on the current version of Gecko, but I've only tried Firefox 3.0.5. I know it doesn't exist in a current Firefox 2.x or IE 6. Reproducible: Always Steps to Reproduce: To see the web pages as they should work, do the following: 1. Open http://developer.r-project.org/geckoBug/doc/html 2. Click on the "Search Engine and Keywords" link, which opens search/SearchEngine.html, and uses Javascript to start a Java applet, so make sure Javascript and Java are enabled. 3. Enter Rd2HTML as the search term, and click on Search. 4. A single search result will be returned. The URL of the results page will be listed as http://developer.r-project.org/geckoBug/doc/html/search/SearchEngine.html, and the search result (which has relative link "../../../library/tools/html/Rd2HTML.html" will work. 5. Now download http://developer.r-project.org/geckoBug.zip, and unzip the files somewhere local. This is a zipped copy of the geckoBug directory from the web page. 6. Open the index.html file in the geckoBug/doc/html directory in your local copy, and repeat steps 2, 3 and 4. This time the URL of the search result page will be shown as file:///C:/temp/geckoBug/doc/html/index.html (or whatever is local for you), and clicking on the result will try to go to the wrong place. Actual Results: A "File not found" error page. Expected Results: It should have gone to the right place, just as it did when those files were installed on a server. I will add the geckoBug.zip file as an attachment after filing; I don't guarantee to keep the demo code on developer.r-project.org indefinitely.

This is a copy of the http://developer.r-project.org/geckoBug directory described in the bug report, an extract of the index, supporting files (including .java source) and one help page from the full R help system.

Could this be some kind of mixup between <base href> and principals?

This works for me with trunk builds. Given the use of document.write to create the result document, looks to me like bug 445004. I plan to get this fixed in Firefox 3.0.7; unfortunately the fix wasn't approved for 3.0.6. And yes, comment 2 is more or less correct as to what was going on.