351940 - Jeep 360° view Java applet crashes Camino

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Plug-ins, defect)

Description

[jhasson]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.4) Gecko/20060613 Camino/1.0.2
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.4) Gecko/20060613 Camino/1.0.2

using the portion of the website that allows you to view vehicles/change colors, etc causes irretrievable hang.  some hotspots dont activate pointers.

Reproducible: Always

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

With Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060908 BonEcho/2.0b2 it only uses 100% of cpu during the page loads.

I believe you mean following URL?

http://www.jeep.com/en/wranglers/360/wrangler/exterior/index.html?tname=wrangler360

This page contains a java applet. Which version of java do you have installed? If you don't have the latest version 1_5_0_08 try to update and test again.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Please look at bug 256763 because your one could be a dupe of that bug.

Comment 3

[Samuel Sidler (old account; do not CC)]

Henrik, this is a Camino bug, please triage using Camino unless it's apparent that this bug is cross-platform.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #3)
> Henrik, this is a Camino bug, please triage using Camino unless it's apparent
> that this bug is cross-platform.

That's why I ask and give hints. Without testing we aren't able find out if it's cross-platform related.

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Java bugs on Mac OS X are almost never cross-platform, given the platform-specific nature of Apple's Java libraries and the way Mozilla talks to Java (JEP).

Reporter, please be specific about which page on the site is causing problems.  Most of the site if Flash-based ("hotspots") and seems to work fine, but the URL mentioned in comment 1 does have an applet and does crash a recent Cm 18branch on 10.3.9.  (In Safari, the applet basically doesn't load; I can occasionally get something to display by clicking the "right" combination of buttons, but otherwise it's just a blank white box, and it spews tons of errors in the console.)

That tends to make me think the applet is broken, but we shouldn't crash ;)

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: crash log (likely not this bug)

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Actually, I was a little hasty to confirm.

I don't crash in Cm 102 or 103rc2, nor in Firefox 1506.  I don't crash in this morning's official branch nightly (so the crash might have been related to it being a debug build).  The applet works fine in all those cases; it's just dog-slow.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

I've now played around quite extensively with the "2-door" and
"4-door" applets, in Firefox 1.5.0.6 and Camino 1.0.2, with JEP
0.9.5+g, on OS X 10.3.9 and 10.4.7.

I didn't see any crashes at all.  I did see a fair amount of wierdness
-- but all of it was to some extent reproduceable in other browsers
(e.g. Safari) and on other platforms (e.g. in Firefox 1.5.0.6 on
Windows and Linux).

Basically, the applet is a real beast, and I suspect the authors only
ever tested it in IE (and then probably only on Windows).  (You see
the following error in the JavaScript console in Firefox 1.5.0.6 on OS
X -- "error: isIE is not defined".)  This bug should probably be
marked INVALID (or maybe "tech evangelism").

Safari loads but never displays the "2-door" applet on both OS X
10.3.9 and 10.4.7.  It does display the "4-door" applet, but at the
same (very slow) speed that both the "2-door" and "4-door" applets get
displayed in Firefox and Camino on OS X.  Display (i.e. view-changing)
speeds were much faster on Windows and Linux -- this must be because
(as is well known) some display operations are much slower in Apple's
versions of Sun's JVMs than they are in Sun's JVMs on other platforms.

I could sometimes reproduce the _appearance_ of being hung with the
"2-door" applet on OS X (in Camino or Firefox) -- particularly by
quickly going back and forth between the "View" and "Hard Top" sets of
buttons.  But the display was never _really_ hung -- at worst I had to
click on one of the "Exterior Colors" buttons to make a "View" change
take effect (e.g. when I clicked on "red", I'd see the color and the
view change at the same time).  These "hangs" are almost certainly a
problem with the "2-door" applet itself -- they probably explain why
Safari couldn't display this applet at all.  I didn't see any of these
"hangs" with the "4-door" applet.

Interestingly, the only _real_ hang I saw was with the "2-door" applet
on Linux (in Firefox 1.5.0.6 with Sun's Java 1.4.2) -- everything in
the browser's (only) window stopped being refreshed except the
"2-door" applet (a situation I could only rectify by closing the
browser).

Comment 9

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #6)

I suspect this crash is unrelated to this bug.

I've just been digging around in bmo, and found that there's a small
class of crash logs which, like this one, have (on the main thread)
the two lines LookupClass and IsInstanceOf at the top of the stack and
JEPCreateJavaApplet somewhere below it (in the same stack):

bug 330005 comment 1 (attachment 214651 [details])
bug 332706 comment 9 (attachment 217253 [details])
bug 338850 comment 2 (attachment 222898 [details])

I don't believe I've ever seen one of these myself, and I don't know
what to make of them.  But it's worth keeping an eye on them.  At some
point, in the very distant future, it may be possible to figure them
out :-)

Comment 10

[Chris Lawson (gone)]

jhasson, is this still a problem with Camino 1.5 and/or a new Java Embedding Plugin?

Comment 11

[Stuart Morgan]

Closing INCO. If anyone can reproduce this with a recent build of Camino, feel free to reopen.