Note: There are a few cases of duplicates in user autocompletion which are being worked on.

"overflow" overrides z-index.

RESOLVED FIXED

Status

()

Core
Layout: View Rendering
P1
normal
RESOLVED FIXED
15 years ago
15 years ago

People

(Reporter: Laurent Martelli, Assigned: roc)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fix], URL)

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20021204 Debian/1.2.7-4
Build Identifier: Mozilla/5.0 Galeon/1.2.7 (X11; Linux i686; U;) Gecko/20021204 Debian/1.2.7-4

If an element A with a fixed position and z-index=1 is inside another element B
with z-index=0, A does not receive mouse events such as "onclick".

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

15 years ago
Of course it is, it is effect of "overflow: auto;" properity. If you change it
to hidden or remove it, all be as you wish. But auto there is mean visible, so
bigger area with z-index: 0 overflow lesser area with z-index: 1.

(Reporter)

Comment 2

15 years ago
Yet, I find it strange that an element with a bugger z-index is "behind" one
with a lower z-index. CSS2 specs says "Boxes with greater stack levels are
always formatted in front of boxes with lower stack levels". So there's a
contradiction somewhere.

Comment 3

15 years ago
I think this bug should be named: "z-index vs overflow: visible priority"

Comment 4

15 years ago
please reopen if you disagree.

*** This bug has been marked as a duplicate of 78087 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 5

15 years ago
Created attachment 110122 [details]
Overflow:Auto vs z-index

Sorry, I little misguided. Where is ther root of all overflow:auto bugs? I just
like to show, that overflow:auto is not working properly. Look at this testase
to see difference between Auto, Hidden and Visible. All 3 states should be
visible, because of z-index:1

Comment 6

15 years ago
Sounds like css to me. I dont know if this is a dupe or not, ian, can you take a
look?
Component: DOM Events → Style System

Comment 7

15 years ago
It is not CSS, I sure. It is bug inside overflow:auto. Please, reopen this bug
-- it have nothing with negative z-index bug.

Comment 8

15 years ago
reopening per coments.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

Comment 9

15 years ago
 Moving to layout, which really does sound more appropriate. I can confirm the
bug  on Win2k build 2002-12-20-08-trunk, OS-All. This is definately a bug
because it used to work on 7.01 build, at least on mac.
Assignee: saari → other
Status: UNCONFIRMED → NEW
Component: Style System → Layout
Ever confirmed: true
OS: Linux → All
QA Contact: vladimire → ian

Comment 10

15 years ago
Created attachment 110192 [details]
Overflow: Auto and z-index case

This testcase show, that Overflow: Auto boxes are on top of all other boxes,
even if z-index made another order.
Attachment #110122 - Attachment is obsolete: true
*** Bug 188502 has been marked as a duplicate of this bug. ***

Comment 12

15 years ago
views.
Assignee: other → roc+moz
Component: Layout → Views

Comment 13

15 years ago
resummarizing to make the problem clear
Summary: z-index not taken into account for mouse events (onclick, ...) → "overflow" overrides z-index.

Comment 14

15 years ago
Created attachment 111179 [details]
Overflow:Auto and Scroll overrided z-index

Small change of previous testcase, included overflow:scroll box.
Attachment #110192 - Attachment is obsolete: true

Comment 15

15 years ago
I think I found -- it is backfire from bug 39621. 
Priority: -- → P1
Created attachment 112571 [details] [diff] [review]
fix

The problem is that scrolling frames don't get their content parent hooked up
correctly when their view is created. This patch makes nsCSSFrameConstructor
pass the content-parent frame down into BuildScrollFrame so that the scrolling
view gets its zparent set right.
Attachment #112571 - Flags: superreview?(bzbarsky)
Attachment #112571 - Flags: review?(bzbarsky)
Whiteboard: [fix]

Comment 17

15 years ago
Comment on attachment 112571 [details] [diff] [review]
fix

we need to fix this file to not suck....
Attachment #112571 - Flags: superreview?(bzbarsky)
Attachment #112571 - Flags: superreview+
Attachment #112571 - Flags: review?(bzbarsky)
Attachment #112571 - Flags: review+
Does this patch also fix
   http://www.hixie.ch/tests/adhoc/css/box/absolute/overflow/010.html
...?
No, that testcase is not fixed.

That is a weird one...
Created attachment 113469 [details] [diff] [review]
Updating patch to trunk
Attachment #112571 - Attachment is obsolete: true
Hixie: that testcase is fixed by my patch in bug 182107.
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 15 years ago15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.