| Summary: | [test case] iframes, objects behave as if they had an infinite z-index (always on top) | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | Dreisam-RD <dreisam-rd> |
| Component: | khtml forms | Assignee: | Konqueror Developers <konq-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | 0de7eay2nk, artaxerxes2, Arwed_Starke, behavedave, chuck, cjacker, colesen, david, EBYKKRFHZDUK, elias, erik, gassauer, gp, gtg261s, jeremyhu, jonkde, kdebugs, kouzinopoulos, lparrab, manuelnp, Mathias.Homann, mikelima, nicolas.ternisien, oded, oss, sd, sorush.nazari, sz332, techniq35, tschlottke, wolff, yansanmo.site, yez, yodor |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Unlisted Binaries | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | test case | ||
|
Description
engels
2001-08-20 10:50:24 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
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 the other two problems are known. do you have a testcase for that margin-left problem? Testcase for the z-index bug: http://www.timohummel.com/kde-bugs/testcase-31121/ Can we have a testcase for the margin-left problem? *** Bug 56536 has been marked as a duplicate of this bug. *** 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. *** Bug 56777 has been marked as a duplicate of this bug. *** *** Bug 58840 has been marked as a duplicate of this bug. *** *** Bug 51598 has been marked as a duplicate of this bug. *** *** Bug 52869 has been marked as a duplicate of this bug. *** *** Bug 50620 has been marked as a duplicate of this bug. *** *** Bug 60300 has been marked as a duplicate of this bug. *** 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?)
*** Bug 53338 has been marked as a duplicate of this bug. *** 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? 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.
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. Jason, you know, sometimes there is a difference between how things should behave and whats technically possible. 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. Of course in my previous comment that should have said "finite" because they are infact "infinite" in behaviour. Ah I understand now. No harm no foul. *** Bug 68725 has been marked as a duplicate of this bug. *** *** Bug 70160 has been marked as a duplicate of this bug. *** 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. 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.
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
*** Bug 57194 has been marked as a duplicate of this bug. *** *** Bug 72777 has been marked as a duplicate of this bug. *** The sites listed in comment #13 are still broken with Konqueror from KDE 3.2RC1 *** Bug 73161 has been marked as a duplicate of this bug. *** 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) 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. 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 ;-) 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? This is still not resolved for iframes. The test in bug 73161 will fail still. debian/unstable kde 3.2.2: still not resolved Replaced engels@mercatis.de with dreisam-rd@gmx.de due to bounces by reporter *** Bug 82870 has been marked as a duplicate of this bug. *** *** Bug 83419 has been marked as a duplicate of this bug. *** *** Bug 83762 has been marked as a duplicate of this bug. *** *** Bug 83931 has been marked as a duplicate of this bug. *** A very simple testcase: http://foell.org/layer.html *** Bug 86545 has been marked as a duplicate of this bug. *** *** Bug 79520 has been marked as a duplicate of this bug. *** 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 *** Bug 92950 has been marked as a duplicate of this bug. *** 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. *** Bug 94117 has been marked as a duplicate of this bug. *** *** Bug 107059 has been marked as a duplicate of this bug. *** Readjust to current state *** Bug 108757 has been marked as a duplicate of this bug. *** *** Bug 108973 has been marked as a duplicate of this bug. *** 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) 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 ;-) It can't be, so it's not important. *** Bug 112386 has been marked as a duplicate of this bug. *** There are some news about this bug? *** Bug 110651 has been marked as a duplicate of this bug. *** *** Bug 113032 has been marked as a duplicate of this bug. *** 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. *** Bug 114463 has been marked as a duplicate of this bug. *** *** Bug 115345 has been marked as a duplicate of this bug. *** *** Bug 115388 has been marked as a duplicate of this bug. *** 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. 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 *** Bug 118476 has been marked as a duplicate of this bug. *** *** Bug 120208 has been marked as a duplicate of this bug. *** 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 *** Bug 122017 has been marked as a duplicate of this bug. *** 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 ggarand++; :) Germain, you rock. Still broken in 3.5.2 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". *** Bug 126201 has been marked as a duplicate of this bug. *** http://www.nvidia.com/page/home.html is broken with KDE 3.5.5, menu is covered by flash. Maybe related to Flash 9 ? both Flash 7 and Flash9 display the same effect. |