Closed
Bug 35503
Opened 24 years ago
Closed 24 years ago
Menus don't draw when using overflow:auto internally
Categories
(Core :: Layout, defect, P3)
Core
Layout
Tracking
()
VERIFIED
WORKSFORME
M16
People
(Reporter: mikepinkerton, Assigned: saari)
References
Details
(Whiteboard: [nsbeta2+])
In xul.css, make sure the css rules for menupopup/popup are as follows: menupopup { behavior: url("resource:/chrome/xulBindings.xml#popups"); display: none; } popup { behavior: url("resource:/chrome/xulBindings.xml#popups"); display: none; } then in xulBindings.xml, make the XBL impl for popups be a box with overflow set: <binding name="popups"> <content> <xul:box class="internal-box" orient="vertical" flex="1" style= "overflow:auto;"> <children/> </xul:box> </content> </binding> Now notice that menus or popups on the personal toolbar no longer draw correctly. evaughan and hyatt think this has to do with the fact that overflow:auto creates extra subviews (to handle scrolling) that don't play nicely with the floating view in the popup.
Reporter | ||
Comment 2•24 years ago
|
||
marking as a blocker, need this for my feature which is committed to for m16.
Comment 3•24 years ago
|
||
I dumped the location of the text frames in nsContainerFrame::PaintChild ... aRenderingContext.Translate(-kidRect.x, -kidRect.y); printf("Kid Rect position %d %d \n", kidRect.x, kidRect.y); ... When the menu popup's are displayed and overflow is set to clip the text frame's have the correct position. When overflow is set to auto the text frame's are set to 0,0. Since the frames have the wrong translation, either they must not be getting reflowed, or they are being reflowed to 0,0. I also tried adding a hover rule for a menu item which expanded its font-size to force a reflow. This did NOT fix the layout of the menuitems in the dropdown. Changing component to layout. Reassigning to Eric, and CC'ing troy since overflow:auto does not reflow the frames correctly within popup's.
Assignee: kmcclusk → evaughan
Component: Views → Layout
Comment 4•24 years ago
|
||
This is blocking one of our features, need an owner who can work on it immediately, and an estimated landing date. Is this really Mac-specific?
Whiteboard: NEED UPDATE NOW!!
Comment 5•24 years ago
|
||
This is not Mac specific. I was able to get it to fail on WINNT. Changing platform to ALL.
OS: Mac System 9.0 → All
Hardware: Macintosh → All
Comment 6•24 years ago
|
||
Work complete testing on multiple platforms.
Status: NEW → ASSIGNED
Whiteboard: NEED UPDATE NOW!! → 5/8/2000
Comment 8•24 years ago
|
||
Scrolling menus now work on both window and linux. But its problematic on mac. Saari is looking at it.
Assignee: evaughan → saari
Status: ASSIGNED → NEW
Assignee | ||
Comment 10•24 years ago
|
||
it looks like whatever problems we were having with scrolling menus on MacOS were fixed in the last week, probably by pinkerton. They work fine for me now. WORKSFORME unless I'm missing something...
Status: NEW → ASSIGNED
Assignee | ||
Comment 11•24 years ago
|
||
marking worksforme
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Comment 12•24 years ago
|
||
Mike, I'm not seeing a problem with the May 30th build. All items on the personal tool bar appear current (including the bookmarks pop-menu). Is there something I'm missing here ?
Reporter | ||
Comment 13•24 years ago
|
||
Chris, i think this is ok now, and all problems are covered in separate bugs.
You need to log in
before you can comment on or make changes to this bug.
Description
•