81159 - Profile migration progress window should be 280*86 pixels

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Profile: Migration, defect)

Description

[Matthew T (active 1999-2002)]

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.

Comment 1

[timeless]

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

Comment 2

[timeless]

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

Comment 3

[Henri Sivonen (:hsivonen)]

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

Comment 4

[Håkan Waara]

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

Comment 5

[Matthew T (active 1999-2002)]

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

Comment 6

[Doron Rosenberg (IBM)]

Attachment: proposed patch

Comment 7

[Doron Rosenberg (IBM)]

patch removes the icon and increases the size.

will post a screenshot soon

Comment 8

[Håkan Waara]

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%"...

Comment 9

[Doron Rosenberg (IBM)]

http://www.nexgenmedia.net/profile.png

Not exactly nice on the eye. Any other suggestions?

Comment 10

[Doron Rosenberg (IBM)]

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

Comment 11

[Matthew T (active 1999-2002)]

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.

Comment 12

[Doron Rosenberg (IBM)]

Attachment: new patch

Comment 13

[Doron Rosenberg (IBM)]

http://www.nexgenmedia.net/profile.png

New patch, fixes various bugs related to the migration progress window.

Comment 14

[Matthew T (active 1999-2002)]

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

Comment 15

[Håkan Waara]

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

Comment 16

[Matthew T (active 1999-2002)]

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.

Comment 17

[Doron Rosenberg (IBM)]

Attachment: new patch

Comment 18

[Håkan Waara]

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

Comment 19

[Doron Rosenberg (IBM)]

Attachment: newer patch

Comment 20

[Doron Rosenberg (IBM)]

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

Comment 21

[Håkan Waara]

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

Comment 22

[Doron Rosenberg (IBM)]

blake suggests the resize to content

Comment 23

[Doron Rosenberg (IBM)]

-> 0.9.3

Comment 24

[Blake Ross]

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

Comment 25

[Doron Rosenberg (IBM)]

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?

Comment 26

[Asa Dotzler [:asa]]

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)

Comment 27

[Benjamin Smedberg]

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.