My applet just stop in the middle of the initial screen drawing.. (1.4.2 and 1.5.0 VM) on Tiger using Camino (nightly). No error in the Java console / CPU normal. The same applet was working stable on Panther.
It uses extensive AWT drawing - and I guess that the new threading model might break it. Is there a way to disable this?
The funny thing is that it works with Safari.
Keep the byte.
Cdric
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I won't be able to help you unless you give me a URL to your applet or
the source code to enough of it to demonstrate your problem. (If you
do want to post source code, you should probably open a bug under the
Java Embedding Plugin's Bugs tracker.)
Does your applet use the CocoaComponent class (an Apple extension to
Sun's Java)? If not, then Tiger's new Java threading model should
make no difference to your applet.
No, it's not possible to turn off that threading model ... though
sometimes I've wished that it were :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just tried your URL, and it worked for me: After having logged on
and chosen to accept the certificate (for your signed applet), I
clicked on the pen-and-paper icon and the editor opened in a new
window. It's true it was a bit slow, and I had to make sure to wait
as long as needed at each stage. But it did work.
Tested on OS X 10.4 (Tiger) with JEP 0.9.1 in Mozilla 1.7.8, Firefox
1.0.4 and Camino 0.8.4.
Maybe our different results have something to do with the hardware
we're using: My Mac is a dual-1Ghz-CPU G4 (with 512KB of RAM).
It might help if you posted a stack trace for your browser after it
gets frozen. (For that you'll really need to open a bug in the Bugs
tracker.) If you don't already know, I can tell you how to generate
one.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I've tried again with a recent Camino nightly (2005-05-10-14), and
now it _is_ hanging. I've made my own stack trace ... so (as far as I
know) I no longer need one from you.
As far as I can tell, it isn't a bug in the Camino nightly. Nor is it
an AWT problem (instead it seems to involve TSM). What it _does_ seem
to be is yet another side effect of Tiger's new (expletive deleted)
threading model, which I'll need to learn how to work around.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> What it _does_ seem to be is yet another side effect of Tiger's new
> (expletive deleted) threading model, which I'll need to learn how to
> work around.
Oops, that's wrong.
It _is_ a problem with the Camino nightly. In fact, the problem
effects all nightlies (and alphas and betas) of all Mozilla-family
browsers created since 2004-04-25! At that point Mozilla.org made a
change in one of the OJI interfaces used by the MRJ Plugin which broke
JavaScript-to-Java LiveConnect. It's not visibly broken (it still
does work in some fashion). But it doesn't work the way it's supposed
to. And in Tiger (for complicated reasons having to do with it's new
Java threading model) it doesn't work at all.
The problem should (now that I realize its nature) be easy to work
around. I'll do so in the next release of the Java Embedding Plugin.
In the meantime use only released versions of Mozilla-family browsers
to do LiveConnect on Tiger -- don't use any of the nightlies.
I've opened a bug about this at bugzilla.mozilla.org
(https://bugzilla.mozilla.org/show_bug.cgi?id=293973), and I'll open
another in the Java Embedding Plugin's Bugs tracker with a more
detailed explanation than I've given here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've just released JEP 0.9.2, which fixes your problem. You should
upgrade as soon as possible, because the root cause of your problem is
a security hole, which effects all Mozilla-family nightlies, alphas
and betas (anything on the "trunk") issued since 2004-04-25. The hang
on Tiger is only a side effect ... though that's now fixed, too.
Thanks again for your report. It was while I was investigating it
that I stumbled upon the larger problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thx for the update - the funny thing is - with new version of the JEP the applet works again with the nightly builds of Firefox/Camino but hang on start-up with the public released versions. It gets a bit further in the loading process as with the 0.9.1 and the nightly browsers.
I have frequent browser crashes when working with the applet since updating to Tiger - happen also in Safari - therefore I guess it has nothing to do with the JEP.
Keep the byte.
Cdric
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
Thx for the new Tiger ready release.
My applet just stop in the middle of the initial screen drawing.. (1.4.2 and 1.5.0 VM) on Tiger using Camino (nightly). No error in the Java console / CPU normal. The same applet was working stable on Panther.
It uses extensive AWT drawing - and I guess that the new threading model might break it. Is there a way to disable this?
The funny thing is that it works with Safari.
Keep the byte.
Cdric
I won't be able to help you unless you give me a URL to your applet or
the source code to enough of it to demonstrate your problem. (If you
do want to post source code, you should probably open a bug under the
Java Embedding Plugin's Bugs tracker.)
Does your applet use the CocoaComponent class (an Apple extension to
Sun's Java)? If not, then Tiger's new Java threading model should
make no difference to your applet.
No, it's not possible to turn off that threading model ... though
sometimes I've wished that it were :-)
If you like to play around with it - try on
http://195.65.178.44/wizardtest
all further instructions are noted there. Let me know if you have questions or might seen something that help to narrow down the cause for the issue.
Nope - I don't use CocoaComponets classes.. - there is not Mac specific code in the applet.
Keep the byte.
Cdric
I just tried your URL, and it worked for me: After having logged on
and chosen to accept the certificate (for your signed applet), I
clicked on the pen-and-paper icon and the editor opened in a new
window. It's true it was a bit slow, and I had to make sure to wait
as long as needed at each stage. But it did work.
Tested on OS X 10.4 (Tiger) with JEP 0.9.1 in Mozilla 1.7.8, Firefox
1.0.4 and Camino 0.8.4.
Maybe our different results have something to do with the hardware
we're using: My Mac is a dual-1Ghz-CPU G4 (with 512KB of RAM).
It might help if you posted a stack trace for your browser after it
gets frozen. (For that you'll really need to open a bug in the Bugs
tracker.) If you don't already know, I can tell you how to generate
one.
OK, I've tried again with a recent Camino nightly (2005-05-10-14), and
now it _is_ hanging. I've made my own stack trace ... so (as far as I
know) I no longer need one from you.
As far as I can tell, it isn't a bug in the Camino nightly. Nor is it
an AWT problem (instead it seems to involve TSM). What it _does_ seem
to be is yet another side effect of Tiger's new (expletive deleted)
threading model, which I'll need to learn how to work around.
> What it _does_ seem to be is yet another side effect of Tiger's new
> (expletive deleted) threading model, which I'll need to learn how to
> work around.
Oops, that's wrong.
It _is_ a problem with the Camino nightly. In fact, the problem
effects all nightlies (and alphas and betas) of all Mozilla-family
browsers created since 2004-04-25! At that point Mozilla.org made a
change in one of the OJI interfaces used by the MRJ Plugin which broke
JavaScript-to-Java LiveConnect. It's not visibly broken (it still
does work in some fashion). But it doesn't work the way it's supposed
to. And in Tiger (for complicated reasons having to do with it's new
Java threading model) it doesn't work at all.
The problem should (now that I realize its nature) be easy to work
around. I'll do so in the next release of the Java Embedding Plugin.
In the meantime use only released versions of Mozilla-family browsers
to do LiveConnect on Tiger -- don't use any of the nightlies.
I've opened a bug about this at bugzilla.mozilla.org
(https://bugzilla.mozilla.org/show_bug.cgi?id=293973), and I'll open
another in the Java Embedding Plugin's Bugs tracker with a more
detailed explanation than I've given here.
Hi Steven,
Wow.. many thx for your indepth analysis. It works for me now using the latest stable Camion release.
Keep the byte.
Cdric
I've just released JEP 0.9.2, which fixes your problem. You should
upgrade as soon as possible, because the root cause of your problem is
a security hole, which effects all Mozilla-family nightlies, alphas
and betas (anything on the "trunk") issued since 2004-04-25. The hang
on Tiger is only a side effect ... though that's now fixed, too.
Thanks again for your report. It was while I was investigating it
that I stumbled upon the larger problem.
Thx for the update - the funny thing is - with new version of the JEP the applet works again with the nightly builds of Firefox/Camino but hang on start-up with the public released versions. It gets a bit further in the loading process as with the 0.9.1 and the nightly browsers.
I have frequent browser crashes when working with the applet since updating to Tiger - happen also in Safari - therefore I guess it has nothing to do with the JEP.
Keep the byte.
Cdric
I just tried your test site again in OS X 10.4.1 with Java 1.5.0_02,
using Firefox 1.0.4 and Camino 0.8.4 -- no hangs or crashes.
Since you also have problems with Java in Safari, maybe they have
something to do with other plugins you have installed that all
browsers can use.