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.

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

moving to m5

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

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.

Putting on [Perf] radar

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

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

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