Closed Bug 3532 Opened 26 years ago Closed 26 years ago

First time toolbar layout incorrect (buttons too big)

Categories

(Core :: Layout, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: mikepinkerton, Assigned: mikepinkerton)

References

()

Details

In viewer, look at the toolbarTest1.xul example (url provided, also a menu item). Notice that the icons on the first toolbar are stretched and are too large. Reloading the page a 2nd time fixes this. I only see this problem when a table is used w/in the first toolbar. Without the table, I'm pretty sure the buttons have the correct sizes every time. My opinion is that this is a layout or table bug, since the toolbars themselves do no layout besides calling nsBlockFrame::Reflow().
Assignee: troy → pinkerton
If we're going to look at this I need a small HTML (preferably), or an XML example
viewer has one. it's in the menus and the url above.
Assignee: pinkerton → troy
I don't think this is an xptoolkit layout bug. It's either tables or block frames.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
Running this on Windows (NT specifically), I don't see the problem you describe. What I see is is all the icons are the same size, and they all have broken images displayed. When I resize the window the sizes are exactly the same
Status: RESOLVED → REOPENED
How are you building? client.mak? If so, the icons should all be in the correct places. You can come see it on my machine if you want. Reopening bug.
Assignee: troy → pinkerton
Status: REOPENED → NEW
I'm building using nglayout.mak just like I always do. Please stop re-opening this bug. If it's a layout bug (and I believe it probably is), make up a simple HTML sample that reproduces the problem and put that in the bug...
Assignee: pinkerton → evaughan
OS: Mac System 8.5 → All
Resolution: WORKSFORME → ---
reassigning to evaughan to take a look at to rule out buttons as the cause.
clearing resolution
Ok after revisiting this bug I think I my have found the problem. It looks like it might be in some of TitledButton image loading code. Taking a look.
*** Bug 3545 has been marked as a duplicate of this bug. ***
*** Bug 3608 has been marked as a duplicate of this bug. ***
Ok Titled buttons and images inside of toolbar come up the wrong size when first loaded. And here is why. 1) Page comes up the image is not loaded yet so it defaults its size to something. For titled buttons it is 30x30px which is why the button are stretched. For regular images its 0x0 so a image in your bar doesn't show up at all the first time. 2) When the image is done loading it calls a content changed on its content node. This should cause a reflow so the image or titledbutton can get the right size. The reflow never reaches either one of them. The following XUL caused the problem. The first time you open this the image will not appear the second and subsequent times it will work fine. Notice this example has no TitledButtons in it. <?xml version="1.0"?> <?xml-stylesheet href="myxul.css" type="text/css"?> <!DOCTYPE window> <window xmlns:html="http://www.w3.org/TR/REC-html40" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" onload="Startup()"> <toolbox> <toolbar> <html:table width="100%" cellpadding=0 cellspacing=0><html:tr> <html:td> <html:img src="home.gif" /> </html:td> </html:tr></html:table> </toolbar> </toolbox> </window> If you remove tool box it will work fine. So I think toolbox for some reason is blocking the reflow.
Assignee: evaughan → pinkerton
Status: NEW → ASSIGNED
Taking over control. It appears i'm not doing incremental reflow correctly in the toolbox. cc'ing hyatt since i know he say something similiar, and he might have to fix similiar code.
accepting bug.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago26 years ago
Resolution: --- → FIXED
This was my problem all along. I wasn't being a good incremental reflow citizen and advancing the reflow command list (not like i have a clue as to why i needed to do that) in nsToolboxFrame::Reflow(). Toolbars and buttons now resize to the correct sizes when images finish loading.
Status: RESOLVED → VERIFIED
Fixed in March 23rd Build.
You need to log in before you can comment on or make changes to this bug.