Closed
Bug 398213
Opened 17 years ago
Closed 17 years ago
[FIX]Incorrect rendering of hidden applets
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.9beta1
People
(Reporter: kbrussel, Assigned: bzbarsky)
References
()
Details
(Keywords: regression)
Attachments
(1 file)
(deleted),
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
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•17 years ago
|
||
Roc, any ideas here. This seems to have regressed, view manager related or something else maybe?
Assignee: nobody → roc
Status: UNCONFIRMED → NEW
Component: General → Layout: View Rendering
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → ian
Updated•17 years ago
|
Flags: blocking1.9?
Nothing springs to mind.
This page just crashes on my 10.4 Mac.
Reporter | ||
Comment 3•17 years ago
|
||
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•17 years ago
|
||
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
Blocks: 390385
Comment 5•17 years ago
|
||
Biesi, looks like this is a regression from your fix for bug 390385. Can you have a look please?
Assignee: roc → cbiesinger
Component: Layout: View Rendering → Plug-ins
Flags: blocking1.9? → blocking1.9+
Keywords: regression
Comment 6•17 years ago
|
||
Biesi, ping?
Assignee | ||
Comment 7•17 years ago
|
||
Kenneth, is the visibility:hidden style in place already when the <applet> is created? Or is it added later?
Reporter | ||
Comment 8•17 years ago
|
||
The DIV containing the applet, "EDITOR", has hidden visibility (from iris.css) when it's initially created.
Reporter | ||
Comment 9•17 years ago
|
||
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
Assignee | ||
Comment 10•17 years ago
|
||
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.
Attachment #284425 -
Flags: superreview?(cbiesinger)
Attachment #284425 -
Flags: review?(cbiesinger)
Assignee | ||
Updated•17 years ago
|
Attachment #284425 -
Flags: superreview?(roc)
Attachment #284425 -
Flags: superreview?(cbiesinger)
Attachment #284425 -
Flags: review?(roc)
Attachment #284425 -
Flags: review?(cbiesinger)
Attachment #284425 -
Flags: superreview?(roc)
Attachment #284425 -
Flags: superreview+
Attachment #284425 -
Flags: review?(roc)
Attachment #284425 -
Flags: review+
Assignee | ||
Updated•17 years ago
|
Assignee: cbiesinger → bzbarsky
Summary: Incorrect rendering of hidden applets → [FIX]Incorrect rendering of hidden applets
Assignee | ||
Comment 11•17 years ago
|
||
Comment on attachment 284425 [details] [diff] [review]
Possible fix
This should be as safe as any plugin change gets, I think....
Attachment #284425 -
Flags: approval1.9?
Comment 12•17 years ago
|
||
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.
Target Milestone: --- → mozilla1.9 M9
Reporter | ||
Comment 13•17 years ago
|
||
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.
Assignee | ||
Comment 14•17 years ago
|
||
Checked in on the trunk.
Kenneth, tomorrow's nightlies should have the fix.
Status: NEW → RESOLVED
Closed: 17 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Reporter | ||
Comment 15•17 years ago
|
||
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•17 years ago
|
||
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.
Status: RESOLVED → VERIFIED
Updated•17 years ago
|
Attachment #284425 -
Flags: approval1.9?
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•