1.64 KB, application/zip
2.44 KB, application/x-zip-compressed
1.97 KB, application/x-zip-compressed
1.64 KB, application/x-zip-compressed
1.49 KB, application/x-zip-compressed
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) Build Identifier: From 1.4.0, plugins have been rendered on top of everything; even iframes with a higher Zindex cant stop them. Plugins rule the layout; they dont care what they have on top of them. They started to have this habit of rendering on of everything. They were such good boys up until 1.3.1. There must be some kinda change from 1.4.0 in molecular level. They are virtually unstoppable. You should do something about this. Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: They do not care about zindex of iframes, they draw themselves on top of everything. Expected Results: They should stay calm and obey the higher iframes' clipping.
What plugin? Most plugins paint themselves directly to the OS video layer -- they are not painted by Mozilla. That behavior was identical in 1.3 and 1.4. This bug needs an actual page showing the problem.
Wow, I am impressed, an "immediate action" has been taken. I am not really into providing any testcase but here are the problems I had with Mozilla versions after 1.3.1. An applet for example with a ticking thread to repaint itself, lets say a clock, always paints itself on top of everything. I believe there are some reflow regressions concerning plugins. If I put an Iframe over this clock applet, the clock applet pops over the Iframe. There are also repaint problems on still applets. If I put an iframe over a still applet and move it away, applet is not rerendered(nice). It could well be a java plugin related problem, but it sounds more like a layout related tick. I dont use html to render so I always post my experiences to DOM. Anyhow, you may either mark this invalid or investigate, I couldnt care less.
> I am not really into providing any testcase Very well. Since I can't reproduce the problem (windowless plugins work correctly, can't reproduce the problem you are describing), marking invalid. Please feel free to reopen once you have a page showing the problem.
Created attachment 137201 [details] test case showing the problem Here is the test case for this bug. The Applet should remain under the Iframe above.
It works fine on 1.3.1. It started doing this from 1.4.0
14 years ago
I see the blue iframe rendering on top of the applet in Linux trunk build 2003-11-19-08. So this is either fixed or Windows-only. In the latter case, it's a Java-specific bug, since last I checked (a few days ago) positioning stuff on top of flash worked just fine.
confirmed on Windows 2000, jre 1.5. =>Pete
Kyle, the version numbers I mentioned (1.4.0 and 1.3.1) are mozilla versions. This problem persists on all java plugin releases as well as Java plugin 1.3.1. I just wanted to let you know although you may have already figured. I am assuming this is not related to OJI. As Boris said, it could well be a windows only rendering bug.
This bug is greatly undermining our efforts to produce well behaving showcases for our new technology. It would be great if this bug gets priority. regards
On Solaris 8 (Sparc) the problem persists as vice versa. The plugins can not pass thru the iframes underneat the iframe that plugin runs in. change the test.htm as following. I am certain this problem is also there for linux boxes. <html> <head> <title>test</title> </head> <body> <iframe width="300" height="300" src="m.htm" style="position:absolute;z-index:40;top:0;left:0"></iframe> <iframe width="300" height="300" src="m1.htm" style="position:absolute;z-index:20;top:50;left:50"></iframe> </body> </html> java clock in m.htm is partially hidden by the iframe that has lower zindex.
Hi Pete, Is there a time frame for this to be fixed?
A diff with Mozilla version 1.4.0 and Mozilla version 1.3.1 will reveal the broken code. It sounds like a widget ZORDER problem. Plugins do honor ZORDER but when they get an expose event they draw themselves on top of everything (see the testcase). The problem more severe on GTK based unix versions. Plugins never draw themselves if there is ZORDER'in involved (they dont get Expose event).
I do not know if anybody is ever reading this bug, but here is what I think happened. I think the Iframes were made lightweight components effective Mozilla 1.4.0. Iframes were used to be heavyweight window components. They are now DIV like lightweight layers. Sun's java plugin doesnt know how to handle lightweight Iframes. I am just guessing because I just got a weird problem on Internet explorer IE5.5 and IE6.0; a somewhat similar problem. IE5.5 and IE6.0 have also lightweight Iframes. But Sun's java plugin is painting itself on top of everything once clicked on it or an iframe is moved around. So I believe that you guys need to teach your plugin how to deal with the lightweight Iframes. This is critical because it breaks all the fundemantals of Applet behaviour as we know it since the dawn of IE4.0, and needs to be addressed immediately.
Fix in Bug 91516 has probable regressions.
Fix in Bug 180921 has probable regressions.
This problem is not only for Java applets, it is there for all plugins.
Two things: 1) In a current Linux build that flash plugin in the URL field renders below the blue iframe. 2) It's not using the wmode parameter, so I would not be surprised if compositing fails sometimes. If you want flash to participate in Z-ordering in a sane way, it needs to be a windowless plugin, which means you should use wmode="transparent". In fact, I am betting this whole bug is simply about plugins not running in windowless mode (which makes them paint directly to the graphics device, not through Mozilla).
I tried to use wmode with Flash plugin. It didnt have an effect. I have checked the plugin source in 1.3.1 and 1.4.0. Looks like there is new implementation in 1.4.0+ Mozilla for the whole plugin thing. It was not a problem at all on Mozilla 1.3.1. It started doing this from 1.4.0. It sounds to me mozilla(now) expects all the plugins to obey new rules or else ;). Can there be a backward compatibility at least until all the plugin verdors adjust for the new rule? regards, Bora
No, plugins are not expected to obey new rules. It's just that now they _can_ be windowless if they want. Before, they could not. In any case, as I said I can't reproduce the problem, so I'll be of no help here.
I see, if noone can help for this bug then it would be okey to mark it invalid. good luck
Created attachment 158969 [details] Interesting test with framesets in iframes Another test case. interesting to see this bug is getting no attention at all.
May be it would be more appropriate to cc this to the owner of the plugin module. does anybody know who is the owner of the plugin module?
Created attachment 166235 [details] revised version of first test case This bug is not invalid. It is important that this bug is fixed. I have revised the first test case to show you what is really wrong.
Created attachment 166662 [details] Applet Rendering Sync problem with layout After investigating this further, we have seen that there is a rendering with applets. The new attachment demonstrates the problem. We used a similar clock applet, but this time there is no "thread" to update the clock. When test.htm first viewed, the applet renders itself on top of blue iframe again. But when you force mozilla to reflow the page(like lowering and raising the mozilla window), it paints correctly under the blue iframe, and remains like that. Therefore, the problem is with the java applet and mozilla layout engine together. If applet has to repaint itself for example with threaded clock, then the applet will always stay on top of the blue iframe. On the other hand, "setIgnoreRepaint(true)" method breaks the entire applet and applet paints nothing. We believe that this is a severe problem, and Sun engineers who are serious about supporting mozilla with a fully functional Java plugin should make this bug a priority. best regards, NeuroDNA Software Engineering team
*** This bug has been marked as a duplicate of 266652 ***
mass reassign to Alfred