>-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of >[EMAIL PROTECTED] >Sent: Friday, March 28, 2003 1:11 AM >To: Marc Schwartz >Cc: 'Help R'; 'Anne York' >Subject: RE: [R] mozilla and R -- again >
> SNIP >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 >page). > >-- >Brian D. Ripley, [EMAIL PROTECTED] >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: file:///C:/PROGRA~1/R/rw1062/doc/html/search/SearchEngine.html Search Results Page (Using "plot"): file:///C:/PROGRA~1/R/rw1062/doc/html/search/SearchEngine.html Click on "abline": file:///C:/PROGRA~1/R/rw1062/library/base/html/abline.html Back Button to Search Results Page: file:///C:/PROGRA~1/R/rw1062/doc/html/search/SearchEngine.html Back Button to Main Search Page: file:///C:/PROGRA~1/R/rw1062/doc/html/search/SearchEngine.html 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 Files\R\rw1062\doc\html\search\SearchEngine.html Search Results Page (Using "plot"): C:\Program Files\R\rw1062\doc\html\search\SearchEngine.html Click on "abline": C:\Program Files\R\rw1062\library\base\html\abline.html Back Button to Search Results Page: C:\Program Files\R\rw1062\doc\html\search\SearchEngine.html Back Button to Main Search Page: C:\Program Files\R\rw1062\doc\html\search\SearchEngine.html Finally, in RH 8.0 using Mozilla 1.3 I get: Main Search Page: file:///tmp/Rtmp1560/.R/doc/html/search/SearchEngine.html Search Results Page: file:///tmp/Rtmp1560/.R/doc/html/search/SearchEngine.html Click on abline: file:///tmp/Rtmp1560/.R/library/base/html/abline.html Back Button to Search Results Page: file:///tmp/Rtmp1560/.R/doc/html/search/SearchEngine.html Back Button to Main Search Page: file:///tmp/Rtmp1560/.R/doc/html/search/SearchEngine.html 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: href="../../../library/base/html/abline.html" When using the Mozilla DOM inspector to look at the 'BaseURl' for the results page I get: Before: "file:///C:/PROGRA~1/R/rw1062/doc/html/search/SearchEngine.html" After: "wyciwyg://0/file:///tmp/Rtmp1560/.R/doc/html/search/SearchEngine.html " 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 wyciwyg://0/file:///C:/PROGRA~1/R/rw1062/doc/html/search/SearchEngine. html may not load or link to file:///C:/PROGRA~1/R/rw1062/doc/html/search/SearchEngine.html. 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 well. 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 ______________________________________________ [EMAIL PROTECTED] mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-help
