Comment 1 _ 2010-08-17 11:34:45 EDT

also, fyi

locate swt | grep \.so | grep lib | grep usr
 /usr/lib64/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_64.source_3.4.0.v3448f.jar
 /usr/lib64/swt/libswt-atk-gtk-3347.so
 /usr/lib64/swt/libswt-awt-gtk-3347.so
 /usr/lib64/swt/libswt-cairo-gtk-3347.so
 /usr/lib64/swt/libswt-glx-gtk-3347.so
 /usr/lib64/swt/libswt-gnome-gtk-3347.so
 /usr/lib64/swt/libswt-gtk-3347.so
 /usr/lib64/swt/libswt-mozilla-gtk-3347.so
 /usr/lib64/swt/libswt-pi-gtk-3347.so
 /usr/local/eclipse/libcairo-swt.so

Comment 2 Steffen Pingel 2010-08-17 23:13:28 EDT

This looks like a problem with the local xulrunner installation. Please see http://www.eclipse.org/swt/faq.php#specifyxulrunner . What is the actual error that is displayed in the editor of the task editor (not when you click the link)?

Comment 3 _ 2010-08-18 00:34:24 EDT

(In reply to comment #2)
> This looks like a problem with the local xulrunner installation. Please see
> http://www.eclipse.org/swt/faq.php#specifyxulrunner . 

I have.  It states there:

"Typically a Mozilla-based Browser uses XULRunner's lookup mechanism to find a registered XULRunner at runtime, in which case a XULRunner location does not need to be specified"

checking,

xulrunner --gre-version
 1.9.2.8

xulrunner --find-gre 1.9.2.8
 /usr/lib64/xulrunner-1.9.2.8/libxpcom.so

ls -al /usr/lib64/xulrunner-1.9.2.8/libxpcom.so
 -rwxr-xr-x 1 root root 18904 2010-08-04 01:31 /usr/lib64/xulrunner-1.9.2.8/libxpcom.so

xulrunner finds it -- so should Eclipse, right?

> What is the actual error
> that is displayed in the editor of the task editor (not when you click the
> link)?

"Submit failed: An unknown repository error has occurred: not allowed"

Comment 4 Steffen Pingel 2010-08-18 00:55:39 EDT

I would recommend filing the xulrunner bug against platform. There is nothing we can do to address this in Mylyn except to handle the error better (tracked on bug 316234).

Frank, do you know what the "not allowed" error on submission indicates?

Comment 5 _ 2010-08-24 02:15:26 EDT

just checking in @ ~1wk.  triage?

Comment 6 Grant Gayed 2010-08-24 15:04:30 EDT

Just to confirm, pressing the Submit button is the first time that a Browser widget is created, right? (ie.- you say you're able to see bugzilla reports, but they're being shown somewhere other than in a Browser widget).

It's possible that swt's library is failing to load if it's detecting your 32-bit xulrunner.  Can you try pointing the Browser explicitly at one of your 64-bit xulrunners by specifying a -D launch property as described in http://www.eclipse.org/swt/faq.php#specifyxulrunner (note that the instructions are slightly outdated, you should add this -D... switch in your eclipse.ini file before launching eclipse).

Comment 7 _ 2010-08-24 15:37:57 EDT

(In reply to comment #6)
> Just to confirm, pressing the Submit button is the first time that a Browser
> widget is created, right? (ie.- you say you're able to see bugzilla reports,
> but they're being shown somewhere other than in a Browser widget).

here's what I see when I 'view' the bug,

  http://img163.imageshack.us/img163/4899/eclipsez.png

when I make a change, and click on Submit, i get:

  http://img842.imageshack.us/img842/8130/eclipse2.png

that's it.

> It's possible that swt's library is failing to load if it's detecting your
> 32-bit xulrunner.  Can you try pointing the Browser explicitly at one of your
> 64-bit xulrunners by specifying a -D launch property as described in
> http://www.eclipse.org/swt/faq.php#specifyxulrunner (note that the instructions
> are slightly outdated, you should add this -D... switch in your eclipse.ini
> file before launching eclipse).

i changed/added @ /usr/local/eclipse/eclipse.ini,

    -startup
++    -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib64/xulrunner-1.9.2.8
plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar
    --launcher.library
    ...

with no apparent effect.  error occurs as before.

i also tried (docs are unclear -- folder, or file, path?)

  -D.../usr/lib64/xulrunner-1.9.2.8/libxpcom.so

again, no dice.

Comment 8 Grant Gayed 2010-08-24 15:56:40 EDT

Sorry, the -D switch to add to eclipse.ini would be...

-Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib64/xulrunner-1.9.2.8/

...and it should be added at the end of the eclipse.ini file to ensure that it follows the -vmargs switch.

Comment 9 _ 2010-08-24 16:03:12 EDT

(In reply to comment #8)
> Sorry, the -D switch to add to eclipse.ini would be...
> 
> -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib64/xulrunner-1.9.2.8/
> 
> ...and it should be added at the end of the eclipse.ini file to ensure that it
> follows the -vmargs switch.

and that seems to do the trick.

no error, and "successful submission"

thx!

Comment 10 Grant Gayed 2010-08-25 08:26:39 EDT

Ok, that's good to hear.  XULRunner's detection functionality does not provide a way to specify whether a 32- or 64-bit gecko is to be detected, so if it gets the wrong one then the Browser's only recourse is to guess at another location.  Since your error logs indicate that the swt-mozilla library is failing to load (not the swt-xulrunner library) I suspect that this is what's happening.

As a data point to see if cases like this may be better handled, can you run the snippet at http://www.eclipse.org/swt/faq.php#printmozillapath and paste its output here?

Comment 11 _ 2010-08-25 12:09:35 EDT

(In reply to comment #10)
> As a data point to see if cases like this may be better handled, can you run
> the snippet at http://www.eclipse.org/swt/faq.php#printmozillapath and paste
> its output here?

Sure.

"The SWT snippet below can be used to print the location of the Mozilla browser that was found."

how?

From inside of Eclipse? Standalone?  I've Eclipsed configured for RSE, PHP & Mylyn use ... something else needs to be installed?

Comment 12 Grant Gayed 2010-08-25 13:50:49 EDT

Created attachment 177451 [details]
compiled DisplayMozillaVersion

I'm not sure if your eclipse contains the Java IDE, so the following should be the easiest way to do this:

- copy the attached .class file into your eclipse root directory
- at the command line cd to your eclipse root directory, then: (ensuring that the swt jar name below matches what you have)

% java -cp .:plugins/org.eclipse.swt.gtk.linux.x86_64_3.6.0.v3650b.jar DisplayMozillaVersion

Comment 13 _ 2010-08-25 14:19:12 EDT

(In reply to comment #12)
> I'm not sure if your eclipse contains the Java IDE,

aha.  no.  it doesn't

> so the following should be the easiest way to do this:

thanks

here's the output, as requested:

java -cp .:plugins/org.eclipse.swt.gtk.linux.x86_64_3.6.0.v3650b.jar DisplayMozillaVersion
>>>Snippet creating SWT.MOZILLA-style Browser
cannot use detected XULRunner: /usr/lib/xulrunner-1.9.1.11
>>>This failed with the following error:
org.eclipse.swt.SWTError: No more handles [Failed to use detected XULRunner: /usr/lib64/firefox]
        at org.eclipse.swt.SWT.error(SWT.java:4109)
        at org.eclipse.swt.browser.Mozilla.create(Mozilla.java:633)
        at org.eclipse.swt.browser.Browser.<init>(Browser.java:119)
        at DisplayMozillaVersion.main(DisplayMozillaVersion.java:13)


Snippet creating SWT.NONE-style Browser
cannot use detected XULRunner: /usr/lib/xulrunner-1.9.1.11
Mozilla path: /usr/lib64/firefox
>>>succeeded
Exception in thread "main" org.eclipse.swt.SWTError: XPCOM error -2147467262
        at org.eclipse.swt.browser.Mozilla.error(Mozilla.java:2347)
        at org.eclipse.swt.browser.Mozilla.unhookDOMListeners(Mozilla.java:2777)
        at org.eclipse.swt.browser.Mozilla.onDispose(Mozilla.java:2370)
        at org.eclipse.swt.browser.Mozilla$5.handleEvent(Mozilla.java:872)
        at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1258)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1282)
        at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1263)
        at org.eclipse.swt.widgets.Widget.release(Widget.java:1080)
        at org.eclipse.swt.widgets.Control.release(Control.java:3302)
        at org.eclipse.swt.widgets.Composite.releaseChildren(Composite.java:1293)
        at org.eclipse.swt.widgets.Canvas.releaseChildren(Canvas.java:208)
        at org.eclipse.swt.widgets.Decorations.releaseChildren(Decorations.java:469)
        at org.eclipse.swt.widgets.Shell.releaseChildren(Shell.java:2303)
        at org.eclipse.swt.widgets.Widget.release(Widget.java:1083)
        at org.eclipse.swt.widgets.Control.release(Control.java:3302)
        at org.eclipse.swt.widgets.Widget.dispose(Widget.java:462)
        at org.eclipse.swt.widgets.Shell.dispose(Shell.java:2239)
        at org.eclipse.swt.widgets.Display.release(Display.java:3221)
        at org.eclipse.swt.graphics.Device.dispose(Device.java:237)
        at DisplayMozillaVersion.main(DisplayMozillaVersion.java:27)


as suspected, seems to be confusion bet /usr/lib & /usr/lib64 ...

Comment 14 Grant Gayed 2010-09-16 10:55:45 EDT

Updating report title to reflect the underlying cause.

I'm a bit surprised that the Browser isn't handling this better, because when it fails to use a detected xulrunner it should fall back to trying the one found by the eclipse launcher.  I'm wondering if the eclipse launcher is failing to provide an a good alternative xulrunner install to try.  Questions:

1. Linux env. var. MOZILLA_FIVE_HOME is NOT set to anything before launching eclipse, right?

2. Does your linux install have any of the following files, and if so, what's in them?
    /etc/gre64.conf
    /etc/gre.d/gre64.conf
    /etc/gre.conf
    /etc/gre.d/gre.conf

Comment 15 _ 2010-09-16 11:03:59 EDT

(In reply to comment #14)
> 1. Linux env. var. MOZILLA_FIVE_HOME is NOT set to anything before launching
> eclipse, right?

atm, that's correct

> 2. Does your linux install have any of the following files, and if so, what's
> in them?
>     /etc/gre64.conf
>     /etc/gre.d/gre64.conf
>     /etc/gre.conf
>     /etc/gre.d/gre.conf

nope,

ls -1 \
 /etc/gre64.conf \
 /etc/gre.d/gre64.conf \
 /etc/gre.conf \
 /etc/gre.d/gre.conf
	/bin/ls: cannot access /etc/gre64.conf: No such file or directory
	/bin/ls: cannot access /etc/gre.d/gre64.conf: No such file or directory
	/bin/ls: cannot access /etc/gre.conf: No such file or directory
	/bin/ls: cannot access /etc/gre.d/gre.conf: No such file or directory

Comment 16 Grant Gayed 2011-05-11 13:16:28 EDT

Created attachment 195396 [details]
patch that attempts to consider Mozilla ABI

On further investigation, XULRunner did actually start including ABI info in its registration a couple of releases ago, so it is possible for the Browser to give it hint regarding the desired architecture.  The attached patch attempts to detect a XULRunner with this additional info provided.

Comment 17 Grant Gayed 2011-05-11 13:17:40 EDT

The .classpath_gtk change is not meant to be part of the patch.

Comment 18 Grant Gayed 2011-05-18 09:55:15 EDT

Created attachment 195973 [details]
revised patch

Revised patch.  This is the best that can be done to help the XULRunner detection magic find us a XULRunner that matches SWT's arch.

Comment 19 Grant Gayed 2011-05-18 10:03:27 EDT

fixed > 20110518