[R] mozilla and R -- again

Marc Schwartz mschwartz at medanalytics.com
Fri Mar 28 20:20:51 CET 2003

>-----Original Message-----
>From: r-help-bounces at stat.math.ethz.ch
>[mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of 
>ripley at stats.ox.ac.uk
>Sent: Friday, March 28, 2003 1:11 AM
>To: Marc Schwartz
>Cc: 'Help R'; 'Anne York'
>Subject: RE: [R] mozilla and R -- again 


>I get similar behaviour in Netscape 7.02. There the link does show.
>However, after going back it is a relative URL not an absolute 
>URL, so the browser has lost the base URL.  Given this is an 
>auto-generated page, that 
>is not too suprising: going back to auto-generated pages often 
>does not 
>work (and the URL in the address box was wrong, still that of 
>the previous 
>Brian D. Ripley,                  ripley at stats.ox.ac.uk
>Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
>University of Oxford,             Tel:  +44 1865 272861 (self)
>1 South Parks Road,                     +44 1865 272866 (PA)`
>Oxford OX1 3TG, UK                Fax:  +44 1865 272595

I spent some time searching both Mozilla's Bugzilla and some
Mozilla/Netscape Usenet groups this morning. While I have not found a
parallel of this particular situation, I do find some posts suggesting
problems with the Gecko DOM implementation with respect to the
handling of relative URL's in Java and JavaScript.

These posts are as recent as this month, while others go back two or
three years. Some of them also suggest that these relative URL related
problems seen in Gecko based browsers (which of course includes NS)
are not seen in MS IE, which is consistent with what I have observed
in this situation. 

To Prof. Ripley's point, the address bar URL does not change upon
returning to the search results or main search page. The address bar
sequence that I see with Mozilla 1.3 under WinXP is as follows:

Main Search Page:

Search Results Page (Using "plot"):

Click on "abline":

Back Button to Search Results Page:

Back Button to Main Search Page:

Note that the address bar URL did not change either forward or
backward at the Search Results page.

In IE 6 SP1, I get the following sequence in the address bar:

Main Search Page: C:\Program

Search Results Page (Using "plot"): C:\Program

Click on "abline": C:\Program

Back Button to Search Results Page: C:\Program

Back Button to Main Search Page: C:\Program

Finally, in RH 8.0 using Mozilla 1.3 I get:

Main Search Page:

Search Results Page:

Click on abline: file:///tmp/Rtmp1560/.R/library/base/html/abline.html

Back Button to Search Results Page:

Back Button to Main Search Page:

Prompted by Prof. Ripley's reply regarding the use of relative URL's,
I did some further "digging", keeping in mind that the actual HTML
code in the various help.start() related pages are relative URLs. To
wit, the results page URL for 'abline' under WinXP:


When using the Mozilla DOM inspector to look at the 'BaseURl' for the
results page I get:



So this would suggest that the URL after hitting the Back Button is
being corrupted, as Prof. Ripley suggested.

When I go into the Mozilla JavaScript Console after using the Back
Button, I get:

Error: [Exception... "Component returned failure code: 0x80004005
(NS_ERROR_FAILURE) [nsIURI.hostPort]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://navigator/content/nsBrowserStatusHandler.js :: anonymous ::
line 350"  data: no]
Source File: chrome://navigator/content/nsBrowserStatusHandler.js
Line: 350

Security Error: Content at
html may not load or link to

Curiously, the Security Error seems to be picking up the mis-match
between the correct URL and the corrupted version.

It was mentioned in a post this morning by Prof. Kincaid that tabbed
browsing in Mozilla works (ie. open the search results target page in
a new tab instead of in the same tab) and I concur. That seems to work

Is there any sense in using absolute URL's in just the search results
page HTML as opposed to relative URL's? It is not relative URL's in
and of themselves that are problems, but apparently when used in
conjunction with Java/JavaScript.

Perhaps I am overlooking other implications of such a change and given
that there are work arounds near term, I would imagine that this would
be a lesser priority issue.

I hope the above information might provide some insights.

Best regards,

Marc Schwartz

More information about the R-help mailing list