Closed Bug 3884 Opened 21 years ago Closed 21 years ago

[PP]toolbars initially drawn at wrong size


(Core :: Layout: Form Controls, defect, P3)






(Reporter: akkzilla, Assigned: eric)


(Whiteboard: [Perf])

See bug 3855 for reference; sometime between the mornings of 3/15 and 3/16 a
change was checked in (probably to navigator.xul) which affected the width of
the toolbars.  In version 1.34, the toolbar width was changed from 160 to 155,
which caused the stop button to wrap onto another line; that's been backed out
for M3, but now the stop button is still initially drawn wrapped onto the next
line and then later shuffled back to where it belongs.  It appears that maybe
the toolbar buttons are initially drawn bigger, or with more whitespace around
them, than they will eventually be laid out.
Assignee: hyatt → evaughan
Target Milestone: M4
reassigning to evaughan as p3 for m4
Tool bar buttons are initally drawn bigger to make space to show you an empty
whiteimage while the image is bieng loaded. Once the image loader knows the size
of the image it resizes itself to the new image size. In this case the new image
size happens to be smaller. This is how HTML works in general. If we were using
HTML images instead of titled buttons the same thing might happen unless we
explicitly specified the size of the image. Unfortunately we can't do this for
titled button because we have no way to know how big they are. One fix would be
to make titled buttons come up with no image initally and then get bigger when
the size is known. But this would have the same problem. The titled button would
suddenly get bigger affecting the tool bar.
It looks unbelievably bad while it's loading (come watch on a linux box if you
haven't already seen it).  Is there any way we can pass width and height to
buttons, like we do with html inline images to improve page loading?
As an "optimization," can we pick an initial size that happens to correspond to
the size it will end up in, given the NSCP look and feel? Coincedence? I think
not! ;)
Target Milestone: M4 → M5
moving to m5
Summary: toolbars initially drawn at wrong size → [PP]toolbars initially drawn at wrong size
This got bulk-changed to read [PP] but I suspect it's actually a problem on all
platforms, though it's probably not obvious on Windows because the performance
is so much better.
does this refer to the darker grey background below the 2nd toolbar
that goes away after you mouse over a button? or is that a different bug?

said area is about 10 pixels high and appears to be a 50% grey. mousing over
any button on either bar causes the content window to grow 10 pixels vertically
and cover up this space.

this is XP on the AM builds on RedHat 5.2, MacOS 8.51, WinNT 4
No, that is different. The problem being described is how the toolbars are
constantly resizing as the images load. It looks unprofessional from the user's
Target Milestone: M5 → M7
Unfortunately this is how html images work you don't know their size until the
image loader gets them. You can place the width and height on the image but not
on titled buttons because they have text that could be above, below, right, or
left of the image. And that text could be in any font so we can not know its
size. So the only way this could be fixed is to eventually make titled buttons
hold arbitrary html. Then and image could be placed in the button and its width
and height could be set. For now its just ugly moving to another milestone.
Whiteboard: [Perf]
Putting on [Perf] radar
Target Milestone: M7 → M9
cc'ing sfraser.
Moving all Widget Set bugs, past and present, to new HTML Form Controls
component per request from karnaze.  Widget Set component will be retired
Blocks: 7251
Is it possible within the current architecture to not show the window until the
XUL has flowed?
Closed: 21 years ago
Resolution: --- → FIXED
Buttons are now only shown after they are loaded.
Seems to be!  From the apprunner improvements recently, this is really going to
teach a lesson about the software process to those who downloaded alphas and
complained about how buggy/slow it was and how XUL would never work!

XUL rocks!
verified fixed 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
No longer blocks: 7251
You need to log in before you can comment on or make changes to this bug.