[R] Re: Possible solution for Mozilla/help.start() search problems

jarrett@duke.edu
Mon, 25 Nov 2002 15:45:19 -0000

Thanks for your time and effort on this Marc.  Unfortunately, Apple has
"integrated" Java into Mac OS X (Darwin) and, according to a tech at
Apple, I cannot simply get a new Java plug-in.  I must wait for an update
of OS X.  So much for Java being platform independent.  BTW, I've tried
Netscape 7, IE 5.2 (both OS X) and Mozilla 1.0 and Opera (version?) (both
Darwin), all with the same problem.  In the meantime, I'm using the
help.search() and help() combo.  However, I seem to recall reading some
place that an earlier version of Netscape (4.x?) has its own Java
component and, presumably, would not depend on an external plug-in.
If/when I decide to investigate this, I'll report accordingly.  Thanks
again!

jarrett


On Sat, 23 Nov 2002, Marc Schwartz wrote:

> I thought that I would post a follow up given the several posts on this
> same subject in the past week. All R comments pertain to 1.6.1.
>
> Earlier in the week using a development build of Mozilla under RH 8.0, I
> was able to get the help.start() based search engine to work with both
> Java and JavaScript enabled. This was using what I believed to be the
> V1.2b branch of Mozilla, in which both Xft anti-aliasing font support
> and Gtk2 support for RH 8.0 was included. There are RH 8.0 specific RPMS
> located at:
>
> http://komodo.mozilla.org/pub/mozilla/nightly/experimental/gtk2/
>
> Upon verifying the version number however, this branch turns out to be
> V1.3a of Mozilla, not 1.2b. At least this is what it is identifying
> itself as. The build that worked was dated 2002-11-18.
> I post this for the sake of clarification.
>
> Late tonight, I updated my Mozilla installation with the latest build
> from the same branch, which is dated 2002-11-22.  Sure enough, the
> help.start() search engine is non-functional with this build.
>
> I spent some time tonight going back through and installing the several
> builds from this past week and the build dated 2002-11-20 does not work
> either.  Going back to the build from 2002-11-18 the search engine does
> work.
>
> The only common observation that I had made is that in the versions
> where the engine does not work, the browser status line message
> indicating that the Java applet has started, does not appear.  It does
> appear in the version from 2002-11-18, where the engine functions as
> expected. Thus it would seem that there is something intrinsic in the
> differing Mozilla versions that is inhibiting the R Java applet from
> properly loading and starting.
>
> I spent some time tonight on both the Sun and Mozilla sites reviewing
> FAQ's and Bugzilla and noted a variety of open Java related issues.
>
> However, I did find one clue in the Mozilla 1.2b Release Notes that
> seems to have worked and I now have the help.start() search engine
> working in the 2002-11-22 Mozilla 1.3a build. The note would suggest
> that the browser may have problems locating the required Java modules to
> load and start the applet.
>
> The fix seems to be to create (as root) a symlink to the file:
>
> /usr/java/JAVA_VERSION/plugin/i386/ns610/libjavaplugin_oji.so
>
> in your active Mozilla plugins directory.
>
> In the process of doing this, I noted that there were multiple Moz*
> directories in /usr/lib, given the updating that I have done since
> installing RH 8.0. There was no symlink in usr/lib/Mozilla-1.3a/plugins.
>
> Upon adding the symlink, lo and behold the help.start() search engine
> worked. If I remove the symlink, it fails.
>
> Thus it is possible that as folks update Mozilla and Java installations
> and the respective directory structures change from version to version,
> this may cause a problem for Mozilla in properly locating the Java
> modules required to run the R search engine.
>
> The pertinent release notes for Mozilla 1.2b are located at:
>
> http://www.mozilla.org/releases/mozilla1.2b/#java
>
> There are also comments there for Windows and similar comments are
> present in the release notes for earlier versions as well.
>
> I though I would pass this on as a possible solution given the problems
> noted here of late.
>
> HTH,
>
> Marc Schwartz
>
>
>
>
>
>
>
>
>
>