Closed
Bug 180502
Opened 22 years ago
Closed 22 years ago
By changing "zIndex" image is unvisible (..and "lost") - Only in Mozilla 1.2
Categories
(Core :: Web Painting, defect)
Core
Web Painting
Tracking
()
RESOLVED
FIXED
People
(Reporter: mail, Assigned: roc)
References
()
Details
(Whiteboard: [fix])
Attachments
(2 files)
970 bytes,
text/html
|
Details | |
1.80 KB,
patch
|
kmcclusk
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
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).
![]() |
||
Comment 1•22 years ago
|
||
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
Assignee | ||
Comment 3•22 years ago
|
||
I really need a reduced testcase here, this page is really complicated.
Reporter | ||
Comment 4•22 years ago
|
||
I have build a showcase, you would like to have,
and it is getting clearer.
You can find it at:
http://www.pslx.de/testcase/index.html
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.
*****************************************************
Assignee | ||
Comment 5•22 years ago
|
||
That looks much better ... it would help a lot if you could get rid of the use
of frames, though.
Reporter | ||
Comment 6•22 years ago
|
||
I have now removed frames and further reduced some content and functions.
You get at: http://www.pslx.de/testcase/index.html
index.html
(pslf-index.html before)
psljs_m.js
(Javascript-file)
3 Image-files
Assignee | ||
Comment 7•22 years ago
|
||
Looks great! I will investigate.
Reporter | ||
Comment 8•22 years ago
|
||
I think that I had not transferred the last changes of the testfiles.
If you have downloaded, please do it again.
Assignee | ||
Comment 9•22 years ago
|
||
Assignee | ||
Comment 10•22 years ago
|
||
Peter, see how I've reduced the testcase a lot more. Making it as simple as
possible is very important.
Assignee | ||
Comment 11•22 years ago
|
||
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.
Assignee | ||
Updated•22 years ago
|
Attachment #112368 -
Flags: superreview?(kin)
Attachment #112368 -
Flags: review?(kmcclusk)
Comment 12•22 years ago
|
||
Attachment #112368 -
Flags: review?(kmcclusk) → review+
Assignee | ||
Updated•22 years ago
|
Whiteboard: [fix]
Assignee | ||
Comment 13•22 years ago
|
||
*** Bug 183380 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•22 years ago
|
Attachment #112368 -
Flags: superreview?(kin) → superreview?(dbaron)
Assignee | ||
Updated•22 years ago
|
Attachment #112368 -
Flags: superreview?(dbaron) → superreview?(bzbarsky)
Attachment #112368 -
Flags: superreview?(bzbarsky) → superreview+
Assignee | ||
Comment 14•22 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 15•22 years ago
|
||
I checked in a patch to nsContainerFrame saying it was for this bug, but it was
actually for bug 190193
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•