398213 - [FIX]Incorrect rendering of hidden applets

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Kenneth Russell]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007100104 Minefield/3.0a9pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007100104 Minefield/3.0a9pre

The IRIS application linked above uses two Java applets in the web page. One of them implements the image editor / slideshow functionality. It is initially hidden by a DIV tag with the appropriate style.

In Firefox 2.0, this application renders correctly. In the Firefox 3.0 alpha builds, the initially hidden applet is not hidden, and overlays part of the web page. After opening and closing the editor panel, the applet is properly hidden.


Reproducible: Always

Steps to Reproduce:
1. Download and install the latest JRE 6 update for Windows from http://java.sun.com/javase/downloads/index.jsp (currently JRE 6 update 2)
2. Open the Java Control Panel, "Java" tab, and click "View..." for "Java applet runtime settings"
3. Add -Dsun.java2d.noddraw=true to the Java Runtime Parameters
4. Close the Java Control Panel
5. Browse to the Iris page. Note that with FF 2 the page is initially rendered correctly but with FF 3 the hidden applet is showing up near the upper left corner of the page.
6. Go to the search field and enter for example "kenneth russell" (or any other Flickr user name). A couple of Flickr albums will show up. Select an album; the photos in the album will show up. Double-click one of those photos. Note that the Editor applet now pops up correctly.
7. Close the Editor applet with the close box in the upper-right corner. Note that the previously-rendered hidden applet is now no longer being rendered, which is the desired result.

Actual Results:  
Applet which should be invisible is being rendered.

Expected Results:  
Invisible applet should not be rendered.

Note that this bug occurs both with the "old" OJI-based Java Plug-In as well as the "new" NPRuntime-based Java Plug-In, so this issue is independent of the OJI and is fairly clearly on the browser side.

Comment 1

[Johnny Stenback (:jst)]

Roc, any ideas here. This seems to have regressed, view manager related or something else maybe?

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Nothing springs to mind.

This page just crashes on my 10.4 Mac.

Comment 3

[Kenneth Russell]

This page requires Java 6 which isn't generally available on the Mac yet, although if you're a member of the Apple Developer Connection and install their Developer Preview it will work (in Safari -- we never tested it with Firefox on the Mac).

For the purposes of regression testing, please try it on Windows. I believe there may be bugs in the Java Plug-In preventing it from working / sizing the applets properly on X11 platforms, which we want to look into in conjunction with FF 3 and the "new" NPRuntime-based Java Plug-In.

Comment 4

[Ria Klaassen (not reading all bugmail)]

Tested on the presence of this: http://img231.imageshack.us/img231/2873/javanw3.png the regression range is http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1186442460&maxdate=1186447439

Comment 5

[Johnny Stenback (:jst)]

Biesi, looks like this is a regression from your fix for bug 390385. Can you have a look please?

Comment 6

[Johnny Stenback (:jst)]

Biesi, ping?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Kenneth, is the visibility:hidden style in place already when the <applet> is created?  Or is it added later?

Comment 8

[Kenneth Russell]

The DIV containing the applet, "EDITOR", has hidden visibility (from iris.css) when it's initially created.

Comment 9

[Kenneth Russell]

Another note. It now seems that when the DIV is made visible (the Editor window is popped up the first time), the Editor is rendered incorrectly the first time; the web page's stale content is visible instead of the Editor. Closing and re-opening the Editor causes it to show up correctly. The browser seems to be sending the correct window sizing indications to the Java Plug-In, but somehow manages to overlay the heavyweight window of the applet with the old content.

There are bugs in the current versions of the Java Plug-In that may affect correct execution of this web app (SecurityExceptions may be thrown in the Java Console); contact me if you need a version of the plug-in which contains fixes for these bugs in order to make progress. See also 399406 which prevents execution of this test case with the current OJI-based plugin. The same error occurs with the new NPRuntime-based Java Plug-In.

Screen shot after opening the Editor the first time (incorrect rendering):
http://download.java.net/media/jogl/builds/tmp/bug1.jpg

Screen shot after opening the Editor the second time (correct rendering):
http://download.java.net/media/jogl/builds/tmp/bug2.jpg

Comment 10

[Boris Zbarsky [:bzbarsky]]

Attachment: Possible fix

I can't test this, unfortunately.  I keep meaning to get a development setup on Windows going, but it hasn't happened yet.  :(

The two changes are:

1)  Don't unconditionally set the view visible when creating the widget, since
    we seem to do that from instantiation, and we now instantiate after reflow.
2)  Handle dynamic CSS visibility changes by twiddling the view visibility as
    needed if our style changes.  It looks like that part was broken all along,
    as far as I can tell.

jst, if you can reproduce this bug, can you give the patch a spin?  Otherwise I think we should check this in (since I'm pretty sure these changes are correct no matter what) and then we'll have a nightly with these changes to test against.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 284425 [details] [diff] [review]
Possible fix

This should be as safe as any plugin change gets, I think....

Comment 12

[Johnny Stenback (:jst)]

The patch does indeed seem to fix this problem. With this patch I don't see the applet that's drawing on top of the UI in this app w/o this patch.

We should IMO take this for beta, the more testing we can get for this the better off we are.

Comment 13

[Kenneth Russell]

I had hoped to try building FF 3 from source to test this patch, but am swamped. Please update the bug report when it lands and indicate when we can expect to see it in a nightly build, and we can help verify the fix here as well.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Checked in on the trunk.

Kenneth, tomorrow's nightlies should have the fix.

Comment 15

[Kenneth Russell]

Verified fix with nightly build dated 2007-10-19 with both the old OJI-based and new NPRuntime-based Java Plug-Ins. Thanks for the timely fix.

Comment 16

[Marcia Knous [:marcia]]

verified fixed using  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007102504 Minefield/3.0a9pre and Java Runtime Environment (JRE) 6 Update 3. Disappointing that this does not work on Mac trunk as I think it cool.