Daniel Pitts on JSObject and FireFox

[Richard Maher]

Hi Daniel et al,

I've got that nagging "JSObject == null" problem with passing a JavaScript
Object from FireFox to Java and when I was searching for a solution I found
this: -
http://groups.google.com/group/comp.lang.javascript/msg/7c8f34311e797e79

I have to applaud the ingenuity shown, but is this *really* what has to be
done to get FireFox to work? (Judging by some of the comments in that post,
Daniel is not aware that IE (no work-around reqd on IE6 at least) does
exactly what it's supposed to do with JSObject and I'm told Chrome works
equally well. Anyone know about Safari? Opera?)

I agree that quite a few similar posts on the net would indicate that FF
users have been experiencing this problem (back to 2005 at least) so I'm
guessing the FF dev people would've heard of it by now; any reason why
they're not fixing it?

Daniel's post shows up as 25/9/2008 so there's every chance that it's state
of the art. Does anyone have any better/other/more-integrated ideas?

Cheers Richard Maher

PS. Not that I'm ungrateful for a (possibly only) working solution. Well
done!

 

[Daniel Pitts]

Hi Daniel et al,

I've got that nagging "JSObject == null" problem with passing a JavaScript
Object from FireFox to Java and when I was searching for a solution I found
this: -
http://groups.google.com/group/comp.lang.javascript/msg/7c8f34311e797e79

I have to applaud the ingenuity shown, but is this *really* what has to be
done to get FireFox to work? (Judging by some of the comments in that post,
Daniel is not aware that IE (no work-around reqd on IE6 at least) does
exactly what it's supposed to do with JSObject and I'm told Chrome works
equally well. Anyone know about Safari? Opera?)

I agree that quite a few similar posts on the net would indicate that FF
users have been experiencing this problem (back to 2005 at least) so I'm
guessing the FF dev people would've heard of it by now; any reason why
they're not fixing it?

Daniel's post shows up as 25/9/2008 so there's every chance that it's state
of the art. Does anyone have any better/other/more-integrated ideas?

Cheers Richard Maher

PS. Not that I'm ungrateful for a (possibly only) working solution. Well
done!

It was state-of-the-art when I posted it. Since then, I've also run into
what appears to be threading issues causing firefox to crash :-( It's
unfortunate because every other aspect of our tool was targeting firefox.

 

[Mark Space]

It was state-of-the-art when I posted it. Since then, I've also run into
what appears to be threading issues causing firefox to crash :-( It's
unfortunate because every other aspect of our tool was targeting firefox.

I just noticed this on Sun's site. Related?

<http://java.sun.com/javase/6/docs/technotes/guides/plugin/developer_guide/java_js.html>


"Thread Safety

Because the DOM of each browser is implemented differently, DOM access
is not expected to be thread safe. Accessing implementation of DOM
objects in this specification must be restricted on the DOM access
dispatch thread only, so thread safely can be ensured. To accomplish
that, code accessing the DOM objects must be scoped within the
DOMAction.run() block. To invoke the action, either
DOMService.invokeAndWait() or DOMService.invokeLater() should be used,
so that DOMAction.run() will be executed in the DOM access dispatch thread.

Although implementations of DOM objects should not be called outside the
DOMAction.run() block, the application may cache these DOM objects
around as instance member of a class, or pass these DOM objects between
threads. However, caching the DOM objects as static members of any
object is prohibited, since static members tend to stay around much
longer than the lifecycle of the underlying DOM object.

The only object in the Common DOM classes that can be called from any
thread is DOMService. Access to other objects in the Common DOM classes
is restricted within the DOMAction.run() block; otherwise, an exception
will be thrown."

 

[Richard Maher]

Hi Daniel,

Thanks for the reply!

It was state-of-the-art when I posted it.

FWIW, I haven't seen it bested, and it is clever.

Please help me with the following questions if you can. I'm not trying to
pick holes in ither peoples code and I really need to do this. If you want
background you can look at
http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1323184
but be warned that it is long and much not relevant. Anyway on to the
questions: -

1) If I know that the only Thread that will callback to my static, named,
JavaScript function from my Applet is the SocketReader thread, then can I
not defeat the FF JSObject bug simply by originally receiving the outgoing,
message-specific, and complex object in the Applet method as a generic Java
"Object". That Object's properties and methods would be ignored and
preserved as it passes from JS-Java-JS, at which stage is message-specific
"callback" could be invoked. (Ok, maybe the "static" funtion should be
defined using JSObject.getWindow().eval(defineFunctionHere) at Applet init()
time, as per your naming example.)

2) Is your HashCoding (I'm guessing this is for per JSObject inside per
Applet uniqueness?) specific to your particular application? I'm also
guessing you have multiple Java threads (and possibly multiple Applets)
calling back to the same JavaScript functionality?

3) I'm worried about JS Garbage Collection of my Objects as there will no
longer be any references to them except on the Java side, stuck in a
LinkedList as their original Object. You may recall that I was worried about
this recently even with a JSObject wrapper, but a really helpful person
(Bojan) provided these references for me: -
http://www.docjar.com/html/api/netscape/javascript/JSObject.java.html
It is not much but see the description of the finalize method.
Found some more references that JSObject keeps the JavaScript reference.
This is true for gecko/mozilla based browsers. See this source:

http://xulrunner-1.9.sourcearchive.com/documentation/1.9~a8/jsj__JSObject_8c-sour
ce.html

and the description of JSRemoveRootRT:

https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference/JS_RemoveRootRT

The first link is to the xulrunner source but I found it in the firefox
source which is identical (or much similar) to the one from xulrunner.
Search for finalize in the code.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

So I was happy that the GC would not clean-up the JS objects I sent to Java
(and that would sometime later become the parameters to the callbak
routines) when they were wrapped in JSObject, but will the
Object-Referencing still hold true for vanilla Java Objects?

Anyway, sorry if the terminology is not correct, but I hope my
intentions/requirements are clear.

Since then, I've also run into
what appears to be threading issues causing firefox to crash :-(

Is it possible to provide a brief summary. I too will have at least one
additional separate thread.

Cheers Richard Maher

 

[Richard Maher]

1) If I know that the only Thread that will callback to my static, named,

JavaScript function from my Applet is the SocketReader thread, then can I
not defeat the FF JSObject bug simply by originally receiving the outgoing,
message-specific, and complex object in the Applet method as a generic Java
"Object". That Object's properties and methods would be ignored and
preserved as it passes from JS-Java-JS, at which stage is message-specific
"callback" could be invoked. (Ok, maybe the "static" funtion should be
defined using JSObject.getWindow().eval(defineFunctionHere) at Applet init()
time, as per your naming example.)

Just to add that I do understand that if the above is doable and if it is
the way I proceed, that I will be losing any of the benefits, functionality,
and methods of JSObject directly on what was passed in from JavaScript. No
[get/set]member() not Call() and so on.

Cheers Richard Maher

 

[Lew]

Hi MArk,

Please do not top-post.

 

[Richard Maher]

Hi MArk,

Isn't that *only* if your using the Common DOM API as opposed to JSObject?

Does anyone use the Common DOM API?

Cheers Richard Maher