336528 - software update installation progress dialog doesn't stretch to fit contents (cut short, text is truncated)

Status: VERIFIED FIXED

(Toolkit :: Application Update, defect)

Description

[James Justin Harrell]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

When an update for Firefox has been downloaded and it is being applied, a dialog pops up with the progress of the installation. This dialog doesn't resize to fit the text in it, so the text can be cut off. (Probably also affects other programs that have updating.)

Reproducible: Didn't try

Steps to Reproduce:
1. Dialog says an update has been downloaded, asks to restart Firefox. (Automatic updates are enabled.)
2. Say not to apply it yet.
3. Dialog says update will be applied next time Firefox is started.
4. Close Firefox.
5. Change Windows display settings to use a large font (if not already).
6. Start Firefox.
7. Progress dialog comes up with chopped off text.

Actual Results:  
Progress dialog doesn't resize to fit contents, so some of the content was not visible.

Expected Results:  
Dialog resizes to show all contents.

Comment 1

[James Justin Harrell]

Attachment: dialog with truncated text

Screenshot of mentioned dialog with truncated text.

Comment 2

[Ben Turner (not reading bugmail, use the needinfo flag!)]

*** Bug 339280 has been marked as a duplicate of this bug. ***

Comment 3

[Ben Turner (not reading bugmail, use the needinfo flag!)]

*** Bug 340096 has been marked as a duplicate of this bug. ***

Comment 4

[Nick Thomas [:nthomas] (UTC+12)]

*** Bug 346959 has been marked as a duplicate of this bug. ***

Comment 5

[James Ross]

Attachment: Possible patch

A few notes:
  - This only addresses Windows. I cannot and will not be able to address any
    other OS this bug affects.
  - I've included a 5s delay in that patch for TESTING ONLY. It is not in any
    way part of the bug fix. :)
  - The patch increases the dialog's width, and height, to fit the single line
    of text. This includes moving the progress bar down if needed.

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

*** Bug 352798 has been marked as a duplicate of this bug. ***

Comment 7

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

I am amazed that non of our localizers -- especially the German ones -- have noticed this before. Assuming this is just a XUL fix, I'd like to mark it as a ridealong for a future RC if one is deemed necessary. Nominating for next triage.

Comment 8

[Ben Turner (not reading bugmail, use the needinfo flag!)]

(In reply to comment #7)
> Assuming this is just a XUL fix

No XUL here.

Comment 9

[Daniel Veditz [:dveditz]]

For people affected this makes us look really lame. Truncation depends on theme and default font and size, for me it ends "... in a few" which sounds inappropriately conversational rather than abruptly truncated. (I believe I have the default font and theme for my laptop, but obviously this looks OK to some people. I definitely do not have "large fonts" which would make this worse.)

How do we handle resizing this dialog to fit wordy languages like German?

Comment 10

[Axel Hecht [:Pike]]

Seems to me as if the patch does a resize-to-content, so wordy languages should be OK. But this is glancing at the stuff without understanding the windows APIs involved.

Would be good if someone could test this, possible scenarios:
Asian script, RTL, lengthy. ko, ar, mk sound like good candidates.

Comment 11

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: updater.exe including Silver's patch - for testing locales

Testing steps:
 1, Unpack/install build for testing
 2, Replace the existing update.exe with this attachment (virus scanned with Sophos)
 3, Start Firefox & check for updates

Expect partial updates to fail (executables always seem to change by 1 or 2 bits, so that updater.exe is in the partial; the version copied in won't match the expected CRC).

I tried updating the Fx2 2006092004 win32 en-US nightly build, after I'd set the Message Text font in the Message Box to Tahoma 12pt (instead of 8pt, Win XP Luna). The message shown by the shipped updater.exe was clipped, but it was shown in full by the patched version.

Comment 12

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: screenshots

Screenshots for original and patched updater with
 1, default and larger fontsize
 2, en-US and de locales

For en-US I used the 2006092004 nightly of the previous comment, while for de I used the 2.0b1 release build (to get an update to 2.0b2).

Note that you never get to see a scrollbar for the patched case because updater.exe fails the CRC check very early in the process.

Comment 13

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

another possible reviewer is robert strong, but seeking r= from him may get you added to his (ever growing) "people who owe me a pony" list.

Comment 14

[Mike Connor [:mconnor]]

This is not a XUL fix, its a updater.exe patch, not trivial.

This is minor, and on most systems is only briefly displayed.  Also, since the user can't actually do anything here, it doesn't really change anything substantial...

Comment 15

[Nick Thomas [:nthomas] (UTC+12)]

*** Bug 354730 has been marked as a duplicate of this bug. ***

Comment 16

[Adam Guthrie]

*** Bug 360027 has been marked as a duplicate of this bug. ***

Comment 17

[Adam Guthrie]

*** Bug 362499 has been marked as a duplicate of this bug. ***

Comment 18

[Nick Thomas [:nthomas] (UTC+12)]

*** Bug 363469 has been marked as a duplicate of this bug. ***

Comment 19

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 231739 [details] [diff] [review]
Possible patch

I'm not the right reviewer for this patch, and sounds like it should be tested more thoroughly first anyways.

Comment 20

[Ale Mand]

Any news when this could be fixed. It also involves Thunderbird trunk. I'm not filing for the time being. 
This bug is just a cosmetic glitch but still floating around since one here.

Comment 21

[Mike Connor [:mconnor]]

Seth, another for b1

Comment 22

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

Comment on attachment 231739 [details] [diff] [review]
Possible patch

Reed, what's up with the Sleep(5000)?

Perhaps Robert can review the the bulk of this patch?

Comment 23

[Reed Loden [:reed]]

(In reply to comment #22)
> (From update of attachment 231739 [details] [diff] [review])
> Reed, what's up with the Sleep(5000)?

It's Silver's patch, so ask him. I just set the r? to you. :)

Comment 24

[James Ross]

Does no-one read the bug comments these days? Hint: try comment 5, where I attached the patch. :P

Comment 25

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

Attachment: screen shot

Comment 26

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

wow, back in September, nick thomas really went to town testing this patch, see https://bugzilla.mozilla.org/attachment.cgi?id=239567

I am currently hitting this bug on my machine, and so I applied, rebuilt, and tested as well.  Things looks better, see the previous screen shot.

Alex asked if we could test:  "Asian script, RTL, lengthy. ko, ar, mk sound like good candidates."  I have not done that yet, as I don't have those languages packs on this machine.

Comment 27

[Carsten Book [:Tomcat]]

(In reply to comment #26)
> Alex asked if we could test:  "Asian script, RTL, lengthy. ko, ar, mk sound
> like good candidates."  I have not done that yet, as I don't have those
> languages packs on this machine.
> 

I tested the Patch from Nick with the 2003 -> 2004 Updates on ko, ar and mk 
(Идентификатор на градба: Mozilla/5.0 (Windows; U; Windows NT 5.2; mk; rv:1.8.1.4) Gecko/2007051502 Firefox/2.0.0.4 - 

Mozilla/5.0 (Windows; U; Windows NT 5.2; ar; rv:1.8.1.4) Gecko/2007051502 Firefox/2.0.0.4 - 

Mozilla/5.0 (Windows; U; Windows NT 5.2; ko; rv:1.8.1.4) Gecko/2007051502 Firefox/2.0.0.4)

And things looks really better with this patch. So test on this 3 locales pass here. 

Comment 28

[Robert Strong (they/them - no direct email)]

Comment on attachment 231739 [details] [diff] [review]
Possible patch

So, the setting of the text and the font during init is causing this. I believe that since we no longer support Win9k on the trunk we shouldn't have to set the font but that should be handled in a separate bug if it is the case.

>Index: progressui_win.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/toolkit/mozapps/update/src/updater/progressui_win.cpp,v
>retrieving revision 1.5
>diff -d -p --unified=6 -r1.5 progressui_win.cpp
>--- progressui_win.cpp	30 Nov 2005 02:03:35 -0000	1.5
>+++ progressui_win.cpp	2 Aug 2006 11:38:19 -0000
>...
>@@ -69,12 +89,58 @@ static void
>...
>+    if ((extra.cx > 0) || (extra.cy > 0)) {
>+      RESIZE_WINDOW(hDlg    , extra.cx, extra.cy);
>+      RESIZE_WINDOW(hWndInfo, extra.cx, extra.cy);
>+      RESIZE_WINDOW(hWndPro , extra.cx, 0       );
>+      MOVE_WINDOW  (hWndPro , 0,        extra.cy);
minor nit: align the , after the 0 in MOVE_WINDOW

Looks good!

Please don't forget to remove the 5s delay and thanks

Comment 29

[Reed Loden [:reed]]

Back to you, Silver. :)

Comment 30

[Daniel Veditz [:dveditz]]

Localization folks want this in 2.0.0.5 -- any chance it'll land soon?

Comment 31

[James Ross]

Gah, don't assign things to me. I am no longer working on Mozilla stuff, someone else will have to own this.

Comment 32

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

Attachment: patch, as checked into the trunk

Comment 33

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

fixed.

Checking in progressui_win.cpp;
/cvsroot/mozilla/toolkit/mozapps/update/src/updater/progressui_win.cpp,v  <--  p
rogressui_win.cpp
new revision: 1.6; previous revision: 1.5
done

Comment 34

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

Comment on attachment 271871 [details] [diff] [review]
patch, as checked into the trunk

addressed nits from rstrong, carrying over his review.

Comment 35

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

Comment on attachment 271871 [details] [diff] [review]
patch, as checked into the trunk

dan, I'm not sure if you want this for 1.8.1.5 or 1.8.1.6

Comment 36

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

taking, so that when it gets 1.8.1.x+ plus, it shows up that I need to land the fix from James Ross.

Thanks again James!

Comment 37

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

fixed (see comment #33)

Comment 38

[Daniel Veditz [:dveditz]]

Comment on attachment 271871 [details] [diff] [review]
patch, as checked into the trunk

approved for 1.8.1.7, a=dveditz for release-drivers

Comment 39

[Axel Hecht [:Pike]]

Seth, could you land this patch on the branch?

Comment 40

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

axel, thanks for the reminder.  I'll land it today.

Comment 41

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

> I'll land it today.

didn't get to it yet, due to some m8 work.

Comment 42

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

fixed on the MOZILLA_1_8_BRANCH.

Checking in progressui_win.cpp;
/cvsroot/mozilla/toolkit/mozapps/update/src/updater/progressui_win.cpp,v  <--  p
rogressui_win.cpp
new revision: 1.2.4.4; previous revision: 1.2.4.3
done

Comment 43

[Al Billings [:abillings - ex-MoCo]]

This is still broken in 2.0.0.8 (1.8.1.8). I just tried the original steps with the RC2 build of 2.0.0.8 on Windows XP and it reproduces.

Comment 44

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

al, you upgraded to 2.0.0.8, but from what version?

This fix landed on the branch during the 2.0.0.8 phase, so that means with 2.0.0.8 we'd have the updater.exe with the fix.

So, you wouldn't see the fix going from 2007 -> 2008, but you would from 2008 -> 2009.

The way to verify this (as there is no 2009 yet, obviously) is to try a nightly:

I just double checked, and ftp://ftp.mozilla.org/pub/firefox/nightly/2007-10-13-03-mozilla1.8 to the latest branch nightly shows the fix.

Comment 45

[Al Billings [:abillings - ex-MoCo]]

Ah, I missed that portion of how the fix would work. Thanks.

I'll mark it verified since you just looked at it.

Comment 46

[Guillermo López :willyaranda (probably SLOW response)]

Attachment: Screenshot of es-ES nightly build upgrading

Is this fixed on latest Namoroka mac build?

I'm having the same problem here. Check the screenshot.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.2b5pre) Gecko/20091127 Namoroka/3.6b5pre

Comment 47

[Robert Strong (they/them - no direct email)]

(In reply to comment #46)
> Created an attachment (id=414914) [details]
> Screenshot of es-ES nightly build upgrading
That is bug 524294