Closed Bug 8597 Opened 26 years ago Closed 26 years ago

Layout hosed if XUL toolbar is too wide

Categories

(SeaMonkey :: UI Design, defect, P1)

All
Linux

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: akkzilla, Assigned: matt)

Details

(Whiteboard: checkin postponed from m8 to m9)

If the XUL toolbar is too wide to fit in the browser window, the content area is laid out too wide and is clipped on the right, which means among other things that the vertical scrollbar isn't drawn. For instance, running on linux with GECKO_FONT_SIZE_FACTOR=1.1 (to make the fonts big enough to read since the Unix default is wrong), the editor toolbar is too wide for the default page size by slightly more than one button, so the editor init page always comes up with no scrollbar. (I'll file a separate bug on the editor toolbar being so wide.) Layout of content should be independant of the size of the toolbars, since it may be common for toolbars to be too wide to fit with the user's chosen font size (it was certainly common in 4.*).
Assignee: trudelle → pinkerton
Target Milestone: M8
This problem is not limited to Linux, is it? reassigning to pinkerton as p3 for M8
Hardware: PC → All
No, its a general window issue. I changed platform to "all" David Hyatt says its happens because the window hierarchy is using boxes for layout. Chrome and content just boxes inside the outermost window box, so its not surprising at all. So Eric should be involved. This doesn't sound easy to solve!
cc'ing hyatt and trudelle. why do i have this bug?
cc'ing hyatt and trudelle. why do i have this bug?
Assignee: pinkerton → evaughan
Reassigning to Eric. This is a problem Eric and I have talked about before... namely that the iframe should be allowed to shrink to zero size, even though the toolbars are too wide for the window. This seems like a bug in boxes to me. Since the width is constrained to 100%, elements should be constrained to 100% if possible. I don't really see why every element in a vertical box has to be laid out with the same width, e.g., why the iframe has to be as wide as the toolbars when the toolbars are violating the constraint anyway. The toolbars can be clipped since they don't fit, but their violation of the 100% width constraint should not affect the elements that can obey the constraint. Right?
Boxes are actually doing the right thing. The solution is: One we can set the min size of the toolbar to be smaller. This will allow the window to shrink clipping the toolbar. This should be the first fix. But the real answer is to make toolbars wrap, but this is a harder problem. I'll do the first fix and then change the bug description.
Eric is right - we just need to set the XUL/CSS correctly. This works great in the editor using the following CSS: iframe#content-frame { min-width: 100px; min-height: 20px; height: 400px; } toolbox#EditorToolbars { min-width: 20px; } box#EditorStatusBar { min-width: 50px; } box#EditorProgessBox { min-width:30px; } This bug should be passed on to the appropriate owner(s) of the Browser (and mail?) windows so they can fix their CSS.
Assignee: evaughan → matt
Matt you are the man!
Matt, do you have the fix ready for this one? Should we fix it for M8 anyway?
Component: XP Toolkit/Widgets → XPApps
Priority: P3 → P1
I'm testing the fix right now
We are posponing this check in to M9
Target Milestone: M8 → M9
Status: NEW → ASSIGNED
Whiteboard: checkin postponed from m8 to m9
updated status
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Actually I already fixed this and it is checked it. Notice you can make the window smaller that the toolbar. I did this by makeing them min-width of the toolboxes 10px.
Status: RESOLVED → VERIFIED
verified on 1999-08-13-08 RedHat Linux 6.0 (GNOME/enlightenment) 1999-08-13-08 WinNT 4.0 sp5 1999-08-13-08 MacOS 8.51
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.