Iframes should be able to clip Java applets

RESOLVED DUPLICATE of bug 266652

Status

Core Graveyard
Java: OJI
--
trivial
RESOLVED DUPLICATE of bug 266652
14 years ago
7 years ago

People

(Reporter: bora123, Assigned: Alfred Peng)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(5 attachments)

(Reporter)

Description

14 years ago
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.
(Reporter)

Comment 2

14 years ago
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. 
Status: UNCONFIRMED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → INVALID
(Reporter)

Comment 4

14 years ago
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.
(Reporter)

Updated

14 years ago
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
(Reporter)

Comment 5

14 years ago
It works fine on 1.3.1. It started doing this from 1.4.0
Attachment #137201 - Attachment mime type: application/octet-stream → application/zip
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.
Assignee: general → kyle.yuan
Component: DOM → Java: OJI

Comment 7

14 years ago
confirmed on Windows 2000, jre 1.5. =>Pete
Assignee: kyle.yuan → pete.zha
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 8

14 years ago
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.

Comment 9

14 years ago
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
(Reporter)

Comment 10

14 years ago
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.
(Reporter)

Comment 11

14 years ago
Hi Pete, Is there a time frame for this to be fixed?
(Reporter)

Comment 12

14 years ago
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).
(Reporter)

Comment 13

14 years ago
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.

Severity: major → critical
(Reporter)

Comment 14

14 years ago
Fix in Bug 91516 has probable regressions.



(Reporter)

Comment 15

14 years ago
Fix in Bug 180921 has probable regressions.
(Reporter)

Updated

14 years ago
Component: Java: OJI → Layout: View Rendering
(Reporter)

Comment 16

14 years ago
Created attachment 154482 [details]
Flash plugin demonstrating the problem
(Reporter)

Comment 17

14 years ago
This problem is not only for Java applets, it is there for all plugins. 
Component: Layout: View Rendering → Plug-ins
Summary: from 1.4.0 plugins being rendered on top of everyting, even iframes with a higher Zindex cant stop them → ALL PLUGINS being rendered on top of everyting, even iframes with a higher Zindex cant stop them

Comment 18

14 years ago
CCing bz.
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).
(Reporter)

Comment 20

14 years ago
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.
(Reporter)

Comment 22

14 years ago
I see, if noone can help for this bug then it would be okey to mark it invalid.


good luck
Severity: critical → normal
(Reporter)

Comment 23

13 years ago
Created attachment 158969 [details]
Interesting test with framesets in iframes

Another test case. interesting to see this bug is getting no attention at all.
(Reporter)

Comment 24

13 years ago
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?


(Reporter)

Updated

13 years ago
Status: NEW → RESOLVED
Last Resolved: 14 years ago13 years ago
Resolution: --- → INVALID

Comment 25

13 years ago
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.
(Reporter)

Updated

13 years ago
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(Reporter)

Updated

13 years ago
Summary: ALL PLUGINS being rendered on top of everyting, even iframes with a higher Zindex cant stop them → Iframes should be able clip Java applets
(Reporter)

Updated

13 years ago
Summary: Iframes should be able clip Java applets → Iframes should be able to clip Java applets

Comment 26

13 years ago
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
(Reporter)

Updated

13 years ago
Severity: normal → major
Component: Plug-ins → Java: OJI
(Reporter)

Updated

13 years ago
Severity: major → trivial
Status: REOPENED → RESOLVED
Last Resolved: 13 years ago13 years ago
Resolution: --- → INVALID
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

*** This bug has been marked as a duplicate of 266652 ***
Status: REOPENED → RESOLVED
Last Resolved: 13 years ago12 years ago
Resolution: --- → DUPLICATE

Comment 28

12 years ago
mass reassign to Alfred
Assignee: zhayupeng → alfred.peng

Updated

7 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.