software update wizard is crowded (too short) for major updates with incompatible extensions screen shot coming.

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.

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.

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.

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

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.

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

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

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.

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

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?)

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

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

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.

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