Closed
Bug 3884
Opened 26 years ago
Closed 26 years ago
[PP]toolbars initially drawn at wrong size
Categories
(Core :: Layout: Form Controls, defect, P3)
Tracking
()
VERIFIED
FIXED
M9
People
(Reporter: akkzilla, Assigned: eric)
Details
(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.
Updated•26 years ago
|
Assignee: hyatt → evaughan
Target Milestone: M4
Assignee | ||
Comment 2•26 years ago
|
||
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.
Reporter | ||
Comment 3•26 years ago
|
||
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•26 years ago
|
||
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! ;)
Updated•26 years ago
|
Target Milestone: M4 → M5
Summary: toolbars initially drawn at wrong size → [PP]toolbars initially drawn at wrong size
Reporter | ||
Comment 6•26 years ago
|
||
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
Comment 8•26 years ago
|
||
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.
Assignee | ||
Updated•26 years ago
|
Target Milestone: M5 → M7
Assignee | ||
Comment 9•26 years ago
|
||
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.
Assignee | ||
Updated•26 years ago
|
Target Milestone: M7 → M9
Comment 12•26 years ago
|
||
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•26 years ago
|
||
Is it possible within the current architecture to not show the window until the XUL has flowed?
Assignee | ||
Updated•26 years ago
|
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Comment 15•25 years ago
|
||
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•25 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•