Closed Bug 91516 Opened 24 years ago Closed 24 years ago

IFRAMEs do not respect z-index of other, non-iframe content

Categories

(Core :: Web Painting, defect)

Product:
Core
Component:
Web Painting
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.9

People

(Reporter: pollmann, Assigned: roc)

References

(
URL
)

Details

(Keywords: testcase, topembed, Whiteboard: [DIGBug][eapp])

Attachments

(10 files, 2 obsolete files)

Drop-down menus that fall benind disrespectful iFrame
35.01 KB, text/html
Details
Stacks and iframes.
1.16 KB, text/xul
Details
HTML code demonstrating that the error concerns both the OBJECT and the IFRAME element
5.05 KB, text/html
Details
screenshot of the IFRAME+OBJECT example
47.42 KB, image/png
Details
new patch
23.53 KB, patch
kmcclusk
: review+
attinasi
: superreview+
Details | Diff | Splinter Review
Safety patch for nsObjectFrame
1.05 KB, patch
peterlubczynski-bugs
: review+
attinasi
: superreview+
Details | Diff | Splinter Review
Safety patch for print preview
804 bytes, patch
rods
: review+
attinasi
: superreview+
Details | Diff | Splinter Review
Set of files in zip to demonstrate the problem
4.40 KB, application/octet-stream
Details
Set of files in zip to demonstrate the problem
5.01 KB, application/octet-stream
Details
Stacks and iframe (enhanced)
1.34 KB, application/vnd.mozilla.xul+xml
Details
An iframe will always be painted on top of non-iframe content, regardless of z-index of the iframe vs. that non-iframe content. See the URL above for an example. This is a followup to bug 43410, which addressed iframe vs. iframe z-index ordering.
Whiteboard: [DIGBug]
I am working on a project for AT&T that makes extensive use of DHTML (DIV + IFRAME tags) for site navigation. The current codebase works flawlessly with IE (and even Nav4 using LAYER/ILAYER), but Nav6 completely disregards the z- indexes and renders the navigation menu useless. I'll have to scrap the whole design (weeks of work) if I can't get Nav6 to cooperate. Is there a light at the end of the tunnel? Will this be corrected in the next release?
Hi Aaron, it depends on how you implemented your menus. With the fix that went in for 43410 (yes, this will be in for the next version of Netscape), one of these issues was resolved - an iframe that have a higher z-index than other iframes will appear on top of them. A div that has a higher index than another div should already have appeared on top of them. There are still some issues, as mentioned at the end of bug 43410. You can try a nightly build of Mozilla to test your design, here: ftp://sweetlou/products/client/6.x/ Choose your platform, then a build from any date after 2000-July-19, and you should get one that has the change in it.
Sorry, wrong URL! Make that: ftp://ftp.mozilla.org/pub/mozilla/nightly Choose the date, then find the build for your platform. :)
Let me just quickly describe the setup. The document contains DIVs for all the menu layers, and an IFRAME for the target content. The menubar (with expanding menus) is at the top, and the IFRAME takes up the rest of the window. Since IFRAMEs can be the target of an HREF or SRC (and sometimes document.location), it makes it real easy to update the contents of the IFRAME based on a menu click since you can treat them like a normal frame. The trouble is, the DIVs get hidden by the IFRAME under Nav6, so most of the menu (when expanded) is obscured (or all of it depending on the page). Since the z-index of DIVs and IFRAMEs don't play together under Nav6 (and the version I'm using didn't have the fix for the IFRAME portion), I tried this approach: 1. Create a hidden IFRAME. Had to be hidden because of the display: none bug. 2. Use a DIV instead of the IFRAME for the visible window content. 3. Load into the IFRAME, then use innerHTML to transfer to the DIV. But, this has some really bad side effects: 1. Style sheets are lost and must be included in the parent document. Not good, since the parent doc then has to contain every style sheet for every page I plan to load (and *.js too if I'm remembering correctly). Even when the CSS files are included, there still appear to be some formatting issues. Maybe there's a way around this? 2. The document loaded into the hidden IFRAME must call into the parent document to let it know when it's done loading so it can transfer the contents to the DIV. If it weren't for the onLoad bug in IFRAME, this could be handled in the parent doc so that each content document need not know it's being loaded under these forced conditions. 3. If the document loaded into the IFRAME also contains an IFRAME, the whole system breaks since there's no easy way to delay content loading the whole way up the hierarchy until the lowest IFRAME is loaded. 4. Java applets are really bad in this scenario, because the applet gets loaded twice. 5. This really overcomplicates the design and code. It's just not feasible to do it using DIVs only. It may be possible to do it using IFRAMEs only, though that's certainly not the ideal or most practical way to do things. I will try grabbing the new version with the z-index fix for IFRAMEs and attempt to create an IFRAME only version. Really, from an API point of view, IFRAMEs and DIVs should respect each other's z-index settings. Without cooperation between the two, it makes it impractical to use DHTML for enterprise-level site navigation and instead reduces what I can do with it to just a few flashy tricks on a single page. Thank you for your time looking into this. I'll try the IFRAME scenario next week and get back to you. P.S. This is a separate bug that may have been reported already (I haven't had time to look into it or run a more detailed test case), but adding functions to HTMLElement.prototype in Nav 6.1 Preview Release 1 doesn't work. The browser is unable to find HTMLElement, though it works fine in Nav 6.01.
Have you tested this approach/bug in MSIE prior to version 5.5 in Windows or MacOs? You'll find the same bug exhibited there as well as in Opera 5.x on most platforms. Whilst this doesn't help solve the NN6/Mozilla problem it does suggest that a different approach may be necessary for widespread support of your menu system.
Agreed. After working with some of the earlier browsers, I've confirmed that this is a larger problem than I first realized and is certainly not Mozilla specific. Currently we're targeting Nav6 and IE5.5, so as long as I can get it working on those two I'll be in good shape. Until the z-order issue in Nav6 is resolved, I've settled on a temporary solution -- use DOM/CSS to hide all IFRAME, OBJECT, EMBED, etc. while the menu is being shown. It's definitely not an ideal solution, but my initial tests with it have been somewhat successful. There's a requirement in my project to do popup menus later based on mouse cursor position, and since the main content frame is an IFRAME, I expect to run into rather large problems with my current approach. If I could get some idea of the timeframe for this fix in Nav6, I might be able to continue development using IE5.5 in the mean time. Otherwise, I think I'm in for a few more setbacks.
I thought I was on to a way to create an IFRAME only version of this menu system, but bug #22681 (http://bugzilla.mozilla.org/show_bug.cgi?id=22681) is preventing me from moving forward with the solution. Basically, I'm trying to create an IFRAME on the fly by inserting it dynamically. Then I was planning to populate the contents via innerHTML or something similar, but the document object of the dynamically created IFRAME is null. Static IFRAMEs embedded in the page don't seem to have this problem. I'll see if I can insert some dummy static frames in the mean time to test the approach.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Attached file Stacks and iframes. —
This error concerns the OBJECT-tag also.
*** Bug 106743 has been marked as a duplicate of this bug. ***
IFrames do not obey z-index relative to the parent document because they create widgets. The parent documents widget would need to be shared by the iframe subdocuments to allow z-index to work. In addition the parent document's viewmanager would need to paint requests to the iframe documents viewmanager.
Depends on: 31468
Target Milestone: Future → mozilla0.9.9
I don't think it's plausible that we'll get rid of ALL native widgets from the content area. We'll always be stuck with plugins, at least. OTOH we can wire together the view managers so that every widget can paint overlapping contents from other view managers. What we really need here is for IFRAME view managers to be able to find and paint the views that overlap it from sibiling and parent view managers.
This is actually something I'm interested in doing once the view API gets cleaned up (nudge, nudge)
*** Bug 114367 has been marked as a duplicate of this bug. ***
WORKSFORME on your non-iframe => style="position:fixed;......." The KiLoBug.
Status: ASSIGNED → NEW
*** Bug 121272 has been marked as a duplicate of this bug. ***
*** Bug 121339 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.9 → mozilla1.1
I just got notice that the target for this bug got pushed out from 0.9.9 to 1.1, but there is NO explanation. What gives?
I am planning to work on this very soon, but I won't steal it from Kevin until I actually have working code :-).
I have code for this limping along. It should be in decent shape soon. It wasn't as hard as I thought.
Assignee: kmcclusk → roc+moz
Target Milestone: mozilla1.1 → mozilla0.9.9
This does not depend on bug 31468; we can solve it without getting rid of native widgets (although native scrollbars are currently causing me grief). It does depend on bug 96832 because we need smart event handling to ensure an event in a widget that is owned by an IFRAME can be dispatched to a view with a different view manager.
Depends on: 96832
No longer depends on: 31468
Here's how it works... Note that both OBJECT and IFRAME work correctly with my patch.
My fix is done. I'll attach a patch once 96832 is checked in. The fix will slow down scrolling inside IFRAMEs a bit. This slowdown will go away when I fix a major latent scrolling problem that I just uncovered (see bug 124554).
Will the proposed fix also take care of bug 43699 ("Frame is rendered behind fixed position DIV")?
This is starting to look really good. Will this fix also allow -moz-opacity to work with iframes and objects?
*** Bug 43699 has been marked as a duplicate of this bug. ***
No, -moz-opacity still won't work properly with IFRAMEs (or any moderately complex container element). The problem with -moz-opacity is that we don't implement group opacity, and that won't change before 1.0. There is much more important work to do --- like this! (However, this fix is certainly a step in the right direction for opacity support.)
Status: NEW → ASSIGNED
nominating for nsbeta1
Keywords: nsbeta1
Whiteboard: [DIGBug] → [DIGBug][eapp]
Major corporations depend on eapp bugs, and need them to be fixed before they can recommend Mozilla-based products to their customers. Adding nsbeta1+ keyword and making sure the bugs get re-evaluated if they are targeted beyond 1.0.
Keywords: nsbeta1 → nsbeta1+
I'm ready to submit the patch, except I just realized that it slows down scrolling of frames in FRAMESET pages, which is quite important, as well as scrolling in IFRAMES, which IMHO is not so important. I will tweak the patch to fix that and submit it later tonight. If things go well we should be able to get this in for 0.9.9.
when (proper) iframe support is widely available, i'm sure it will be used a lot by web designers. i will at least ;-). layouting with iframes is way more flexible than with standard frames, not only thanks to css. so i think scrolling-speed in iframes is just as important as in normal frames, since iframes will more and more replace them. thanks, phil
I have to agree with the above. If you're doing serious DHTML work, FRAMES are rarely if ever used, and IFRAMES are much preferable. At DIG (a DHTML/Web App group inside AOL), we use IFRAMES exclusively. IFRAME support in NN6.2 is still ragged, and needs to be improved, and certainly not hurt by decreasing the performance of scrolling speed within IFRAMES. My 2 Cents :) Kirk
I know what's required to fix the scrolling issues with IFRAMEs. It should happen soon. It's just a matter of what gets fixed first.
*** Bug 125175 has been marked as a duplicate of this bug. ***
Attached patch the fix (obsolete) — — Splinter Review
As promised, this patch joins view managers for different documents together into a hierarchy. This allows IFRAME documents to dispatch paint and event handling to other view managers for overlaid content. In theory all documents can be joined together this way, so that, for example, chrome can be overlaid onto content. This patch restricts the joining so that child documents are only joined to parents which are content shells and not frameset documents. However, if the parent is already joined into a hierarchy then we force its children to join too, otherwise we will see serious bugs. I've restricted the joining to mitigate the effect of certain performance bugs, and to reduce the overall risk. As discussed above, this patch will slow down IFRAME scrolling due to a serious preexisting scrolling bug, bug 124554. I will be working on that bug next.
Keywords: testcase
eapp was incorrectly used to change this to nsbeta1+. Resetting to nsbeta1 to nominate. This is an important issue and deserves to be nsbeta1+ by the ADT.
Keywords: nsbeta1+ → nsbeta1
Keywords: topembed
*** Bug 125706 has been marked as a duplicate of this bug. ***
Marking nsbeta1+
Keywords: nsbeta1 → nsbeta1+
I applied patch 69248 using a pull from yesterday on WinXP and I am seeing a problem with the tinderbox popup's. When I click on the email address in the guilty column the popup appears, but if I click on the "Last check-in" link, the popup goes away leaving only its border and it does not bring up the last checkin info. Just to make sure this wasn't a problem with my build I reversed the patch and rebuilt and the tinderbox popup's behave correctly.
*** Bug 126064 has been marked as a duplicate of this bug. ***
Attached patch new patch — — Splinter Review
The Tinderbox problem turned out to be a longstanding bug where if an nsHTMLFrameOuterFrame required a view, then its child nsHTMLFrameInnerFrame's view would be created as a sibling of the outer frame's view rather than its child. That never mattered before... This patch fixes that. This patch also fixes a bug with destroying views where the previous patch wouldn't repaint enough. I've tested this patch on the viewer, XUL and XBL demos, plus 60 of the browser buster pages (which aren't much use for this really), plus dhtmlcentral.com and the mozilla.org usual suspects.
Attachment #69248 - Attachment is obsolete: true
All the duplicates of this bug are basically fixed by the patch. There are some small problems left in some of the duplicates, partly due to bug 125386.
Comment on attachment 70019 [details] [diff] [review] new patch sr=attinasi ps. 'heldRefCountsToOtherVMs' could be called the colloguially endearing 'kungFuDeathGrips'. Also, why a void array and not a supports array?
Attachment #70019 - Flags: superreview+
Robert, I SR'd the patch, it is surprisingly straight-forward. My only lingering concerns are that the semantics of the view / view manager relationships have changed slightly, and that a root view can have a parent now and some people may not realize that. Most of the details are fortunately encapsulated itne the view system. We really *really* need some documentation on the view system. I was about to request that you update the docs with this new patch, but then I found that there are no docs at all! How do you feel about documenting the view system? I have created some templates and guidelines for layout, if you are interested (see the layout\docs directory for the templates and some docs).
> why a void array and not a supports array? I didn't think of it :-). Good idea. I'll write some documentation.
CC'ing peterl, because these changes may affect some plugin code which I think assumes that the root view's parent is null.
See: http://lxr.mozilla.org/mozilla/ident?i=GetWindowOriginInPixels It's always used on Mac and only for "windowless" type plugins on Win32 Sample Win32 windowless plugin: modules/plugin/tools/sdk/samples/winless
peterl: It looks like nsObjectFrame::GetWindowOriginInPixels has a bug in that could be exposed when this patch is checked in. GetWindowOriginInPixels should keep adding up the ancestor view's offsets until it gets to a view with a widget or it's parent view is null. It's working right now because the viewmanager's root view never has a parent and it owns a widget. Although, I think it would only be a problem if you had a windowless plugin inside an IFRAME. That would be a very rare occurence.
I think we should file a separate bug for the nsObjectFrame::GetWindowOriginInPixels issue and let Robert check in his patch.
It could be a problem for Mac plugins inside IFRAMEs, but I'm not really sure what this plugin code is doing with the pixel coordinates. It would probably be safest to modify GetWindowOriginInPixels so that it stops at the nearest view manager root, preserving the current behavior. I will do that and post the patch here before I check in. Thanks for the eyes, guys.
Here's an additional patch that should ensure nsObjectFrame::GetWindowOriginInPixels is not affected.
Time is short so I will try to check in patch 70019 tomorrow morning before the tree opens. I'll check in 70236 as soon as it gets its own reviews.
Comment on attachment 70236 [details] [diff] [review] Safety patch for nsObjectFrame r=peterl
Attachment #70236 - Flags: review+
Patch 70019 causes print preview to crash in some of these testcases. Not checking in yet.
This patch fixes a crasher in print preview. With this patch, I can print and print preview on IFRAME examples like 68262. The print output doesn't actually look right, but it doesn't look any worse either :-). Fixing printing of overlapping IFRAMEs and normal content is a significant project and it will have to wait.
Ccing rods the printing man. Actually I think these changes could make printing a lot simpler. But I'm not sure since I don't really understand the print code in nsDocumentViewer yet.
Comment on attachment 70312 [details] [diff] [review] Safety patch for print preview Yes, that looks like a good idea r=rods
Attachment #70312 - Flags: review+
Comment on attachment 70236 [details] [diff] [review] Safety patch for nsObjectFrame sr=attinasi
Attachment #70236 - Flags: superreview+
Comment on attachment 70312 [details] [diff] [review] Safety patch for print preview sr=attinasi
Attachment #70312 - Flags: superreview+
All 3 patches checked in. Thanks all
I guess I can mark this fixed :-)
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
thanks all! this was an important one (to me). phil
Please download a build from today (or later) and make sure it works for you.
Does this fix bug 125162 as well?
It gets us much closer. Now that this fix is in, the infrastructure exists to support chrome floating over the editor. However, this patch contains some checks that will have to be disabled to make that work. (Right now I'm not integrating chrome and content because that might cause a slight performance loss and it would be more risky.)
Okay, I've verified that this is definately fixed, and I would mark it as VERIFIED if I had the necessary permissions. I also filed bug 127981, a remaining issue related to this.
FYI, one of the changes to nsViewManager::DispatchEvent() caused regression bug 127368 ... it's preventing typing into some of the textfields on some major sites when iframes are present. (home.netscape.com, www.lycos.com, www.cnnfn.com, to name a few)
*** Bug 128852 has been marked as a duplicate of this bug. ***
*** Bug 129106 has been marked as a duplicate of this bug. ***
*** Bug 128226 has been marked as a duplicate of this bug. ***
Okay, I couldn't get the <a hrefstacks and iframes testcase to work. iframe is still always on top of <box>. build 2002030208
IFRAME or BROWSER children of chrome do not get integrated into the view hierarchy so they won't interact properly with siblings in terms of z-index and overlap. This was a deliberate decision because I didn't want to change the behavior of the main browser window (too risky). We can change this policy after Mozilla 1.0 ships.
*** Bug 130042 has been marked as a duplicate of this bug. ***
Is new bug 130263 caused by, or related to, the fix for this bug?
Marking verified in the April 22 build (2002-04-22-03).
Status: RESOLVED → VERIFIED
The drop down menu disappears when the mouse pointer touches the iframe and thereby cannot be used. Package is zip file containing all the links called by the html test file.
The drop down menu disappears when the mouse pointer touches the iframe and thereby cannot be used. Package is zip file containing all the links called by the html test file.
This bug doesn't seem to be fixed. I just tried the second example (with some changes) in Firefox (1.5.0.6) and Xulrunner (1.8.0.4) and it looks broken. The "Stacks and iframes" example (#2) outlines the problem.
Enhances the second example to really show the problem with iframs in stacks and their order.
Comment on attachment 234879 [details] Stacks and iframe (enhanced) ><window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"><box flex="1" orient="vertical" align="center"><groupbox><caption label="Green Box on Red Box"/><stack><box top="10" left="10" width="100" height="100" style="border: 2px solid rgb(255, 0, 0); background-color: rgb(255, 255, 255);"/><box top="10" left="10" width="100" height="100" style="border: 2px solid rgb(0, 255, 0); background-color: rgb(238, 238, 238);"/></stack></groupbox><groupbox><caption label="Green Box on Red Iframe"/><stack><iframe top="10" left="10" width="100" height="100" style="border: 2px solid rgb(255, 0, 0);" src="http://www.mozilla.org/"/><box top="20" left="60" width="100" height="100" style="border: 2px solid rgb(0, 255, 0); background-color: rgb(238, 238, 238);"/></stack></groupbox><groupbox><caption label="Green Iframe on Red Iframe on Blue Box"/><stack><iframe top="10" left="10" width="100" height="100" style="border: 2px solid rgb(255, 0, 0);" src="http://www.mozilla.org/"/><iframe top="20" left="60" width="100" height="100" style="border: 2px solid rgb(0, 255, 0);" src="http://bugzilla.mozilla.org/"/><box top="0" left="40" width="100" height="100" style="border: 2px solid rgb(0, 0, 255); background-color: rgb(170, 170, 170);"/></stack></groupbox></box></window>
File a new bug if you can reproduce it on *trunk* builds (not 1.8.anything, 1.9).
(In reply to comment #85) > File a new bug if you can reproduce it on *trunk* builds (not 1.8.anything, > 1.9). > bug occurs on latest trunk for me I have submitted a new bug (https://bugzilla.mozilla.org/show_bug.cgi?id=355078)
Blocks: 355078
(In reply to comment #86) > (In reply to comment #85) > > File a new bug if you can reproduce it on *trunk* builds (not 1.8.anything, > > 1.9). > > > > bug occurs on latest trunk for me > > I have submitted a new bug > (https://bugzilla.mozilla.org/show_bug.cgi?id=355078) > scratch that, bug occurs in chrome only (finally read all the comments in this bug :)
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: