An IFRAME with a lower z-index obscures what is supposed to be a DIV with a higher z-index. The IFRAME, once loaded from the specified SRC, always appears in front of absolutely positioned DIV's. Three examples are included at the supplied URL: 1) An IFRAME in the base document normal flow covers an absolutely positioned DIV with a higher z-index. 2) An IFRAME embedded in a DIV obscures DIV's in the base document with a higher z-index than the DIV inwhich the IFRAME is embedded. 3) An IFRAME, with no SRC attribute specified, is obscured behind a DIV with a higher z-index. The same result is obtained when the SRC is an invalid source, ie, the DIV is in front of the IFRAME.

confirmed with win32 mozilla build 071008

This does not seem like a severe bug that will prevent major functionality of the browser, marking Future.

Robert, you may wish to see this bug.

I see it. My nsViewManager2 does not fix this bug. I'll take a look at it if I have time.

Has anyone looked at this bug recently? It is severely impacting our product development. Can someone have a look and see if it would be a major change to get this working? Can the severity/target be increased?

It would be a major change to get this working. We would really have to move to one view manager for the entire window and all its documents.

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

I reeeeellllllyyyyy beleave this one is a major bug. The suport and use of iframes should be as easy as to suport ILayers. We, developers, need a alternative or solution, since DIV and IFRAME Z-index property are basic peaces to any DHTML project.

I would like to see the Mozilla0.9 or 1.0 keyword/target added to this bug. Rodolfo is right, this functionality is a basic requirement of much DHTML development (for example an HTML windowing system with multiple pages loaded in IFRAMEs). An IFRAME is a W3C standard HTML element - unlike an ILAYER, so will work cross-browser. IE5.5 renders multiple IFRAMEs with a z-index correctly, and the lack of support in mozilla can cripple apps where documents need to overlap. Pleases reconsider the Future target, as this will inevitably result in this not being fixed in the forseeable future. Also, I can confirm that this is not limited to PC platform / Win98 OS, I have confirmed the behaviour in MAC- OS and Linux too - can this be changed?

z-index on DIV, indeed, everything except IFRAME, works fine ... at least, it will when my view manager changes are turned on by default. It's a lot easier for IE 5.5 to support z-index on IFRAMEs because IE 5.5 doesn't try to handle "z-index: auto" correctly, so their z-index code is probably a lot simpler than ours. Kevin, I think the only sane way to solve this would be to put all views for an entire application window under one view manager, or somehow link the view managers together to achieve the same effect. What do you think?

I think it would be best to try to link the existing viewmanagers together. This way we would be able to perform optimizations when we know all of the view's bound to viewmanager are always on top or below all of the views managed by another viewmanager. The end result would be that the viewmanagers really are just a grouping mechanism for managing view's efficiently, while construction and processing of the culled display list would take into account multiple viewmanagers to make the display correct. One optimization would be to disregard the viewmanager's associated with the chrome when rendering the content area.

I think you're right. > One optimization would be to disregard the viewmanager's associated with the > chrome when rendering the content area. Hey, I dream of translucent chrome controls floating over my full-screen content area :-). This would fix a raft of bugs, including "what should we do with translucent documents?". We could also improve performance. It seems worth doing.

This is a serious problem - it occurs with any absolutely positioned element (not just <div>) and means that you can't overlay an <iframe> with anything other than another <iframe>

actually this problem seems to be alot more complex... zindex'es set in the html code through style="" and zindexes set via javascript doersn't seem to go to well together... at http://www.oncable.dk you will see that if you mouseover the rightmost menu item 'profil' it will popup behind the scrollbar (which is just a <div> layer really) and this eventhough the popup layer has z-index 8, set in the htmlcode, and the menubar has z-index 6 set via javascript (it is set dynamically when the scrollbar is build, which it only is when the contentlayer has enough text that it needs scrolling... just like frames with scrolling=auto) i see the same with iframes nested in div's, they are always topmost zindex and so on and so forth... the zindex management is completely unreliable as far as i can tell, and makes dhtml a virtual impossibility in the browser, which is too bad really :(

Martin, that page is really complicated. Is there a simple, small test case that demonstrates the problem you're talking about?

Here is some "simple" example code. http://www.webmoguls.com/bugs/43410/moz_43410_sample.html Hoping for a moz1.0 designation on this one.

Both Martin & Hardy's examples highlight WHY this bug is so serious - you simply can't mix a div-based pop-up menu with iframe-based pages. However, the menu and rollover code is irrelevant to the basic bug - which is that an iframe incorrectly handles (ignores) the z-index value of other elements. See http://www.tamachain.co.uk/bug43410.html for a simple example.

OK. I think we (or at least I) understand the issues with IFRAMEs not respecting z-index, both why the bug exists and what we should do about it. However Martin was talking about something else to do with whether z-index is set by an explicit style rule or through the DOM. As far as I know there are no bugs in that department. We do know how to fix this but it's not going to be easy, especially because we want to fix it right, which means transparent elements hanging over IFRAMEs have to show the IFRAME underneath, and we also want to support transparent IFRAMEs as well. If you can collect more votes, and work out a list of popular sites that rely on this, that would help move it up the radar. And in the meantime, DON'T PANIC.

Updating summary, this affects elements other than DIVs.

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

A common use of this is a menu system that is layered over a content frame. Attaching a simple testcase that has two abs. positioned IFRAMES. Scrolling an IFRAME will leave garbage from the other frame. The testcase alwo allows to swap the zIndex of the two frames.

While the attached testcase IFRAMES display a file not found messgage, this doesn't matter. The behavior can still be observed.

Marking DIGbug, PDT+. Blocker for DIG.

What is "DIG"?

Here is an example of a dhtml menu that drops over and manipulates an iframe: http://webfx.eae.net/dhtml/dhtmlmenu3/skin.html?menu.css It's the little grey menu on the top left, integrated with the browser chrome. It reads: File, WebFX, Skins. The main content is an iframe. It is explorer only, so this type of menu is used in intranets more than on the internet. This is one example, but the problem with iframes and z-index comes up regularly and in different situations. Thanks for looking into this.

Addition: I wanted to clarify the problem, that this kind of setup is not possible in mozilla because of this bug.

Changing to DIGBug+, as this is critical to DIG and Calendar app.

Unfortunately, I've not been able to make any progress with this one. Handing to Patrick in hopes that he'll have better luck. Patrick, please let me know if you have any ideas for fixes that I can help with on this one. (x6821, I'll be in by 9AM) I'll attach a simplified testcase. To see the problem, try minimizing the window or dragging other windows on top of the browser. Since both iframes have an (opaque) native widget, and paint requests are not synchronized, whichever iframe is last exposed will paint on top, regardless of z-index.

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

We're out of time, the PDT+ is coming off this bug this afternoon...

Removing PDT+. Please apply your work on the trunk when you're ready.

The above patch is based on work Patrick and I did earlier today - it fixes the case where an iframe with it's z-index overlaps another iframe with it's z-index set, on Windows. (This case already works acceptably on Mac, and the patch has no negative effect on Linux). The windows will paint and clip correctly, even through window minimize/restore, and cover/uncover with another window. In order to get this patch working on Linux, widget/src/gtk/nsWindow.cpp will need to implement PlaceBehind(). I tried several implementations that did random things like gtk_window_lower and gtk_window_reparent with no success. Stuart, do you have any ideas on this? I don't think that it is going to be feasible to solve the iframe with z-index overlaping a non-iframe piece of content with z-index at this late stage, but at least this patch gets us part way there...

The idea of the patch seems sound, but I have a couple of comments. Did you try putting the widget Z-index setting code in nsViewManager::SetZIndex instead of nsContainerFrame::SyncFrameViewAfterReflow, so that it gets set for all widget-bearing views? This would be a more general solution and the changes could be smaller. This approach will not work correctly with complicated pages using "z-index: auto". But IE doesn't do that right either so that's not worth worrying about yet. A complete solution to this requires organising nsViewManagers into a hierarchy so that a repaint in one view manager can paint overlapping views belonging to other view managers. But even when that's implemented, setting the widget z-indexes as you're doing will be helpful for performance reasons.

Thanks Robert. With that change, this second patch seems to have fewer quirks on the DIG site - but still only addresses iframe to iframe zindex ordering, and not iframe to non-iframe zindex ordering (All iframes appear on top of other content). It still does not include a fix for Gtk (Linux).

Patch looks good, r=beard, but the call to widget->SetZIndex(aZIndex) in nsViewManager::SetViewZIndex() is theoretically redundant, because nsViewManager::InsertChild(nsIView *parent, nsIView *child, PRInt32 zindex) calls nsIView::SetZIndex(), and nsView::SetZIndex(PRInt32 aZIndex) calls nsIWidget::SetZIndex() on its mWindow field if it is non-NULL. So, you might be calling it twice in some cases. However, if widgets get created after views are inserted, this may be necessary as the z-index of the view may not be changing, but the widget really still needs to be rordered.

r=beard on third patch. let's get this checked into the trunk! waterson, care to super review?

Johnny says: "sr=jst@netscape.com"

Checked this patch in on the trunk. Please help test this as much as possible tomorrow, and attach any feedback (positive and negative) here. Thanks!

I tested this on the Calendar app this morning, and it looks good! I'll do some more testing this afternoon, but everything that i've tested so far looks great.

I've been using the daily build for all my work today, sending/recieving email, AIM without any problems. I've also run browser buster for a few hours with no crashes (top 100 and random site), and did a quick check of prefs, address book, password/cookie/form manager, help, composer, ... and haven't seen any obvious problems.

Returning to the PDT+ list. Dynamic HTML pages were identified as the primary risk area. Please get at least 5 of these sites and show that they continue to work after this fix. Checkin on the branch is approved, please procede with that and test further in parallel.

I'll be checking into the branch this evening. In the meantime, Marcio Galli is helping by coming up with an exhaustive list of DHTML test sites.

One great implementation (not verified if this is using IFRAME), but it's exhaustive use of DIVs, events(drag), etc: Windows: *** http://www.brainjar.com/dhtml/windows/demo.html More stuff: ** Netscape 6.1 Welcome page: IFRAME and DHTML page inside: http://home.netscape.com/browsers/6/su_setup61pr.html exhaustive use of DIV and clip: ** http://www.mozilla.org/docs/dom/samples/can/index.html Animating DIV/PNG: http://www.dhtmlplanet.com/webfilmed/png/ Events, DIVs, DOM1: http://www.taboca.com/worlds/gek/board/r21/computer.html GameTab (go and click the livepreview icon). Will create an IFRAME with a flash inside. http://www.mamata.com.br/sidebar/ ---------- This is what I have in mind for now. Will keep watching this. But anyway the feature is great!! we can jump to a next level of web apps.

One more QA Test: ---------------- http://www.dynamicdrive.com/dynamicindex8/dhtmlwindow.htm

Fix checked in on the branch and the trunk. Marking FIXED. Now, to reveal this bug for the hydra it is, I've filed three new bugs to address the remaining issues: 1) Linux needs to implement nsWindow::PlaceBehind() (bugs 91508) 2) Cleanup redundant widget->SetZIndex in nsViewManager::SetView (bug 91511) 3)IFRAMEs do not respect z-index of other, non-iframe content (bug 91516)

Fixing link: 1) Linux needs to implement nsWindow::PlaceBehind() (bug 91508)

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

This fix does not work in Netscape 6.2.1 neither in mozilla 0.9.7

Cecile, are you seeing _this_ bug? Or bug 91516?

You are right, I am seing bug 91516. My problem is with _div_ components. So, I think that: - attachments as http://www.tamachain.co.uk/bug43410.html - bugs as bug 78699 deal with bug 91516 instead of bug 43410. thanks,

re-resolving per comments.