Bug 31121 - [test case] iframes, objects behave as if they had an infinite z-index (always on top)
Summary: [test case] iframes, objects behave as if they had an infinite z-index (alway...
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml forms (show other bugs)
Version: unspecified
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
: 50620 51598 52869 53338 56536 56777 57194 58840 60300 68725 70160 72777 73161 79520 82870 83419 83762 83931 86545 92950 94117 107059 108757 108973 110651 112386 113032 114463 115345 115388 118476 120208 (view as bug list)
Depends on:
Blocks:
 
Reported: 2001-08-20 11:03 UTC by Dreisam-RD
Modified: 2006-11-09 21:30 UTC (History)
34 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
test case (548 bytes, text/html)
2003-12-23 17:29 UTC, Oded Arbel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description engels 2001-08-20 10:50:24 UTC
(*** This bug was imported into bugs.kde.org ***)

Package:           khtml
Version:           KDE 2.2.0 
Severity:          normal
Installed from:    Unspecified Linux
Compiler:          Not Specified
OS:                Linux
OS/Compiler notes: qt-2.3.0-3

CSS2 - z-index attribute:
o form elements like textarea are alway drawn on top
  even if they should be overlapped by a higher layer

Absolute positioning:
o margin-left is relative to the containing box. I thought
  it should be relative to the contents of the containing 
  box!?

Robustness:
o an <img ..> with a missing src attribute causes reload


(Submitted via bugs.kde.org)
Comment 1 djoham 2001-11-01 20:07:20 UTC
I'm seeing this too while I've been working on some JavaScript menus.
Here's my test case. The button has a z-Index of 0 and should be
covered by both the red and the blue block. Konqi renders the button
right on top.  Mozilla renders correctly. Konqi renders the divs
correctly but not the form element.

    <html><body>
    <div style="width: 200px; height: 200px; position: absolute; top:
25px; left: 25px; z-Index: 1; background: red">hello</div>
    <div style="width: 200px; height: 200px; position: absolute; top:
20px; left: 20px; z-Index: 2; background: blue">hello</div>
    <input type="button" value="foo" style="position: absolute;
z-Index: 0; top: 30px; left: 30px; width: 200px; height: 200px">
    </body></html>

Thanks for your attention. 

David

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com
Comment 2 David Joham 2002-02-18 21:16:04 UTC
This bug is still visible in cvs from 17 feb 2002


=0D
_________________________________________________________=0D
Do You Yahoo!?=0D
Get your free @yahoo.com address at http://mail.yahoo.com=0D
=0D
Comment 3 Dirk Mueller 2002-09-25 01:47:37 UTC
the other two problems are known. do you have a testcase for that margin-left 
problem? 
Comment 4 Timo A. Hummel 2003-01-31 10:52:44 UTC
Testcase for the z-index bug: 
 
http://www.timohummel.com/kde-bugs/testcase-31121/ 
 
Can we have a testcase for the margin-left problem? 
Comment 5 George Staikos 2003-03-28 19:19:18 UTC
*** Bug 56536 has been marked as a duplicate of this bug. ***
Comment 6 Tiago Freire 2003-04-10 22:15:53 UTC
I see this too, my system is: 
Gentoo Linux x86 
kde3.1.1 (kdebase r1) 
qt 3.1.2 
xfree4.3.0 (r1) 
nvidia drivers version 1.0.4349 
compiled with gcc 3.2.2 
-O2 -pipe -fomit-frame-pointer -mcpu=athlon-xp -march=athlon-xp -mmx -sse -3dnow 
-fpmath=sse,387 
another test 'on the wild': 
http://www.digimer.com.br 
the ticker tape is a form element. 
Comment 7 Maksim Orlovich 2003-05-13 17:52:47 UTC
*** Bug 56777 has been marked as a duplicate of this bug. ***
Comment 8 Maksim Orlovich 2003-05-24 00:09:02 UTC
*** Bug 58840 has been marked as a duplicate of this bug. ***
Comment 9 Maksim Orlovich 2003-06-14 16:08:21 UTC
*** Bug 51598 has been marked as a duplicate of this bug. ***
Comment 10 Maksim Orlovich 2003-06-14 17:47:39 UTC
*** Bug 52869 has been marked as a duplicate of this bug. ***
Comment 11 Maksim Orlovich 2003-06-14 17:48:28 UTC
*** Bug 50620 has been marked as a duplicate of this bug. ***
Comment 12 Thiago Macieira 2003-06-24 13:23:15 UTC
*** Bug 60300 has been marked as a duplicate of this bug. ***
Comment 13 Arwed Starke 2003-07-23 01:34:49 UTC
watch e.g. www.ghettotech.de to verify this behaviour: the textarea headers 
("news flash" etc.) should be above them but they are below them and look cut. 
 
or www.notoriousonline.com - the menus on the main page open up lying behind 
other page elements (probably flash elements?) 
Comment 14 Dirk Mueller 2003-08-26 00:10:54 UTC
*** Bug 53338 has been marked as a duplicate of this bug. ***
Comment 15 Stephan Binner 2003-10-18 20:54:31 UTC
I have seen this working several times with khtml/HEAD after N7y, e.g. testcases in comments 4, 6 and 8. Which sites still don't work?
Comment 16 George Staikos 2003-10-18 20:58:22 UTC
Subject: Re:  form elements behave as if they had an infinite z-index (always on top) (testcase)

On Saturday 18 October 2003 14:54, Stephan Binner wrote:
> I have seen this working several times with khtml/HEAD after N7y, e.g.
> testcases in comments 4, 6 and 8. Which sites still don't work?

  I think it's best to leave this until Lars is done with it.  There are still 
many bugs.

  Also embedded components still dont' have infinite z-index, but then again, 
they probably never will.

Comment 17 Jason Keirstead 2003-10-18 21:31:19 UTC
Why would you want embedded components to have an infinite z-index?

Nothing should have an infinite z-index, everything should be adjustable via CSS. Giving components an infinite z-index would just needlessly restrict the web developer making things like dragging HTML objects over an embedded component impossible.
Comment 18 Dirk Mueller 2003-10-20 00:11:30 UTC
Jason, you know, sometimes there is a difference between how things should behave and whats technically possible. 
Comment 19 Jason Keirstead 2003-10-20 00:54:22 UTC
Well if it is not possible to have embedded components follow z-index rules that is fine.

"Also embedded components still dont' have infinite z-index, but then again, 
 they probably never will. "

Its just the comment sounded like you were *trying* to give them an infinite z-index on purpose.
Comment 20 George Staikos 2003-10-20 00:57:07 UTC
Of course in my previous comment that should have said "finite" because they are infact "infinite" in behaviour.
Comment 21 Jason Keirstead 2003-10-20 01:14:32 UTC
Ah I understand now. No harm no foul.
Comment 22 Maksim Orlovich 2003-11-21 15:02:00 UTC
*** Bug 68725 has been marked as a duplicate of this bug. ***
Comment 23 Stephan Kulow 2003-12-11 22:26:54 UTC
*** Bug 70160 has been marked as a duplicate of this bug. ***
Comment 24 Jesper Juhl 2003-12-15 00:28:06 UTC
I see identical behaviour in konqueror from kde 3.2beta2 , mozilla 1.4 & netscape 7.1 with the testcase at http://www.timohummel.com/kde-bugs/testcase-31121/  - the behaviour being that the text is shown on top on a blue background, the red box is below the blue one.
Comment 25 Jason Keirstead 2003-12-15 14:14:21 UTC
Subject: Re:  form elements behave as if they had an infinite z-index (always on top) (testcase)

On December 14, 2003 7:28 pm, you wrote:
> I see identical behaviour in konqueror from kde 3.2beta2 , mozilla 1.4 &
> netscape 7.1 with the testcase at
> http://www.timohummel.com/kde-bugs/testcase-31121/  - the behaviour being
> that the text is shown on top on a blue background, the red box is below
> the blue one.

Yes, works here too. However, it is still broken. Try this:

<select style="z-index:0"><option>Stuff</option></select>
<div 
style="margin-top:-20px;width:100px;height:100px;background-color:red;z-index:1">Foo</
div>

The red background will be beneath the select box, but the Foo text will be 
above it. They should both be above it.

Very unusual.

Comment 26 Oded Arbel 2003-12-23 17:29:35 UTC
Created attachment 3830 [details]
test case

A simple variation on the above example. in this test case the select is
clearly above the red <div> - text and all - even though it has a lower z-index
Comment 27 Maksim Orlovich 2004-01-11 18:59:10 UTC
*** Bug 57194 has been marked as a duplicate of this bug. ***
Comment 28 Dirk Mueller 2004-01-16 20:48:45 UTC
*** Bug 72777 has been marked as a duplicate of this bug. ***
Comment 29 Jesper Juhl 2004-01-20 23:25:58 UTC
The sites listed in comment #13 are still broken with Konqueror from KDE 3.2RC1
Comment 30 Maksim Orlovich 2004-01-21 18:44:59 UTC
*** Bug 73161 has been marked as a duplicate of this bug. ***
Comment 31 Arwed Starke 2004-01-25 18:46:46 UTC
In KDE 3.2 rc1 konqueror, nvidia.com behaves as follows:

The menus are now ABOVE the input field, but when you open a menu, all text disappears.

Btw. correct layering still does not work, like on www.ghettotech.de (headings should be overlapping the text boxes)
Comment 32 Erik Hensema 2004-01-28 23:26:59 UTC
The bug still seems to be in KDE 3.2rc1. I am using tabs created with dhtml and css. Hidden tabs have "visibility: none; z-index: 1;" and visible tabs have "visibility: show; z-index: 2;". In konqueror an iframe in a tab is always on top of the other tabs as soon as the tab containing it has been selected once.

If the page loades with the tab containing the iframe hidden, the pages renderes correctly.
Comment 33 Erik Hensema 2004-01-28 23:30:53 UTC
My previous comment is not entirely accurate. The iframe which should be hidden is not hidden because the layer on top is not drawn. The area which contained the iframe gets NO redraws whatsoever.
The iframe itself is gone, it's just the residual image of it which is still on the screen ;-)
Comment 34 Arwed Starke 2004-02-12 00:09:23 UTC
nvidia.com works fine now with KDE 3.2 RPMs from Mandrake.

As the original subject, "form elements", seems to be solved (at least for me), i suggest opening a new bug for the z-index issue that can be seen on e.g.
www.ghettotech.de
www.notoriousonline.com

Anyone agrees?
Comment 35 Jason Keirstead 2004-04-22 17:57:27 UTC
This is still not resolved for iframes. The test in bug 73161 will fail still.
Comment 36 arne anka 2004-05-12 13:21:04 UTC
debian/unstable kde 3.2.2: still not resolved
Comment 37 Stephan Kulow 2004-05-19 10:41:47 UTC
Replaced engels@mercatis.de with dreisam-rd@gmx.de due to bounces by reporter
Comment 38 Maksim Orlovich 2004-06-05 15:59:05 UTC
*** Bug 82870 has been marked as a duplicate of this bug. ***
Comment 39 Maksim Orlovich 2004-06-15 17:16:35 UTC
*** Bug 83419 has been marked as a duplicate of this bug. ***
Comment 40 Maksim Orlovich 2004-06-21 14:36:18 UTC
*** Bug 83762 has been marked as a duplicate of this bug. ***
Comment 41 Maksim Orlovich 2004-06-24 19:19:22 UTC
*** Bug 83931 has been marked as a duplicate of this bug. ***
Comment 42 Justin Foell 2004-08-02 22:22:49 UTC
A very simple testcase:
http://foell.org/layer.html
Comment 43 Maksim Orlovich 2004-08-04 16:58:33 UTC
*** Bug 86545 has been marked as a duplicate of this bug. ***
Comment 44 Leo Savernik 2004-09-01 22:50:40 UTC
*** Bug 79520 has been marked as a duplicate of this bug. ***
Comment 45 Germain Garand 2004-10-15 05:47:38 UTC
CVS commit by ggarand: 


Optimize widget painting by using a shared buffer and a more efficient painting logic
(it's now 4 times faster on large surfaces).

Textareas and listviews are now stacking aware (z-order).

There's still some work to do to get correct paint events from RenderObjects overlapping
a scrollview. I'll do that soon.

CCMAIL: 31121@bugs.kde.org
									


  M +17 -0     ChangeLog   1.300
  M +28 -17    khtmlview.cpp   1.668
  M +1 -1      khtmlview.h   1.214
  M +2 -3      html/html_formimpl.cpp   1.386
  M +3 -3      rendering/render_form.cpp   1.278
  M +153 -64   rendering/render_replaced.cpp   1.174



Comment 46 George Staikos 2004-11-09 12:03:41 UTC
*** Bug 92950 has been marked as a duplicate of this bug. ***
Comment 47 Tobias Schlottke 2004-11-18 14:36:06 UTC
imho this bug is a critical thing (the iframe z-Index thing). there are a lot of projects not supporting konqueror/safari for this reason.
Comment 48 Maksim Orlovich 2005-01-05 23:57:44 UTC
*** Bug 94117 has been marked as a duplicate of this bug. ***
Comment 49 Maksim Orlovich 2005-06-08 20:23:41 UTC
*** Bug 107059 has been marked as a duplicate of this bug. ***
Comment 50 Maksim Orlovich 2005-07-08 16:15:53 UTC
Readjust to current state
Comment 51 Maksim Orlovich 2005-07-08 16:17:23 UTC
*** Bug 108757 has been marked as a duplicate of this bug. ***
Comment 52 Maksim Orlovich 2005-07-12 15:18:30 UTC
*** Bug 108973 has been marked as a duplicate of this bug. ***
Comment 53 Ferdinand Gassauer 2005-07-12 21:11:21 UTC
just want to say that the URL described in http://bugs.kde.org/show_bug.cgi?id=108973
works in safari on MAC OS X (pre Tiger)
Comment 54 rgpublic 2005-07-12 22:59:09 UTC
I can confirm that: This bug does not exist in Safari.
This fact might be important if code can be taken from there.
Otherwise sorry for the spam ;-)
Comment 55 Maksim Orlovich 2005-07-12 23:06:30 UTC
It can't be, so it's not important.
Comment 56 Thiago Macieira 2005-09-10 22:06:31 UTC
*** Bug 112386 has been marked as a duplicate of this bug. ***
Comment 57 Emanuele Tamponi 2005-09-17 19:21:38 UTC
There are some news about this bug?
Comment 58 Maksim Orlovich 2005-09-21 23:47:26 UTC
*** Bug 110651 has been marked as a duplicate of this bug. ***
Comment 59 Maksim Orlovich 2005-09-21 23:47:31 UTC
*** Bug 113032 has been marked as a duplicate of this bug. ***
Comment 60 Richard Van Den Boom 2005-10-07 14:17:29 UTC
I can confirm that this bug is still occuring in KDE 3.5 Beta 1. 
Here's a link where it occurs : http://svdboom.free.fr.

As soon as there's an <object> or an <iframe> added to the <div> using javascript, it appears on top of the steel curtain image, whatever the z-index value is.
It may be bad HTML programing to use these tags to import an html file into another one dynamically but since it's not explicitely forbidden to do so, I guess KHTML should support it. Firefox supports it well.
 
Comment 61 Maksim Orlovich 2005-10-15 22:54:34 UTC
*** Bug 114463 has been marked as a duplicate of this bug. ***
Comment 62 Maksim Orlovich 2005-10-29 23:05:19 UTC
*** Bug 115345 has been marked as a duplicate of this bug. ***
Comment 63 Thiago Macieira 2005-10-30 19:33:16 UTC
*** Bug 115388 has been marked as a duplicate of this bug. ***
Comment 64 Alain Knaff 2005-11-12 18:26:13 UTC
Just contributing another test case, observed with 3.5rc1 and earlier:

http://alain.knaff.lu/bug-reports/kde/31121/

This one has an additional twist: _two_ iframes!

The red box has z-index=100, while green has 50px, thus red should be displayed on top of green... and it is, except for the iframes contained in both boxes.

Not only is the "green" iframe displayed on top of the red background, but it is also displayed on top of the "red" iframe! (most of the time)

This behavior ("iframes later in the code always on top of iframes earlier") breaks Banque Générale's Web banking. Indeed this site uses iframes both for the menus (defined near the top of the page), and for its main view (account positions, etc.), which is defined later in the page. Result: menues go "under" the main view, and are thus unusable.

N.B. Refreshing the test example very often reveals a strange behaviour: occasionally, the stacking order of the iframes is correct ("red" iframe on top of "green"), but at the next refresh it's wrong again.

Firefox (and presumably IE) correctly display the menus on top of the main view.
Comment 65 Oded Arbel 2005-11-22 15:18:35 UTC
I've observed this behavior with current KDE 3.5. 
Another site exhibiting it is http://www.reallife.com, where the pulldown menus are obscured behind the ad's iframe
Comment 66 Thiago Macieira 2005-12-17 17:53:57 UTC
*** Bug 118476 has been marked as a duplicate of this bug. ***
Comment 67 Thiago Macieira 2006-01-19 19:46:20 UTC
*** Bug 120208 has been marked as a duplicate of this bug. ***
Comment 68 Germain Garand 2006-03-03 05:36:06 UTC
SVN commit 515212 by ggarand:

get iframes, objects and some other overlaid widgets to obey their stacking context at last
(a.k.a, keep flash and iframes *under* the friggin dhtml menus)

CCBUG: 31121


 M  +19 -0     ChangeLog  
 M  +12 -3     khtmlview.cpp  
 M  +5 -0      rendering/render_canvas.cpp  
 M  +5 -0      rendering/render_canvas.h  
 M  +54 -1     rendering/render_layer.cpp  
 M  +10 -0     rendering/render_layer.h  
 M  +45 -2     rendering/render_object.cpp  
 M  +3 -1      rendering/render_object.h  
 M  +7 -1      rendering/render_replaced.cpp  
Comment 69 Luciano Montanaro 2006-03-06 10:32:34 UTC
*** Bug 122017 has been marked as a duplicate of this bug. ***
Comment 70 Germain Garand 2006-03-07 14:26:27 UTC
SVN commit 516516 by ggarand:

- relayout/repaint fixes (really fix #121653 rather than voodoo merging)
- widget masks fixes: unbork stacking context walking and layer translation, various optimisations, 
  update widget when clearing mask.
  Now www.hdlma.co.uk is OK too. George's seatguru test site has unfortunately changed its layout at a bad time
  but problem was similar to www.bea.com - bad layer translation.
  I'll now close 31121. Oh Yes I will.

BUG: 121653
BUG: 31121



 M  +25 -0     ChangeLog  
 M  +14 -35    khtmlview.cpp  
 M  +6 -6      rendering/render_block.cpp  
 M  +7 -3      rendering/render_canvas.cpp  
 M  +23 -16    rendering/render_layer.cpp  
 M  +2 -2      rendering/render_layer.h  
 M  +39 -12    rendering/render_object.cpp  
 M  +1 -0      rendering/render_object.h  
 M  +19 -12    rendering/render_replaced.cpp  
 M  +2 -0      rendering/render_replaced.h  
Comment 71 Anders E. Andersen 2006-03-07 14:30:05 UTC
ggarand++;

:)
Comment 72 Ismail Donmez 2006-03-07 18:53:34 UTC
Germain, you rock.
Comment 73 Alain Knaff 2006-03-30 14:53:52 UTC
Still broken in 3.5.2
Comment 74 David Menday 2006-03-30 16:01:25 UTC
After reading Alain Knaff's new comment about http://alain.knaff.lu/bug-reports/kde/31121/ I tried it on a few different browsers using KDE 3.5.2 on Gentoo Linux.

Trying to describe the visual differences below, but you should really just
try it out yourself instead of reading this convoluted description of the 
differences.

On Linux:
Firefox 1.5.01:
Red div is on top of green div. The iframes are contained within the divs. Background on iframes are red and green. Red div is on top of green div covering part of both green div and iframe for frm2.txt (line 1 mainly).
No scrollbars.
Green iframe is to the side of the ' -- ' in the green div. Red iframe is below the four lines of ascii art (Test 1, Test 2) in the red div.
Internet Explorer 6 SP1 (via Crossover):
Renders it similarly. Backgrounds on iframes frm*.txt are white instead of red or green as firefoxs backgrounds are. Both of the iframes have scrollbars (possibly something with font size?). 
Konqueror 3.5.2:
Renders the iframe frm2.txt on top of iframe frm1.txt. Both iframes are on top of the both of the divs and have white backgrounds.
White backgrounds and scrollbars.
Opera 8.52:
Similar to Konqueror, the main difference is that the iframes have no scrollbars.

The width on the iframe for frm1.txt should probably be width="55" not width=55".

Comment 75 Thiago Macieira 2006-04-27 00:27:21 UTC
*** Bug 126201 has been marked as a duplicate of this bug. ***
Comment 76 Ismail Donmez 2006-11-09 19:07:54 UTC
http://www.nvidia.com/page/home.html is broken with KDE 3.5.5, menu is covered by flash. Maybe related to Flash 9 ?
Comment 77 David A Taylor 2006-11-09 21:30:14 UTC
both Flash 7 and Flash9 display the same effect.