8597 - Layout hosed if XUL toolbar is too wide

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P1)

Description

[Akkana Peck]

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.*).

Comment 1

[Peter Trudelle]

This problem is not limited to Linux, is it?  reassigning to pinkerton as p3
for M8

Comment 2

[Charles Manske]

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!

Comment 3

[Mike Pinkerton (not reading bugmail)]

cc'ing hyatt and trudelle. why do i have this bug?

Comment 4

[Mike Pinkerton (not reading bugmail)]

cc'ing hyatt and trudelle. why do i have this bug?

Comment 5

[David Hyatt]

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?

Comment 6

[Eric Vaughan]

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.

Comment 7

[Charles Manske]

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.

Comment 8

[Eric Vaughan]

Matt you are the man!

Comment 9

[don]

Matt, do you have the fix ready for this one?  Should we fix it for M8 anyway?

Comment 10

[matt]

I'm testing the fix right now

Comment 11

[matt]

We are posponing this check in to M9

Comment 12

[Michael La Guardia]

updated status

Comment 13

[Eric Vaughan]

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.

Comment 14

[phillip]

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