349590 - software update wizard is crowded (too short) for major updates with incompatible extensions

Status: RESOLVED WONTFIX

(Toolkit :: Application Update, defect)

Description

[(not reading, please use [e-mail] instead)]

software update wizard is crowded (too short) for major updates with incompatible extensions

screen shot coming.

Comment 1

[(not reading, please use [e-mail] instead)]

Attachment: screen shot of major with extension incompatibilites

Comment 2

[(not reading, please use [e-mail] instead)]

this is mentioned in the forums, see http://forums.mozillazine.org/viewtopic.php?p=2501929#2501929

it could be helped if http://www.mozilla.com/test/sample-details.html didn't have a monster logo at the top, but the bug is still valid.

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

FWIW, I don't think that this should depend on bug 349589. Sure, the two are related, but I don't think that one needs to be fixed for this one to get resolved.

The quick n' dirty solution to this particular problem is just to make the software update wizard 100px taller for major updates. Hell, 150px. Booya.

Comment 4

[(not reading, please use [e-mail] instead)]

removing dependency, per beltzner.

I'll whip up a patch with more height and get some screen shots of this page in the wizard, and others.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Seth, any progress here? If there's a braindead simple patch for this, I'd love to get it on the triage radar for RC2, since it'd be a nice polish fix to have. Though, really, I guess it's more important for 1.5.0.8 ...

Comment 6

[(not reading, please use [e-mail] instead)]

I've got a simple fix, will attach the patch.  

I'm specifying window.height for the wizard is specified in toolkit/locales/en-US/chrome/mozapps/update/updates.dtd (where we are already specifying the window.width)

[For why I'm doing it this way, see 
http://lxr.mozilla.org/seamonkey/search?string=window.height]

I'm going with 40em (which, on my mac with my settings, is 440 px).

beard asked today what the contraints are for the content we show in the update dialog.  

With a software update dialog at 39em x 40em, the constraints for the details xul:browser are:

369px x 206px (when there are incompatible themes and/or extensions)
369px x 281px (when there are no incompatible themes and/or extensions)

For the EULA xul:browser, the constraints are:

369px x 218px

I used DOMi to determine those numbers.

Note, as we adjust window.height, the height values of the contraints will change and the xul:browser flexes.

Comment 7

[(not reading, please use [e-mail] instead)]

I have one concern, which is making the update wizard taller, to handle the "major update" and "major update + incompatible extensions warning box", makes it look worse in other scenarios.

here comes a bunch of screen shots for others to evaluate.

Comment 8

[(not reading, please use [e-mail] instead)]

Attachment: simple patch, but the devil is in deciding what to make window.height

Comment 9

[(not reading, please use [e-mail] instead)]

Attachment: eula page, after the fix

Comment 10

[(not reading, please use [e-mail] instead)]

Attachment: major update + incompat

Comment 11

[(not reading, please use [e-mail] instead)]

Attachment: downloading screen shot

Comment 12

[(not reading, please use [e-mail] instead)]

Attachment: download complete

Comment 13

[(not reading, please use [e-mail] instead)]

Attachment: major update (no incompat)

Comment 14

[(not reading, please use [e-mail] instead)]

Attachment: minor update, no details, incompat

Comment 15

[(not reading, please use [e-mail] instead)]

Attachment: minor update, no details, no incompat

Comment 16

[(not reading, please use [e-mail] instead)]

Attachment: checking screen shot

Comment 17

[(not reading, please use [e-mail] instead)]

Attachment: aus error page

Comment 18

[(not reading, please use [e-mail] instead)]

Attachment: no updates found

Comment 19

[(not reading, please use [e-mail] instead)]

Comment on attachment 240237 [details] [diff] [review]
simple patch, but the devil is in deciding what to make window.height

seeking code review from dietrich and UI review from beltzner.

once reviewed, this would be good for the backport to 1.5.0.x (where the major update is going to been seen first), and to 2.0.x (for an eventual major update)

Comment 20

[(not reading, please use [e-mail] instead)]

fyi, the existing width value comes from bug #307436 (courtesy of josh, r=mano)

Comment 21

[Dietrich Ayala (:dietrich)]

Comment on attachment 240237 [details] [diff] [review]
simple patch, but the devil is in deciding what to make window.height

Looks ok, nice minimal change. For ui-review, it might help to provide before/after shots of the problem from both Mac and Win.

Comment 22

[(not reading, please use [e-mail] instead)]

fyi:

With a software update dialog as is, the details HTML content are:

369px by 96px (when there are incompatible themes and/or extensions)
369px by 171px (when there are no incompatible themes and/or extensions)

The constraints for the EULA HTML content are: 369px by 108px

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

Not going to block the release on this, as we can make it work with the existing small space. If we need to patch it, we'll get it in before code freeze.

One more question to consider: what does it look like in locales where words are bigger (ex: french? german? japanese?)

Comment 24

[(not reading, please use [e-mail] instead)]

> One more question to consider: what does it look like in locales where words
> are bigger (ex: french? german? japanese?)

Good question.  The window width is localized in updates.dtd, so it would depend on what values were given to window.width and window.macWidth for those locales.

For french, http://lxr.mozilla.org/l10n-mozilla1.8/source/fr/toolkit/chrome/mozapps/update/updates.dtd#4, it's wider (on the mac) than it is for english (39em vs 47em)

The pixels per em will also vary with fonts.

Comment 25

[Mike Beltzner [:beltzner, not reading bugmail]]

Attachment: sample content that could fit in the small space available

Just some sample content that would fit in the smaller size.

Comment 26

[Mike Beltzner [:beltzner, not reading bugmail]]

I showed that sample content to Chris Beard and Paul Kim, and both thought that between our efforts to ensure that few users will fail the compatibility checks, and the amount of space available in the small window, we're actually OK with this size, and it's not worth making the rest of the wizard look awkward for what will really be a less frequent use case.

As such, marking this one WONTFIX.

Comment 27

[Mike Beltzner [:beltzner, not reading bugmail]]

Filed bug 354789 to address a related problem, which is that we should be showing content tailored to one of the two sizes depending on the result of the incompatibility check ...