Build: 2001051504, Mac OS 9.1 To reproduce: * Migrate a Mozilla profile. * Look at the profile migration progress window. What you should see: * A window which is 280 pixels wide and 86 pixels high (excluding chrome), to match the dimensions of unexpanded progress windows in the Finder. What you actually see: * A window which is so much ridiculously smaller than that, that its contents doesn't even fit within the window.

no fair, where's that picture of what you see?

ok, found the picture http://bugzilla.mozilla.org/showattachment.cgi?attach_id=34722

The migration progess window is badly sized on Unix platforms, too. However, the expected size might be different there.

Mpt, is this bug mac-only (as the bug description says) or does it apply to all platforms? It may be hard to do something mac-only like this in a XP environment...

If you can find a standard size for progress windows on Windows, then certainly you should use it. However, that may be dependent on coming up with an animation of preferences files flying from one folder to another ...

patch removes the icon and increases the size. will post a screenshot soon

1. Don't set the width and height via CSS. Use the width= and height= instead. 2. Fix up the flexing... Looks like the majority of widgets in that box has flex="100%"...

http://www.nexgenmedia.net/profile.png Not exactly nice on the eye. Any other suggestions?

uh, the "#1" part in the title is a left over of my failed attempt to get the profile name into the title.

Well, progress windows in Mac Classic should have a margin of (AFAICT) 12 pixels around each side (though that's probably better specified as 1em). Doron, if you're looking for other ways to improve the window, perhaps you could fix all of bug 38230 all at once? The patch for this bug already fixes bug 81160, for example.

http://www.nexgenmedia.net/profile.png New patch, fixes various bugs related to the migration progress window.

I've seen a screenshot of this patch running on Linux, and it looks much better than the current UI. Anyone for review?

+ <vbox autostretch="always"> Boxes are always autostretching by default, so no need to set it explicitely. + <separator style="height:1em;"/> This is not good, it's not skinnable. Can you try with class="thin", and if that is insufficent, make a class in profile.css so themes-people can skin it. +window.dialog { + padding: 7px; } Are there other dialogs using profile.css that will be affected? You need to check so they don't are affected in a bad way by this. If they are, then make it a explicit class that your dialog can use for itself.

There should be a class="thick" (= 1em) for separating unrelated controls, alongside the class="thin" (= 0.5em) for separating related controls. If such a class doesn't exist, add it. :-) There should be no need for any window-specific CSS for this. It's just bog-standard control layout.

+ width="280px" + height="86px" Remove "px" from that. <window width=""/> takes only a number without the actual measurement. - <text id="info1" flex="100%" value="&currentlyProcessing.text;" /> - <text id="info2" flex="100%" value="&downloadBeforeUpdate.text;" /> You remove the usage but not the string from the DTD? Or is it used elsewhere? \ No newline at end of file You know what to do there. r=hwaara after those checks and changes.

woops, i had forgotten to add the .dtd changesin the previous pathc, also fixed the "px" thing. so i assume r=hwaara

Yes, r=hwaara on attachment 38600 [details] [diff] [review].

blake suggests the resize to content

-> 0.9.3

Doesn't look like this is getting fixed before the freeze tomorrow night. Pushing out a milestone. Please correct if I'm mistaken.

pushing to 1.0, as I am far away from my tree. Resize to content was causing wierd things to happen, so if blake agrees, perhaps check in for 0.9.4 the current patch and then try to get the resize to work?

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)

This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE. If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.