3884 - [PP]toolbars initially drawn at wrong size

Status: VERIFIED FIXED

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

Description

[Akkana Peck]

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.

Comment 1

[Peter Trudelle]

reassigning to evaughan as p3 for m4

Comment 2

[Eric Vaughan]

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.

Comment 3

[Akkana Peck]

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?

Comment 4

[Mike Pinkerton (not reading bugmail)]

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! ;)

Comment 5

[Peter Trudelle]

moving to m5

Comment 6

[Akkana Peck]

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.

Comment 7

[phillip]

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

Comment 8

[Mike Pinkerton (not reading bugmail)]

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
perspective.

Comment 9

[Eric Vaughan]

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.

Comment 10

[leger]

Putting on [Perf] radar

Comment 11

[Mike Pinkerton (not reading bugmail)]

cc'ing sfraser.

Comment 12

[leger]

Moving all Widget Set bugs, past and present, to new HTML Form Controls
component per request from karnaze.  Widget Set component will be retired
shortly.

Comment 13

[Matthew Tuck [:CodeMachine]]

Is it possible within the current architecture to not show the window until the
XUL has flowed?

Comment 14

[Eric Vaughan]

Buttons are now only shown after they are loaded.

Comment 15

[Matthew Tuck [:CodeMachine]]

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!

Comment 16

[phillip]

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