266652 - Plugins are not clipped and rendered over iframes.

Status: RESOLVED INVALID

(Core Graveyard :: Plug-ins, defect)

Description

[bora123]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Build Identifier: All versions

Plugins are not clipped by the absolutely positioned iframes with higher z-
index. They stay on top of iframes. On Solaris, they always stays at the bottom 
meaning if the iframe that plugin is in has a higher zindex than another iframe 
below with lower ZIndex. Plugin stays at the bottom completely hidden.

Reproducible: Always
Steps to Reproduce:
1.Use the test cases
2.
3.



Expected Results:  
Plugins must respect the iframe geometries and style properties.

This has ruined our entire mozilla based product since the mozilla 1.3.1. the 
money we lost is irrecoverable. If the firefox is going to go gold with this 
bug in the it will be very damaging for compaines having this problem in front 
of them. We were thinking about not supporting mozilla at all but it doesnt 
solve the problem we had and having. I am sure the fix must be very 
straightforward for someone who knows the Mozilla source base well.

regards,

Comment 1

[bora123]

Attachment: test case 1

Comment 2

[bora123]

Attachment: Test case 2

Comment 3

[bora123]

Attachment: Test case 3

Comment 4

[Frank Wein [:mcsmurf]]

Related: Bug 133968 (probably it's even the same?, but let's stick here, since
there's too much trash in the other bug)

Comment 5

[Frank Wein [:mcsmurf]]

-->invalid
set wmode="transparent" for the flash example and it will work.

Comment 6

[Boris Zbarsky [:bzbarsky]]

To clarify, plugins typically paint themselves directly to the graphics context,
bypassing the browser's drawing routines altogether, so they'll end up on top of
everything else.  Some plugins (flash, notably) support "windowless" operation
that allows them to participate in the browser's compositing pipeline (so allows
things to overlap them, for example; in this mode, the plugin and browser
cooperate to ensure that the plugin is correctly composited with the other
content the browser is rendering.).  To enable windowless operation for Flash,
the "wmode" attribute of the embed or "wmode" param of the object needs to be
set to "transparent".

Comment 7

[bora123]

How this is invalid when the Test case 1 and 3 is not demonstrating good will 
with wmode="transparent"?

Boris, Iframes should nor work as DIVs. They should clip anything including 
plugins because for example their contents can be two different web sites. When 
you overlap these two iframes with different sites, regardless what the wmode 
of the plugins they include they should not dissolve in each other.

Comment 8

[bora123]

CC'ing Peter, I really would like to know what he thinks on this.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> How this is invalid when the Test case 1 and 3 is not demonstrating good will 
> with wmode="transparent"?

Because wmode="transparent" is a Flash command (as in, it's just passed on to
the Flash plugin, and the plugin decides what to do with it) and those are Java
applets.  The Java plugin can go windowless too, as I recall; check the Java
plugin documentation on how that's done.

> Boris, Iframes should nor work as DIVs. They should clip anything including 
> plugins

Actually, that's wrong.  Iframes can be translucent, in particular, with the
content they're on top of shining through them.  At some point Robert did some
work to make it possible to do that; that's probably what "broke" your testcases.

Again, this is invalid.  There is just no way to make plugins that are not
windowless be part of the standard browser rendering pipeline.

Comment 10

[bora123]

If something is broken (clearly it is) why this is marked "invalid" instead of 
directing it to the right person? I think it should remain open until it is 
totally cleared out. Plus my intend on reporting this bug was not about 
problems with windowless plugins or problems with translucent iframes. All I 
have two iframes (not translucent) and my java applet (does not have windowless 
mode) does not play right on my testcase 1 and testcase 3. The test case 2 
having the flash example I think it is confusing it all. Test case 3 
demonstrates the problem in a more elaborative point of view with framesets in 
iframes working right but iframes themselves do not.

I would like to reopen it until Robert takes a look at it.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> If something is broken (clearly it is)

No, the point is nothing is broken.  Things are working exactly as specified.

> and my java applet (does not have windowless mode)

That's a bug in your java applet, then.

The framesets issue sounds like a bug in Mozilla's frameset implementation...

Since you insist on having this open, feel free to, but I doubt that will change
anything materially.

Comment 12

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

I haven't looked at the testcases --- it'd be helpful if you make a testcase
available either on your own Website or preferably as a set of Bugzilla
attachments so I can just click on it.

It sounds like the problem is that you have an IFRAME and a Java applet and the
IFRAME has higher z-index but the Java applet is drawn on top. Correct?

Boris is correct that we do not attempt to make plugins work well with z-index.
It's just not possible in general.

This workaround might work: wrap the IFRAME and the Java applet in DIVs, and set
the z-index on the DIVs, and make the DIVs overflow:auto.

Comment 13

[bora123]

Hi Robert, I will make the testcases as bugzilla attachments first thing 
tomorrow. I will try the workaround you have suggested. The problem started 
right after Mozilla 1.3.1. It was working just fine before. Testcase 3 
demonstrates the problem well. The frameset in Iframe can clip the java applet 
just fine. But the iframe itself cant. I will put out the bugzilla attachments 
rightaway.

best regards,

Comment 14

[bora123]

I am trying to figure out how to make a bugzilla attacment, In the mean time, 
let me clearify the problem I am having.

>It sounds like the problem is that you have an IFRAME and a Java applet and the
>IFRAME has higher z-index but the Java applet is drawn on top. Correct?

Applet is in the content of IFRAME. 

From test case 1:

this is the code for test.htm

<html>
<body>
<iframe width="300" height="300" style="position:absolute;z-
index:10;top:20;left:20" src='m1.htm'></iframe>
<iframe width="300" height="300" style="position:absolute;z-
index:20;top:60;left:60" src='m.htm'></iframe>
</body>
</html>

-------------------------------------->8
code for m.htm

<html>
<body bgcolor="#0000FF">
</body>
</html>


-------------------------------------->8
code for m1.htm

<html>
<body>
<applet code="Clock" width=70 height=70></applet>
</body>
</html>

Applet is a very simple clock. The applet in the iframe with "src" set to 
m1.htm always pops up in front of the iframe with "src" set to m.htm. It should 
remain clipped under the iframe with higher zindex. This was working fine last 
in Mozilla 1.3.1. 

Comment 15

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

Making those IFRAMEs position:fixed might make the problem go away too.

Comment 16

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

Boris, we could probably do some work to try to get the widget z-order to match
the CSS z-order better. E.g., order the widgets based on where their views
appear in the display list. It wouldn't be perfect of course, in particular
plugins would still render on top of content whose nearest widget was the root
widget, but it would help these testcases.

Comment 17

[bora123]

Robert, I have tried position:fixed. It had no effect. In the mean time, I was 
unable to find a way to create bugzilla attachments :\. It works for a split 
second when mouse clicked onto one of the iframes(test case 1). 

I think Boris removed himself from the CC list.

Comment 18

[bora123]

I have put the testcases to the following URL

http://www.geocities.com/bora123/

Comment 19

[bora123]

Although this fix was done for MacOs, It might have broken something. 

http://bonsai.mozilla.org/cvsview2.cgi?
diff_mode=context&whitespace_mode=show&file=nsObjectFrame.cpp&branch=&root=/cvsr
oot&subdir=mozilla/layout/html/base/src&command=DIFF_FRAMESET&rev1=1.379&rev2=1.
380

fix was made for bug#191821

Comment 20

[bora123]

Robert,

In nsObjectFrame.cpp
from revision from 1.379 to 1.380 in the function
nsPluginPort* nsPluginInstanceOwner::FixUpPluginWindow()

there are suspicous changes regarding the clipping view ObjectFrame.


http://bonsai.mozilla.org/cvsview2.cgi?command=DIFF&subdir=mozilla%2Flayout%
2Fhtml%2Fbase%
2Fsrc&file=nsObjectFrame.cpp&rev1=1.379&rev2=1.380&whitespace_mode=show&diff_mod
e=full

Comment 21

[:Gavin Sharp [email: [e-mail]]]

*** Bug 303636 has been marked as a duplicate of this bug. ***

Comment 22

[:Gavin Sharp [email: [e-mail]]]

*** Bug 227470 has been marked as a duplicate of this bug. ***