379058 - Java applet contained in IFrame with height set to 0px is sometimes visible

Status: RESOLVED FIXED

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

Description

[Matt Vella]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Please see http://rulez.com/focus_test/.  Demo at http://rulez.com/focus_test/test.html.

Problem: 

You have an HTML page containing two IFrames.  One contains only HMTL content (IFrame A), the other contains HTML that loads a Java applet (IFrame B).  Initially, the height of IFrame A is set to 100%, the height of IFrame B is set to 0px (as styled by CSS).  As expected, IFrame A is visiable while IFrame B is not.

Next, you click on a link that causes some javascript code to swap the CSS styles on IFrame A and IFrame B, so that the height of IFrame A is now 0px, and the height of IFrame B is now 100%.  As expected, IFrame B is now visible, IFrame A is not.

Finally, you click on a link that again swaps the CSS styles.  As they were initially, IFrame A's height is now set to 100%, IFrame B's height is now set to 0px.  This sometimes works as expected (IFrame A is visiable while IFrame B is not).  However, many times the Java applet from IFrame B stays visible, covering the content of IFrame A that should now be visible. Clicking the page seems to clear the remnants of the Java applet from IFrame B so that you then see the content of IFrame A.

Notes:
- This problem seems to only effect the Firefox brower on Mac OS.

Reproducible: Sometimes

Steps to Reproduce:
Navigating in a Firefox browser to http://rulez.com/focus_test/test.html will allow you to easily replicate this issue as described above.  

1. After the page loads you will see the contents of IFrame A. Click on the tab labeled 'Applet'.  The contents of IFrame B will now be visible.  
2. Click on the tab labeled 'HTML Content'.  The content of IFrame A should now again be visible, but it will not be if the problem has occurred.
3. If the problem has not occurred, repeat steps 1 and 2.

Comment 1

[Steven Michaud [:smichaud] (Retired)]

Thanks for your report and test case.

I've confirmed this in Firefox 2.0.0.3 and Camino 1.0.4 on OS X 10.4.9
and 10.3.9.  I've also confirmed that it doesn't happen in Safari on
either of these OSes, or in Firefox 2.0.0.3 on Linux (with Java 1.4.2)
or Windows XP (with Java 5.0).

Since the tab switch (when it works properly) takes place when the
mouse button is released, I suspect this is an issue with the handling
of mouse-up events.

I'll be working on this.  But since I currently have less time to work
on the Java Embedding Plugin, it may be a while before I can fix it.

Comment 2

[Steven Michaud [:smichaud] (Retired)]

I had some time today to work on this, and have come up with a
solution.  I'll include the fix in the next version of the Java
Embedding Plugin, when I release it in the next month or two.

The problem has nothing to do with the processing of mouse events.
Rather, it results from a subtle (and very seldom-encountered) bug in
my workaround for bug 277067 (in AppletView.m's setClip:).

Comment 3

[Matt Vella]

Thanks for looking into this so quickly, I appreciate the time you spent fixing it.

I'll look forward to the fix in the next version of the Java Embedding Plugin.

Comment 4

[Steven Michaud [:smichaud] (Retired)]

I've just released a new version (0.9.6.3) of the Java Embedding Plugin
that fixes this problem.  Please try it out.

For more information see bug 386918.

Comment 5

[Matt Vella]

Thanks so much for working on this.  It does appear that the original test case now works as expected.

However, there still seems to be a problem when the Iframe containing the applet exists inside of another tabbed Iframe (i.e. the applet is a level deeper).  Sorry to point this out, but I realized it was a problem because we do have web content structured this way.

I have put together another test case so you can see this.

http://rulez.com/focus_test2/

To view the actual test:
http://rulez.com/focus_test2/test.html

From the README.txt:

You have an HTML page containing two IFrames.  One contains only HMTL content (IFrame A), the other (Iframe B) contains HTML that calls 2 more iframes - one that loads a Java applet (IFrame C) and the other containing only HTML (Iframe D).  Initially, the height of IFrame A is set to 100%, the height of IFrame B is set to 0px (as styled by CSS).  As expected, IFrame A is visiable while IFrame B is not.

Next, you click on a link that causes some javascript code to swap the CSS styles on IFrame A and IFrame B, so that the height of IFrame A is now 0px, and the height of IFrame B is now 100%.  As expected, IFrame B is now visible, IFrame A is not.  IFrame B sets the height of IFrame C (containing a Java applet) to 100%, while setting the height of Iframe D to 0px.  As expected, Iframe C is visible, while Iframe D is not.

Finally, you click on a link that swaps the CSS styles of iframe C and D.  IFrame D's height is now set to 100%, IFrame C's height is now set to 0px.  You expect to see Iframe D and expect Iframe C to be non-visible.  However, this does not occur.  If you click to show Iframe A, then click back to Iframe B, Iframe D will show very briefly until Iframe C become visible and hides Iframe D.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

Your new problem isn't a bug in the Java Embedding Plugin -- it's caused by
one or more Mac-specific bugs in current versions of all Mozilla.org browsers.

The "test2 bug" happens in Firefox 2.0.0.4, Camino 1.5 and SeaMonkey 1.1.2,
but not in current "Minefield" and Camino trunk nightlies ("Minefield" is name
used for Firefox trunk nightlies; I didn't test a SeaMonkey trunk nightly).
All my tests were done with JEP 0.9.6.3.

You can do the following to see what's going on:

Add '-Djep.debug.visibility=true' (without the quotes) to the Java Control
Panel's (aka Java Preferences) "Java Applet Runtime Parameters" and set "Show
console" (to cause the Java Console to be displayed).  The following kinds of
messages will appear in the Java Console every time a change is made to the
test2 applet's "visibility":

JEPController:showHideApplet making DummyApplet visible
JEPController:showHideApplet making DummyApplet invisible
AppletView:setClip clipping DummyApplet to
  X (0.000000) Y (0.000000) Width (0.000000) Height (0.000000)
AppletView:setClip clipping DummyApplet to
  X (10.000000) Y (144.000000) Width (300.000000) Height (300.000000)

You'll notice that in current Mozilla.org browsers (e.g. Firefox 2.0.0.4),
these messages appear when you switch between IFrame A and IFrame B, but not
when you switch between IFrame C and IFrame D.  However in current Minefield
and Camino nightlies, these messages appear in both cases.

I say "Mac-specific" because I wasn't able to reproduce this problem in
Firefox 2.0.0.4 on either Linux or Windows.

I'm not sure if it will be possible to backport the correct behavior from
current nightlies to (for example) Firefox 2.0.0.4.  When I have more time
I'll try to find out when the change occured that made the nightlies start
behaving correctly.  (Of course this is also something you could do.)

Comment 7

[Steven Michaud [:smichaud] (Retired)]

> I'm not sure if it will be possible to backport the correct behavior
> from current nightlies to (for example) Firefox 2.0.0.4

I should have said "Firefox 2.0.0.5", or "future releases on the 1.8
branch".

Comment 8

[Steven Michaud [:smichaud] (Retired)]

> When I have more time I'll try to find out when the change occured
> that made the nightlies start behaving correctly.

I had time sooner than I thought.

The change took place between the 2006-09-28-08-trunk Minefield
nightly (which still had the bug) and the 2006-09-29-06-trunk nightly
(which didn't).  The only plausible source code change that cooincides
with this is bug 326469 ("use Cocoa widgets by default on Mac OS X").

This was a very large change.  It will be very difficult to know which
part of it did the trick.

Comment 9

[Matt Vella]

Again, thanks for the investigation.  We will continue to track this and will be more than willing to help with any testing if this fix does get backported into the 1.8 branch.