Closed
Bug 180921
Opened 22 years ago
Closed 22 years ago
z-index ignored on hidden IFRAME
Categories
(Core :: Web Painting, defect)
Core
Web Painting
Tracking
()
RESOLVED
FIXED
People
(Reporter: sdelmont, Assigned: roc)
References
()
Details
(Whiteboard: [fix])
Attachments
(1 file)
2.68 KB,
patch
|
john
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021105 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021105 The z-index CSS attribute can be used to display some elements on top of an IFRAME, and that works fine. But if the IFRAME is initially hidden and displayed afterwards, then it overlaps any other object, regardless of z-index value. Reproducible: Always Steps to Reproduce: 1. Visit http://www.zonageek.com/tmp/iframebug.html 2. Click on "Display Hidden DIV" Actual Results: The "hidden" DIV (that was initially hidden and later displayed when the link was clicked) contains an IFRAME, and while the DIV is "below" the overlapping yellow DIV, the IFRAME is displayed above it. The blue DIV on the left has exactly the same HTML and CSS attributes, and it is displayed correctly. The only difference is that the one on the left is displayed initially. Expected Results: Display the IFRAME "under" the yellow DIV, just like the blue DIV on the left. Mozilla 1.2b on Mac OS X (Gecko/20021015) shows the same incorrect behaviour.
Comment 1•22 years ago
|
||
seeing this on Linux too. At a guess, the widget and view orders are out of sync....
Assignee: frame → roc+moz
Status: UNCONFIRMED → NEW
Component: Layout: HTML Frames → Views
Ever confirmed: true
OS: Windows 2000 → All
QA Contact: amar → ian
Hardware: PC → All
Reporter | ||
Comment 2•22 years ago
|
||
The problem only happens when the element is hidden using "display: none". Hiding with "z-index: -1" or with "visibility: hidden" work fine.
Assignee | ||
Comment 3•22 years ago
|
||
The problem here is just that the new IFRAME wasn't being hooked up to the tree of view managers. This is because for the new IFRAME, nsDocumentViewer was using Show() instead of MakeWindow(). Show() seems to contain what was originally a copy of MakeWindow(), although MakeWindow() got the view manager tree hookup added and Show() didn't. I fixed this by making Show just call MakeWindow instead of duplicating most of its code. My only question is why Show() was duplicating all that code in the first place...
Assignee | ||
Updated•22 years ago
|
Attachment #112004 -
Flags: superreview?(bzbarsky)
Attachment #112004 -
Flags: review?(jkeiser)
Assignee | ||
Comment 4•22 years ago
|
||
BTW there is one difference in Show() vs MakeWindow(): the former uses mDeviceContext to initialize the view manager, the latter uses the device context from the mPresContext. I believe that the latter is always correct.
Updated•22 years ago
|
Attachment #112004 -
Flags: review?(jkeiser) → review+
Assignee | ||
Comment 5•22 years ago
|
||
Comment on attachment 112004 [details] [diff] [review] fix changing sr request to jst, who knows this code well and who may know why this code wasn't merged in the first place :-)
Attachment #112004 -
Flags: superreview?(bzbarsky) → superreview?(jst)
Comment 6•22 years ago
|
||
Comment on attachment 112004 [details] [diff] [review] fix Heh, well, I don't think there's anyone alive that knows this code well, but I've made my own mess here, so I guess I kinda know what's going on (oh how I wish someone had the time to clean this mess up). Anyways, looks good to me, sr=jst
Attachment #112004 -
Flags: superreview?(jst) → superreview+
Assignee | ||
Updated•22 years ago
|
Whiteboard: [fix]
Assignee | ||
Comment 7•22 years ago
|
||
Fix checked in
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
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
•