By changing "zIndex" image is unvisible (..and "lost") - Only in Mozilla 1.2




16 years ago
4 months ago


(Reporter: mail, Assigned: roc)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [fix], URL)


(2 attachments)



16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021115
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021115

Until Mozila 1.2 the tabs were working fine.

2 Tabs are managed by changing the zIndex. The front tab got zIndex=1.
The background tab got the zIndex=0.

In Mozilla 1.2 the tab that got zIndex=0 is not visible any more ("lost").

I found out to fix it by using zIndex=1 and zIndex=2 (instead of 0 and 1).
But before Mozilla 1.2 it was working whitout that.
(Also in all other browsers  Mozill0.8-1.1, IE4-6, NS4-4.78)
On this site I have'nt done the possible "fix". - You can see the Problem.

(If you wonder, why the unvisible tab on the right side is clickable, - this is
another transparent gif to solve an IE4.0 Problem.)

Reproducible: Always

Steps to Reproduce:
1. "Katalog"
3.There should be 2 tabs visible, and clickable (a little bit overlapping -
changing from back to frontside).
Actual Results:  
Only one tab is visible

Expected Results:  
There should be 2 tabs visible, and clickable (a little bit overlapping -
changing from back to frontside).
Views.  Seeing this on Linux too.
Assignee: jst → roc+moz
Component: DOM Style → Views
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All

Comment 2

16 years ago
Also on 1.3 nightly build 20021130 /win.
I really need a reduced testcase here, this page is really complicated.

Comment 4

16 years ago
I have build a showcase, you would like to have,
and it is getting clearer.

You can find it at:

Two tabs are defined over a picture.
Normally you should see both tabs.
But after clicking the one who gets "z-index:0" is lost/covered,
by an EARLIER defined picture with the same z-index.

If you use zindex 1 and 2 (in the javascript-file)(instead of 0 and 1) for
"reiter1" and "reiter2",
there will be no problem.
(Also, if you move the position of the picture)

But in earlier mozilla versions and other browsers,
the later defined object covers the earlier defined,
if they have the same z-index.

In the newer mozilla version (1.2) it is the same,
until you change z-index.
The visual order of objects with the same z-index is lost.
That looks much better ... it would help a lot if you could get rid of the use
of frames, though.

Comment 6

16 years ago
I have now removed frames and further reduced some content and functions.
You get at:

(pslf-index.html before)


3 Image-files
Looks great! I will investigate.

Comment 8

16 years ago
I think that I had not transferred the last changes of the testfiles.
If you have downloaded, please do it again.
Peter, see how I've reduced the testcase a lot more. Making it as simple as
possible is very important.
Created attachment 112368 [details] [diff] [review]

The problem is that changing the z-index is causing us to lose the position of
the view in document order. Now that z-index is fully handled by sorting, we
don't really need to reorder the views. So let's stop doing that.

We probably should continue to try to reorder widgets, for maximum performance
and also correctness when plugins are present (although for plugins it's only
partial correctness because setting the widget z-index (which is what we do
today) is only approximately correct). So we unconditionally set the widget
z-index and hope.
Attachment #112368 - Flags: superreview?(kin)
Attachment #112368 - Flags: review?(kmcclusk)
Comment on attachment 112368 [details] [diff] [review]
Attachment #112368 - Flags: review?(kmcclusk) → review+
*** Bug 183380 has been marked as a duplicate of this bug. ***
Attachment #112368 - Flags: superreview?(kin) → superreview?(dbaron)
Attachment #112368 - Flags: superreview?(dbaron) → superreview?(bzbarsky)
Fix checked in.
Last Resolved: 16 years ago
Resolution: --- → FIXED
I checked in a patch to nsContainerFrame saying it was for this bug, but it was
actually for bug 190193
Component: Layout: View Rendering → Layout: Web Painting
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.