R help - Mar 2003 - mozilla and R -- again

I noticed last week that when using mozilla (both 1.2 and 1.3) as  the
help browser in R, it exhibits the following behavior: 

1. assuming the browser is running go to the help -> "search engine and
key
words"

2. enter a string, say "plot"

3. when the "search results" are displayed, click on something, say
"abline"

4. go back to the search results using the browser "Back" button

5. click on something else, eg, "arrows"

Nothing happens.  I get the same results with mozilla 1.2 and 1.3
running R 1.6.2 in both RH 8.0 and Windows 2000.  

Seems like the links just die. I''m wondering if this is this simply a
mozilla issue as browsers work fine with R.  Or perhaps some of the R gurus
might have some idea if mozilla can be configured differently to work
better with R? 


Thanks,
Anne

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Anne E. York
National Marine Mammal Laboratory
Seattle WA 98115-0070  USA
e-mail: anne.york at noaa.gov
Voice: +1 206-526-4039
Fax: +1 206-526-6615
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>-----Original Message-----
>From: r-help-bounces at stat.math.ethz.ch 
>[mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of Anne York
>Sent: Thursday, March 27, 2003 3:52 PM
>To: Help R
>Subject: [R] mozilla and R -- again 
>
>
>I noticed last week that when using mozilla (both 1.2 and 1.3) 
>as  the help browser in R, it exhibits the following behavior: 
>
>1. assuming the browser is running go to the help -> "search 
>engine and key words"
>
>2. enter a string, say "plot"
>
>3. when the "search results" are displayed, click on 
>something, say "abline"
>
>4. go back to the search results using the browser "Back" button
>
>5. click on something else, eg, "arrows"
>
>Nothing happens.  I get the same results with mozilla 1.2 and 
>1.3 running R 1.6.2 in both RH 8.0 and Windows 2000.  
>
>Seems like the links just die. I''m wondering if this is this 
>simply a mozilla issue as browsers work fine with R.  Or 
>perhaps some of the R gurus might have some idea if mozilla 
>can be configured differently to work better with R? 
>
>
>Thanks,
>Anne

Anne kindly e-mailed me and we had an offline exchange on this prior
to her post here.  I can also confirm this behavior with R 1.6.2 under
WinXP using Mozilla 1.3.  

However, if I use IE 6 SP1, this does not occur. So this would seem to
be yet another example of a Mozilla related Java engine/applet issue.

When going back to the search results page using Mozilla, a quick
visual scan of the HTML code does not show any changes from the
initial version that worked.  If you move the mouse over the links,
the mouse changes, however the link URL does not show on the Mozilla
status line, suggesting that something is at least partially blocking
the link activation in the browser.

Regards,

Marc Schwartz

On Thu, 27 Mar 2003 16:20:32 -0600
Marc Schwartz <mschwartz at medanalytics.com> wrote:
> >-----Original Message-----
> >From: r-help-bounces at stat.math.ethz.ch 
> >[mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of Anne York
> >Sent: Thursday, March 27, 2003 3:52 PM
> >To: Help R
> >Subject: [R] mozilla and R -- again 
> >
> >
> >I noticed last week that when using mozilla (both 1.2 and 1.3) 
> >as  the help browser in R, it exhibits the following behavior: 
> >
> >1. assuming the browser is running go to the help -> "search 
> >engine and key words"
> >
> >2. enter a string, say "plot"
> >
> >3. when the "search results" are displayed, click on 
> >something, say "abline"
> >
> >4. go back to the search results using the browser "Back"
button
> >
> >5. click on something else, eg, "arrows"
> >
> >Nothing happens.  I get the same results with mozilla 1.2 and 
> >1.3 running R 1.6.2 in both RH 8.0 and Windows 2000.  
> >
> >Seems like the links just die. I''m wondering if this is this 
> >simply a mozilla issue as browsers work fine with R.  Or 
> >perhaps some of the R gurus might have some idea if mozilla 
> >can be configured differently to work better with R? 
> >
> >
> >Thanks,
> >Anne
> 
> 
> Anne kindly e-mailed me and we had an offline exchange on this prior
> to her post here.  I can also confirm this behavior with R 1.6.2 under
> WinXP using Mozilla 1.3.  
> 
> However, if I use IE 6 SP1, this does not occur. So this would seem to
> be yet another example of a Mozilla related Java engine/applet issue.
> 
> When going back to the search results page using Mozilla, a quick
> visual scan of the HTML code does not show any changes from the
> initial version that worked.  If you move the mouse over the links,
> the mouse changes, however the link URL does not show on the Mozilla
> status line, suggesting that something is at least partially blocking
> the link activation in the browser.
> 
> Regards,
> 
> Marc Schwartz
> 
> ______________________________________________
> R-help at stat.math.ethz.ch mailing list
> https://www.stat.math.ethz.ch/mailman/listinfo/r-help
With all the problems using java-based search on Linux I was wondering why java
was needed.  Could this have been done more simply?  I am not very knowledgeable
about java so please forgive me if the answer is obvious.
-- 
Frank E Harrell Jr              Prof. of Biostatistics & Statistics
Div. of Biostatistics & Epidem. Dept. of Health Evaluation Sciences
U. Virginia School of Medicine  http://hesweb1.med.virginia.edu/biostat

On Thu, 27 Mar 2003, Frank E Harrell Jr wrote:
>
> With all the problems using java-based search on Linux I was wondering
> why java was needed.  Could this have been done more simply?  I am not
> very knowledgeable about java so please forgive me if the answer is
> obvious.
Well, the searching needs a search program to be run, triggered by
something you do in the browser.

This requires either a program that can run in the browser (Java, as
JavaScript I don''t think can handle this sort of thing) or requires
some
way of calling R from the browser (even worse).

Better solutions would seem to require either R doing the HTML rendering
or R running an HTTP server.  Neither is out of the question, but it
isn''t
straightforward.  Stata uses the former solution and I believe SAS uses
the latter.

	-thomas

On Thu, 27 Mar 2003, Marc Schwartz wrote:
> >-----Original Message-----
> >From: r-help-bounces at stat.math.ethz.ch 
> >[mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of Anne York
> >Sent: Thursday, March 27, 2003 3:52 PM
> >To: Help R
> >Subject: [R] mozilla and R -- again 
> >
> >
> >I noticed last week that when using mozilla (both 1.2 and 1.3) 
> >as  the help browser in R, it exhibits the following behavior: 
> >
> >1. assuming the browser is running go to the help -> "search 
> >engine and key words"
> >
> >2. enter a string, say "plot"
> >
> >3. when the "search results" are displayed, click on 
> >something, say "abline"
> >
> >4. go back to the search results using the browser "Back"
button
> >
> >5. click on something else, eg, "arrows"
> >
> >Nothing happens.  I get the same results with mozilla 1.2 and 
> >1.3 running R 1.6.2 in both RH 8.0 and Windows 2000.  
> >
> >Seems like the links just die. I''m wondering if this is this 
> >simply a mozilla issue as browsers work fine with R.  Or 
> >perhaps some of the R gurus might have some idea if mozilla 
> >can be configured differently to work better with R? 
> >
> >
> >Thanks,
> >Anne
> 
> 
> Anne kindly e-mailed me and we had an offline exchange on this prior
> to her post here.  I can also confirm this behavior with R 1.6.2 under
> WinXP using Mozilla 1.3.  
> 
> However, if I use IE 6 SP1, this does not occur. So this would seem to
> be yet another example of a Mozilla related Java engine/applet issue.
> 
> When going back to the search results page using Mozilla, a quick
> visual scan of the HTML code does not show any changes from the
> initial version that worked.  If you move the mouse over the links,
> the mouse changes, however the link URL does not show on the Mozilla
> status line, suggesting that something is at least partially blocking
> the link activation in the browser.
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,                  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

On Thu, Mar 27, 2003 at 05:19:25PM -0800, Thomas Lumley
wrote:
> On Thu, 27 Mar 2003, Frank E Harrell Jr wrote:
> 
> >
> > With all the problems using java-based search on Linux I was wondering
> > why java was needed.  Could this have been done more simply?  I am not
> > very knowledgeable about java so please forgive me if the answer is
> > obvious.
> 
> Well, the searching needs a search program to be run, triggered by
> something you do in the browser.
> 
> This requires either a program that can run in the browser (Java, as
> JavaScript I don''t think can handle this sort of thing) or
requires some
> way of calling R from the browser (even worse).
> 
> Better solutions would seem to require either R doing the HTML rendering
> or R running an HTTP server.  Neither is out of the question, but it
isn''t
> straightforward.  Stata uses the former solution and I believe SAS uses
> the latter.
> 
> 	-thomas
I have just set up emacs to work with a text browser called w3m (using
emacs-w3m).  This is light and fast and displays webpages in an emacs
buffer.  It is surprisingly useful.  I also have a little function
that takes the output of help.search() and creates a webpage with
hyperlinks and can therefore do a search that creates a webpage and
then display the webpage in an emacs buffer.

I have just start trying to cobble something together that combines
these more formally and hope that I should be able to do something
like M-x help-search, enter a search phrase and display the results as
a webpage with links all in emacs/ESS/w3m.  I don''t have a clue about
lisp (except that it seems to involve lots of brackets and has a
considerable history) so this will is unlikely to move forward very
fast.  This does not provide all of the functionality of help.start()
but might be a way of getting free of these java issues (for those
happy to use emacs and ESS that is).

I am doing this on linux, but w3m is also available for MS Windows.

BTW just to push it I also used sweave(), xtable and latex2html
together - it was quite interesting, although latex2html does not
recognise the code environment - something else to tiniker with,
perhaps.  I haven''t yet tried the html package that was announced here
a short while ago, but the possibility of combining these as an
alternative way of displaying output from R (esp. large tables?) could
be fun to explore.

Dave
> 
> ______________________________________________
> R-help at stat.math.ethz.ch mailing list
> https://www.stat.math.ethz.ch/mailman/listinfo/r-help
-- 
Dave Whiting
Dar es Salaam, Tanzania

R-Community,

Having experinced similar broken links, I came upon the following work
around:
1) When the intial page is brought up from a search, 
instead of directly clicking on a link of interest, right click on the
link and open in a new tab.
2) In the new tab one seems to be able to follow links back and
forth....
3) in the orginal page returned by the search, one can follow  other
links to new tabs, etc.

Bit of a pain but it works most of the time: Even so, on occasion the
links seem to break....

This works on mozillia 1.3 and NS 7.02

cheers

Joel F. Kincaid, Ph. D.
Assistant Professor
Department of Economics and Finance
Franklin P. Perdue School of Business
Salisbury University
Salisbury Maryland, 21801
Phone: (410) 548-4416
Email:   jfkincaid at salisbury.edu 



Joel F. Kincaid, Ph. D.
Assistant Professor
Department of Economics and Finance
Franklin P. Perdue School of Business
Salisbury University
Salisbury Maryland, 21801
Phone: (410) 548-4416
Email:   jfkincaid at salisbury.edu

On Fri, Mar 28, 2003 at 06:38:22AM -0800, A.J. Rossini wrote:

[...]
> > fast.  This does not provide all of the functionality of help.start()
> > but might be a way of getting free of these java issues (for those
> > happy to use emacs and ESS that is).
> 
> Very, very interesting.  Let me know if I can help.
Without doubt.  How about this problem: I can get input from the
minibuffer and store it in a variable.  I haven''t yet found out how to
call R from a lisp function (or more correctly do thing like
eval-region/eval-my-search-function) and when I do I want to be able
to pass the entered value to the function.  I plan to try to work on
this over the weekend so if you can give me some pointers in that
direction it would be helpful.  Please remember though that I am very,
very new to lisp.
> Let us know if you make progress that you''d like to share!
Okay, will do.  BTW, what''s the best way to handle
discussion/collaboration on this?  Off-list, at least until something
more solid appears?  It is probably a little tangential to R-help for
now and I have not subscribed to the ESS list. 

Bye for now.

Dave

-- 
Dave Whiting
Dar es Salaam, Tanzania

>-----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 
>
> 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,                  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:
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

Correction:  In my prior post, I mixed the RH URL with the WinXP URL
in the following lines and should be corrected as:


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:///C:/PROGRA~1/R/rw1062/doc/html/search/SearchEngine
.html"


Of course the same relative phenomenon occurs in RH.


Marc Schwartz

Good evening all,

This will be my last post on this subject...I promise...  :-)

I have spent more time searching this evening on this, only because I
had some gut feelings that my first impression earlier today was not
entirely accurate. Indeed, that seems to be the case here. While I
have not located "conclusive" facts to explain this phenomenon, I have
located sufficient piecemeal information to at least suggest some
possibilities.

In addition, I am also rapidly coming to the conclusion that I am
learning much more about the internal workings of Mozilla than I
really need to know.  :-)

First, the URL showing in the Mozilla DOM/JavaScript Object browser in
WinXP that I referenced earlier
("wyciwyg://0/file:///C:/PROGRA~1/R/rw1062/doc/html/search/SearchEngin
e.html") reflects the use of the "wyciwyg" protocol, which is
apparently used by the Gecko engine to interact with the "Cache"
functions in the browser for **dynamically generated pages**. Thus the
active page URL is not actually "corrupted" as I suggested and this
also applies to the Linux variant of the same URL.

This may not be the sole "rasion d''etre" for wyciwyg, but it
certainly
seems to be a significant foundation.

In other words, as I understand it, when you use the Back and/or
Forward buttons and the page you are recalling was dynamically
generated, it is the wyciwyg protocol that Gecko uses to retrieve the
URL''s and the page from the Cache. Hence the prefix of
"wyciwyg://0/"
in the URL above.

There are several sites that came up in searches suggesting that the
combination of the wyciwyg protocol and Java/JavaScript, along with
both the memory and disk caches can result in the compromise of
"dynamically" generated pages (at least as they are rendered in the
browser after being recalled from the cache). In addition there are
references to possible security risks with the wyciwyg protocol due to
URL spoofing. 

There is an indication in Bugzilla that the latter issue has been very
recently resolved via patches to docshell and imposed restrictions on
what type of pages can be loaded via the wyciwyg protocol and it may
be this change that was reflected in the Security Warning in the
JavaScript Console that I included earlier today.

Some information on these sites would imply that the type of behavior
that we see with relative URL links from the R Java search engine
applet might be expected as a consequence of the combination of the
various above factors.

It is also suggested that the "broken URL" behavior does not occur in
MS IE since MS does not utilize the wyciwyg protocol approach to
recalling dynamically generated pages from IE''s cache. 

This would seem to reinforce the possibility that there is something
unique to the use of the wyciwyg protocol by the Gecko engine in this
scenario and the possibility of some "environmental" compromise of the
integrity of the page content in the browser.

In either case, since specific details are somewhat sparse, I am
unclear as to whether or not this behavior is to be fixed. What is
clear is that these symptoms appear to be known and at least similar
issues have been around for a period of time over which multiple
versions of Mozilla have been released without a change.

At this point, I''ll leave you with the above and presume that
we''ll
need to live with this behavior for at least the near term,
notwithstanding the workarounds discussed earlier.

Best regards to all,

Marc Schwartz

One other thing to mention.  w3m can be compiled with image support
(which seemed strange to me at first considering w3m is a text
browser).  Any, this means that graphics can also be displayed inline.
I have used Zed Shaw''s html.r and run his example code.  It works very
nicely.  I have a screen shot of the output if people want to see what
it looks like but don''t have a website on which to post it.  If anyone
wants to see it, let me know and I email it.  It is a 14k png file, so
is not too heavy.

I have also downloaded Eric Lecoutre''s R2HTML and will have a play
with that.  

So, all (?) I need to do now is learn enough lisp to stick it all
together.

Dave.




On Fri, Mar 28, 2003 at 06:35:39PM +0000, david.whiting at ncl.ac.uk
wrote:
> On Fri, Mar 28, 2003 at 06:38:22AM -0800, A.J. Rossini wrote:
> 
> [...]
> > > fast.  This does not provide all of the functionality of
help.start()
> > > but might be a way of getting free of these java issues (for
those
> > > happy to use emacs and ESS that is).
> > 
> > Very, very interesting.  Let me know if I can help.
> 
> Without doubt.  How about this problem: I can get input from the
> minibuffer and store it in a variable.  I haven''t yet found out
how to
> call R from a lisp function (or more correctly do thing like
> eval-region/eval-my-search-function) and when I do I want to be able
> to pass the entered value to the function.  I plan to try to work on
> this over the weekend so if you can give me some pointers in that
> direction it would be helpful.  Please remember though that I am very,
> very new to lisp.
> 
> > Let us know if you make progress that you''d like to share!
> 
> Okay, will do.  BTW, what''s the best way to handle
> discussion/collaboration on this?  Off-list, at least until something
> more solid appears?  It is probably a little tangential to R-help for
> now and I have not subscribed to the ESS list. 
> 
> Bye for now.
> 
> Dave
> 
-- 
Dave Whiting
Dar es Salaam, Tanzania