When putting Flash on a div, no matter what z-index you set, Flash always takes precedence as the top z-index, ignoring the code. We need to be able to drop DHTML layers over areas of Flash content, and cannot. Example: We have a horizontal nav layout with Flash content right below it. The horizontal nav has DHTML drop down menus. The menus appear beneath the Flash content, instead of over it as it should visually, and as it should according to z-index. This problem is very simple to duplicate on any Mozilla build. Simply put a flash movie on one div, anything on another div, and overlap them so that the second div is over the top of the Flash div. Flash shows up on top, no matter how it's coded. It simple disregards z-index code no matter what you do. One "fix": We are able to get the content of a div to appear over the top of Flash in a div (or table, or in body) by using IFRAME. Example: Put a flash movie on one div, an IFRAME that calls in a page (local or absolute) on another div, and overlap them so that the second div is over the top of the Flash div. Flash properly recedes to the back. There is something in the IFRAME tag that correctly pushes Flash content back, when the IFRAME tag appears in a div above a Flash div. Whatever logic is applied to the handling of IFRAME is missing from the good ol' layer by itself. You should be able to put anything over a Flash movie if you can put an IFRAME, theoretically. IFRAME problem: The IFRAME solution works in a very limited manner. If the content you want to show over the Flash div occupies a rectangular or square area, you are fine. In the case of the DHTML drop down, we were able to do this. But, it requires a separate page of code and another server hit everytime you roll over any of the navigation drop downs. This is really a hack! The real problem is that we need to do things like run animate GIF's with transparent areas over the top of an entire page with DHTML (something we do quite a bit for promotion...have for years...and is a staple of our rich media ad solutions). For example, the current E.T. promotion had "Elliot" flying over the content of the page to come to rest on a moon. If Elliot had to cross over any Flash content (which he fortunately did not), he would have been forced to fly behind it. Much is riding on this functionality from a Commerce perspective. We really need the ability to more closely intermingle Flash content with DHTML content, and this is a brick wall for us. Many of the promotions we'd like to do exclude the use of Flash during that promotion. At the same time, we are looking more seriously everyday at using Flash as a content delivery tool, tied into databases and all kinds of XML feeds, and would use it extensively on the new Netscape Network and most certainly for the Netblaster initiative if we could get this darn bugs out of the way. Thanks! Doug Bonneville dnbonneville@cs.com doug@bonfx.com

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

-> plugins Reporter: Which build are you using ?

My current build is: 2002032708 Netscape 6.2.1+ Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020327 Netscape6/6.2.1+

Reporter: Can you attach a simplified HTML testcase showing the differnce between IE (and/or 4.x) and the bug in Mozilla. Thanks! The testcase I attached, used with the lastest Mozilla build, shows how a DIV can be easily layered on top of a windowed plugin, such as Flash. It uses CSS fixed positioning and z-index.

Using a nightly with Build ID 2002032608 on OS/X this test case is very unstable. It seems that while the html content occationally shows at the top various interactions and animations in the movie seem to cause it to show through. Here's a sample of some of the states I'm seeing on the document (via mouseovers, setting focus elsewhere, etc. but not reloading). http://placenamehere.com/Mozilla/flash_zindex.gif I'd imagine this is a dupe of a bug already filed, or perhaps a regression because I thought the iframe z-index bug was the last thing *I* was pulling for. I could be wrong though.

confirming on OSX/2002040608

This file and the subsequent SWF file must be in the same folder to work. This shows how when 2 layers are involved, Flash usurps the z-index of any layer and puts itself on top, regardless of code. Notice that the plugin code must contain object and embed, not just embed. Whatever code solution works (if it's a code thing in the end) it has to support IE and Netscape at the same time due to publishing contraints of our template Publish Once system at AOL.

Hmmm...why couldn't I attach 2 files at the same time? How did the first swf/html post work? Anyway, here is the SWF that goes with the HTML file I posted just before this. Put this in the same folder as the HTML to see it work.

This example has the flash just sitting in the body, and the div layer set to z-index 2. Flash still takes precedence in the z-index and shows up on top.

Here is another using absolute positing that shows that it fails. Can someone explain to me why the "fixed" version posted earlier appears to work fine? What can I be missing? Could it be how gecko is interpreting the embed tag when it is by itself and not nested in the object tag (as it is normally deployed by us and everyone else on the planet....)??

There are two types of plugins: window'ed and windowless. If a plugin has a window then only another native window can be layered on top of it. (This is a limitation of the operating system) In the case of fixed positioning Mozilla creates a native window. This native window can be placed on top of the existing elements which also have native windows. Fix positioned elements do not scroll with the document so they require a native window to keep them in a static position when the user scrolls. Absolute positioned elements do not have a native window, so they can not be layered on top of a plugin which has a native window. IE 6 has exactly the same limitation. You can not layer absolutely positioned elements on top of a plugin which has a native window. In IE 6 you can not layer anything over the top of an object tag unless the object tag is referring to a windowless plugin. You can verify this by running this test case: http://bugzilla.mozilla.org/attachment.cgi?id=53555&action=view The difference in behavior between IE and Mozilla is the result of the Flash plugin running as windowless in IE and window'ed in Mozilla.

FYI: Mozilla is actually more flexible than IE in regards to rendering z-index correctly in regard to overlapping native windows. You will notice in the test case that current Mozilla builds overlap the menu's correctly for both the object and iframe cases where as IE fails on the object case: http://bugzilla.mozilla.org/attachment.cgi?id=53555&action=view Unfortunately, Mozilla can only do this when it controls the painting. When a plugin is window'ed all of the paint messages go directly to the plugin via its native window. The only thing that will show up on top of a plugin's native window is another native window. When a plugin is window'less, Mozilla controls all of the painting and can do the proper z-index rendering.

Doug, I'm not seeing the correct behavior in IE either! In the screenshot you can see that the plugin is always placed on top of the div in IE but Mozilla at least gets the fixed positioning one correct. Can you please attach a testcase (and maybe a screenshot) which shows the behavior you want working in IE? Thanks! (for testcases, it's useful to link to a swf file already on the net or in bugzilla like in my testcase so it can be viewed directly as a bugzilla attachment without the need to download locally)

handing over to peterl

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

Compare bug 111920 "Flash overlapping DHTML menus", which was marked as Invalid. Was that correct?

really giving to peterl

This is a dup of bug 93959. IE defaults to use Flash in windowless mode so naturally z-index will work. Gecko already has all the code needed to support windowless mode (like in 4.x), just now Flash needs to support it. *** This bug has been marked as a duplicate of 93959 ***

mass duplicate verifications . For filtering purposes, pls use keywd "massdupverification"

Reopening... Based on multiple reports with Flash 6.0 r79 (OS X & Windows) it looks like the the original problem still exists... when using fixed positioning (as in the first testcase) the positined html content appears above the flash movie, but in the case where the html content is over the flash movie using abosulute positioning (later testcases) the flash movie is still taking precident. I don't know at this point if this is a regression since 6r60 (what bug 93959 tests against) or if this never worked and was missed because bug 93959 covers tranparancy and a few other things besides z-index, and I don't know if its a problem in mozilla or the flash plugin... but its not working at the moment so i'm repoening. I'll follow up with WMODE using testcases in a minute.

this is an updated fixed positioning using the object tag and wmode setting - it works as expected

this is an updated absolute positioning based testcase using the object tag and wmode setting - the flash movie pokes through and should not (Flash 6.0 r79 on various recent trunk/1.4a builds)

Your testcase is missing a quote after WMODE="transparent so the browser isn't correctly picking up that attribute. Fixing the markup does indeed make the DIV show on top of the plugin. Marking WFM. Please open NEW bugs on specific real problems.

V