275359 - [extension/java/xpcom] various fixes and improvements

Status: RESOLVED FIXED

(Core Graveyard :: Java to XPCOM Bridge, defect)

Description

[Michal Ceresna]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041128 Firefox/1.0 (Debian package 1.0-4)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041128 Firefox/1.0 (Debian package 1.0-4)

these are various fixes and improvements to the code in extensions/java/xpcom

Reproducible: Always

Steps to Reproduce:

Comment 1

[Michal Ceresna]

Attachment: many java objects mapping to one xpcom object

Comment 2

[Michal Ceresna]

Attachment: XPCOM.queryInterface searches all ancestort interfaces

Comment 3

[Michal Ceresna]

Attachment: import and export XPCOM instances to/from external party (e.g. SWT)

Comment 4

[Michal Ceresna]

Attachment: possibility to init javaXPCOM without calling NS_InitEmbedding

Comment 5

[Michal Ceresna]

Attachment: XPCOM errorcodes

Comment 6

[Michal Ceresna]

Attachment: report location of the xpcom exception

Comment 7

[Michal Ceresna]

(In reply to comment #1)
> Created an attachment (id=169191) [edit]
> many java objects mapping to one xpcom object
> 

this patch is the most interesting one, fixes problem of code like this

nsICookieManager cm = ...
nsISimpleEnumerator en = cm.getEnumerator();
while (en.hasMoreElements()) {
  nsISupports s = en.getNext();
  nsICookie c = (nsICookie) s.queryInterface(nsICookie.NS_ICOOKIE_IID); //fails
}

the problem is that the xpcom instance seen from getNext() is coupled 
with the nsISupports_Stub and then ca not be casted to nsICookie anymore.

First, the patch makes possible to map several java-stubs onto one xpcom
instance. Then when an xpcom->java wrapper is required a java instance
is searched or created using the given IID

Additionally I had to fight with releasing of global weak references at any
time by jvm. (because now xpcom instance had associated list of java objects,
and the references were vanishing while iterating that list).
So I've updated the implementation of the java<->xpcom mapping tables
in a similiar way as in the QT/Java implementation.

Comment 8

[jhp (no longer active)]

Comment on attachment 169196 [details] [diff] [review]
report location of the xpcom exception

I just checked in a patch that reworks the exception handling, so this patch is
no longer necessary.

Comment 9

[jhp (no longer active)]

Comment on attachment 169192 [details] [diff] [review]
XPCOM.queryInterface searches all ancestort interfaces

Handle this patch in bug 273357.

Comment 10

[Michal Ceresna]

remaining patches updated wrt. code: 
 cvs-2005-01-26 + patches from bug 279649 

Comment 11

[Michal Ceresna]

Attachment: many java objects mapping to one xpcom object (v2)

Comment 12

[Michal Ceresna]

Attachment: import and export XPCOM instances to/from external party (e.g. SWT) (v2)

Comment 13

[Michal Ceresna]

Attachment: possibility to init javaXPCOM without calling NS_InitEmbedding (v2)

Comment 14

[Michal Ceresna]

Attachment: XPCOM errorcodes (v2)

Comment 15

[jhp (no longer active)]

Comment on attachment 172466 [details] [diff] [review]
many java objects mapping to one xpcom object (v2)

Spun off this patch into bug 281102.

Comment 16

[jhp (no longer active)]

Comment on attachment 172467 [details] [diff] [review]
import and export XPCOM instances to/from external party (e.g. SWT) (v2)

Michal, can you explain or give an example as to why this import/export code is
necessary?  I'm familiar with SWT's Mozilla browser code, so you can reference
it.

Comment 17

[Michal Ceresna]

(In reply to comment #16) 
the exportInstance is used to get the nsIWebBrowser interface associated with 
an swt.Browser widget 
 
long p = gecko.getnsIWebBrowserPointer(); 
nsIWebBrowser brow = (nsIWebBrowser) 
  XPCOM.importInstance(p, nsIWebBrowser.NS_IWEBBROWSER_IID); 
nsIWebNavigation nav = (nsIWebNavigation) 
  brow.queryInterface(nsIWebNavigation.NS_IWEBNAVIGATION_IID); 
nsIDOMDocument doc = (nsIDOMDocument) nav.getDocument(); 
//do something useful with the DOM 
... 
 
 
the hook into the swt.Browser: 
 
public long getnsIWebBrowserPointer() { 
    //mine the private field 
    nsIWebBrowser webBrowser = getnsIWebBrowser(this); 
    int[] ret = new int[1]; 
    int rc = webBrowser.QueryInterface(nsISupports.NS_ISUPPORTS_IID, ret); 
    if (rc != XPCOM.NS_OK) { 
        throw new SWTError("XPCOM error "+rc); //$NON-NLS-1$ 
    } 
 
    return ret[0]; 
} 
 
JNIEXPORT jobject JNICALL 
Java_com_lixto2_swt_browser_mozilla_GeckoExt_getnsIWebBrowser 
  (JNIEnv* env, jclass mozillaExtCls, jobject swtBrowserObj) 
{ 
    jclass cls; 
    jfieldID fid; 
    jobject nsIWebBrowserObj; 
 
    //org.eclipse.swt.browser.Browser 
    cls = (*env)->GetObjectClass(env, swtBrowserObj); 
 
    if (!cls) return 0; 
    fid = (*env)->GetFieldID( 
      env, cls, "webBrowser",  
      "Lorg/eclipse/swt/internal/mozilla/nsIWebBrowser;"); 
    if (!fid) return 0; 
    nsIWebBrowserObj = (*env)->GetObjectField(env, swtBrowserObj, fid); 
    return nsIWebBrowserObj; 
} 
 
 

Comment 18

[Michal Ceresna]

(In reply to comment #16)  
the importInstance is used when interacting with other parts of 
mozilla that do not have xpcom/IDL interfaces 
(e.g. widget, view layers) 
 
This is an outline of such code, I've stripped things 
like getting the blinking color and duration from (eclipse) 
preferences, grouping into several Display.syncExec() blocks 
to not freeze the UI. 
 
//simulate mouseclick in the webpage 
MouseEvent me = ... (from EMF model) 
nsIDOMNode target = ...  
long targetPtr = XPCOM.exportInstance(target);  
long eventPtr =  
  NavigatorNative.  
  createMouseEvent(me.getType(),  
                   targetPtr,  
                   me.getRelX(), me.getRelY(),  
                   me.getShiftKey(), me.getCtrlKey(),  
                   me.getAltKey(), me.getMetaKey(),  
                   me.getButton());  
//blink the target node  
for (int i=0; i<MousePerformer.NUM_BLINKS; i++) {  
  NavigatorNative.drawOutline(targetPtr);  
  NavigatorNative.clearOutline(targetPtr);  
}  
//enough blinking, proceed to event sending  
NavigatorNative.sendEvent(targetPtr, eventPtr);  
//destroy event  
NavigatorNative.destroyEvent(eventPtr);  
//NS_RELEASE the target dom node  
NavigatorNative.releaseRef(targetPtr);  
  
  

Comment 19

[Michal Ceresna]

(In reply to comment #16) 
>possibility to init javaXPCOM without calling NS_InitEmbedding (v2) 
 
Also this patch is related to the javaxpcom <-> swt.Browser interaction. 
 
When you create the first swt.Browser instance, the NS_InitEmbedding is 
called. 
Therefore, javaxpcom needs also a way of initialization without  
calling the NS_InitEmbedding again. 
 

Comment 20

[jhp (no longer active)]

Attachment: XPCOM errorcodes v3 (checked in)

This patch integrates Michal's gen script into the build process.  I changed
the script a little.  Normally, error codes in Mozilla are |unsigned int|s; 
since Java doesn't support that, I had to make them all |long|.  I also made
the script spit out a licensing statement; don't know if there is a good way to
make perl just duplicate the licensing block at the top of nsError.h (I'm not
good at perl, so if you know, Michal, show me how).
I made it so XPCOM.java implements the XPCOMError interface.  This will allow
developers to easily specify errors (i.e. XPCOM.NS_ERROR_FAILURE).

Comment 21

[jhp (no longer active)]

(In reply to comment #17)
> the exportInstance is used to get the nsIWebBrowser interface associated with 
> an swt.Browser widget 

I don't understand.  I have an updated version of the SWT.Browser code that uses
the Javaconnect interfaces.  So, the Browser.webBrowser object is already an
nsIWebBrowser Java proxy.  So the exportInstance code shouldn't be necessary;
that is, if you are using my SWT.browser code!  If you want that code, Michal,
let me know.

Comment 22

[jhp (no longer active)]

(In reply to comment #18)
OK, so this makes more sense.  This implies that certain SWT constructs need the
underlying raw XPCOM address, not the Java proxy (so there is no way for those
methods to take the Java proxy, they specifically need the raw pointer?).

So maybe the best approach is to add an |address()| method on the Java proxy
that returns the raw XPCOM pointer as a |long|.  And then we'd need a method
like your |importInstance()|, that takes a raw pointer and returns the correct
Java proxy object.  Right?

Comment 23

[jhp (no longer active)]

(In reply to comment #19)
As I mentioned above, the correct solution is for SWT.Browser to be rewritten
using Javaconnect.

Comment 24

[jhp (no longer active)]

Closing this bug as FIXED.  Open new bugs for other issues.