[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.platform.swt] Re: SWT Browser Questions on Gentoo Linux

One possibility is that in the case that is working (downloaded eclipse) the
xulrunner is being found by the xulrunner lookup mechanism, not by
MOZILLA_FIVE_HOME (this is one last piece of the Browser startup story which
was not explained in my previous response, but probably should have been).
The Browser does the MOZILLA_FIVE_HOME dance primarily in order to support
installations of Seamonkey, Firefox and Mozilla 1.4 - 1.7.x.  For xulrunner
support, swt has statically-linked xulrunner code which tries to find a
registered xulrunner install the first time a Browser is created.  This is
the prescribed way of linking to an external xulrunner install since it
ensures that the correct gecko libraries will be loaded.  My guess is that
the xulrunner detection is failing in your compiled eclipse case.  A simple
test of this:

- create a class with the following content:

public static void main(String[] args) {
    Device.DEBUG = true;
    Display display = new Display();
    Shell shell = new Shell(display);
    shell.setLayout(new FillLayout());
    final Browser browser;
    try {
        browser = new Browser(shell, SWT.NONE);
    } catch (SWTError e) {
        System.out.println("Could not instantiate Browser: " +
e.getMessage());
        return;
    }
    shell.open();
    /* any website with popups */
    browser.setUrl("http://www.eclipse.org";);
    while (!shell.isDisposed()) {
        if (!display.readAndDispatch()) display.sleep();
    }
    display.dispose();
}

- run it in each of your working and non-working eclipses with the
MOZILLA_FIVE_HOME environment variable set to /dev/null (set this in your
Run configuration's Environment tab)
- see what is printed to stdout, I think that the working eclipse case will
print something like "XULRunner path: /usr/lib/xulrunner/libxpcom.so" while
the non-working eclipse case will not be as lucky

Please follow up here with whether this is what happens for you.

Grant


"Jean-Noel" <elvanor2007@xxxxxxxxx> wrote in message
news:09ea183da418d7929bd0b4da7fcf26f5$1@xxxxxxxxxxxxxxxxxx
> Hi Grant,
>
> Much thanks for your very helpful reply. I did some more work, and here
> are my results.
>
> > It always needs an external html renderer, and on linux this will always
be
> > something gecko-based.
>
> OK, good to know.
>
> >> 2. "If you are running with eclipse 3.2.1 or newer then you can just
run
> >> eclipse and it will attempt to detect a browser on your system to use."
> >>
> >> Can you tell my how exactly the detection is done? How come running the
> >> binary package manages to discover it, but running from source does
not?
> >> Where is the code for this detection (I mean, in which plugin). Is it
in
> >> SWT?
>
> > This code lives in the eclipse launcher executable.  It basically goes:
> > - if MOZILLA_FIVE_HOME is already set then do nothing
> > - otherwise try to determine a value for MOZILLA_FIVE_HOME by:
> >   -> looking for a file like /etc/gre64.conf or /etc/gre.d/gre64.conf,
which
> > exists on some linux distros to point at an available Gecko
> >   -> trying some common installation locations, like
> > /usr/lib/[mozilla/firefox/xulrunner] and
> > /usr/lib/[mozilla/firefox/xulrunner]-<version> (usr/lib/mozilla-firefox
is
> > not a directory that gets checked here)
>
> > You can get the source for this from CVS (
> > http://www.eclipse.org/swt/cvs.php ) project
org.eclipse.equinox.executable.
>
> > If a Browser cannot not be created for some reason when eclipse is first
> > started then an alternate intro screen is shown, so you have to be aware
of
> > which case you're seeing.  The "correct" intro screen is greenish, which
> > indicates that a Browser was successfully created; the alternative intro
> > screen is white, which indicates the Browser creation failed.
>
> I've found this code and looked at it. You should have told me it was C
> code, I was looking for some Java code at first, so it took me a bit of
> time to find it, but that's ok ;)
>
> It basically works as you explained it. I can make my compiled Eclipse
> browser work by specifying the MOZILLA_FIVE_HOME.
>
> However there is still one thing I don't fully understand. I have a
> xulrunner installation in /usr/lib/xulrunner. This is a place that gets
> scanned. If I set
> MOZILLA_FIVE_HOME="/usr/lib/xulrunner" and load my compiled Eclipse
> everything works. If I don't set this env var, this does not work. The
> renderer is here (eg, the browser gets created), but the links etc don't
> work. Although it should not make a difference since the directory should
> get scanned!
>
> If I use the binary version from Eclipse, things work better: it works out
> of the box because the xulrunner install gets used. Although, another
> strangeness, it should *not*, because the file that gets tested in
> /usr/lib/xulrunner is:
>
> components/libwidget_gtk2.so
>
> and I *don't* have this file on my xulrunner directory. I have it on my
> mozilla-firefox directory though...
>
> Any ideas about this strange behavior?
>
> Jean-Noel
>