425278 - Java3D applets don't work properly with the JEP

Status: RESOLVED INCOMPLETE

(Plugins Graveyard :: Java (Java Embedding Plugin), defect)

Description

[Pratik]

If you load one or more J3D applets using Firefox, and have at least two tabs open, the result is badly garbled.  The simplest example is one tab with anything other than a J3D applet, and another tab with a J3D applet.  The attached screenshot is the result of the Hawaii Applet in tab 1, the 3D Milkshape Applet in tab 2, and the Advanced Imaging test in tab 3.

To Reproduce:
1) Launch Firefox (or latest Minefield nightly).
2) Open http://www.vis.uni-stuttgart.de/javatevi/Hawaii/index.html
==> The Hawaii applet opens correctly.
3) Open a new tab (<cmd>T).
4) In the new tab, open http://home.earthlink.net/~kduling/Milkshape/MS3DLoader.html
==> Both J3D images are superimposed.  Switching between tabs does not remove these, only the background part of the respective page.  The correct tab has focus; that is, from tab 1, you can more the Hawaii image around, even if the mouse pointer is over part of the 3D Milkshape.

See attached screenshot.

In order to fix this, the JEP needs to message the following NSView methods on the Java Cocoa Plugin in the expected order:
– viewDidMoveToSuperview:
– viewDidMoveToWindow:
– viewWillMoveToSuperview:
– viewWillMoveToWindow:

This happens in latets nightly Minefield as well as Firefox 2.0. My UA string is

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5pre) Gecko/2008032604 Minefield/3.0b5pre

Comment 1

[Pratik]

Attachment: Screenshot of Firefox

Comment 2

[Steven Michaud [:smichaud] (Retired)]

The problem is more general than this:

Judging from these two examples, Java3D applets simply don't work
properly with the Java Embedding Plugin on either OS X 10.5.2 or OS X
10.4.11.  None of the JEP's clipping code works -- so not only will a
single Java3D applet show up in all tabs, but it will also draw
outside of the plugin view and even outside of the window's content
area (e.g. on top of browser chrome and the title bar).

I don't know how long this has been the case.  Nobody's ever reported
it before.

It will be a while before I can fix this -- it will certainly not be
done before the Firefox 3 release.  So I suppose this will have to be
mentioned in a release note.

To be fair, the release note will also have to mention that Java3D
applets don't work on Windows or Linux, either (at least not with the
Sun Java Plug-In as it comes "out of the box").  On those platforms
you simply get "class not found" error messages.

> In order to fix this, the JEP needs to message the following NSView
> methods on the Java Cocoa Plugin in the expected order:
> – viewDidMoveToSuperview:
> – viewDidMoveToWindow:
> – viewWillMoveToSuperview:
> – viewWillMoveToWindow:

This almost certainly has nothing to do with the problem.

Why do you think it does?

Comment 3

[Steven Michaud [:smichaud] (Retired)]

Using gdb to find out what additional dylibs get loaded after a Java3D
applet is run, I see the following (on my new MacPro running OS X
10.5.2):

/System/Library/Java/Extensions/libJ3D.jnilib
/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/
  Libraries/libjawt.dylib
/System/Library/Frameworks/OpenGL.framework/Versions/A/
  Resources/GLEngine.bundle/GLEngine
/System/Library/Extensions/ATIRadeonX2000GLDriver.bundle/
  Contents/MacOS/ATIRadeonX2000GLDriver
/System/Library/Frameworks/OpenGL.framework/Versions/A/
  Resources/GLRendererFloat.bundle/GLRendererFloat

Of these, the crucial ones are probably libJ3D.jnilib and
GLEngine.bundle.  I'll probably have to hack both of them to get
around these problems.  (In addition to	j3daudio.jar, j3dcore.jar,
j3dutils.jar and vecmath.jar in /System/Library/Java/Extensions.)

Comment 6

[d]

Now, I can see that this bug hasn't been touched since 2008, but I wonder, is this something _you_ can (or have to) solve, or is it something only Apple can change/fix?

Comment 7

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #6)

Apple may be able to help -- note that bug 507823 comment #6 also
reports problems with the Java3D libraries in Safari.  But this
probably won't be enough by itself -- the JEP's clipping code will
probably also need to be revised to work with the Java3D libraries.

I can't give you a timeframe for this.  I don't have as much time to
work on the JEP as I used to.  And (under the circumstances) I don't
think it makes sense for me to start working on this until Apple has
done more work of its own.

Comment 8

[d]

OK, I understand. This might sound like a stupid request, but do you think you could make it behave like Safari for now? Some flicker at scrolling and resizing is better than not being able to browse at all.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

> do you think you could make it behave like Safari for now?

This would likely take just as long as fixing the problem correctly.
So no, it doesn't make sense to attempt this.

Comment 11

[Steven Michaud [:smichaud] (Retired)]

The JEP is long gone.