Closed Bug 91516 Opened 23 years ago Closed 23 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: 23 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: