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.http://www.mei-toys.de/psl/ 2.click "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
Status: UNCONFIRMED → NEW
Component: DOM Style → Views
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
Also on 1.3 nightly build 20021130 /win.
I really need a reduced testcase here, this page is really complicated.
That looks much better ... it would help a lot if you could get rid of the use of frames, though.
Looks great! I will investigate.
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] fix 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.
Comment on attachment 112368 [details] [diff] [review] fix email@example.com
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)
16 years ago
Attachment #112368 - Flags: superreview?(bzbarsky) → superreview+
Fix checked in.
Status: NEW → RESOLVED
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.