Closed Bug 336528 Opened 15 years ago Closed 14 years ago

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

Categories

(Toolkit :: Application Update, defect)

1.8 Branch
defect
Not set
minor

Tracking

()

VERIFIED FIXED
mozilla1.9alpha7

People

(Reporter: HeroreV, Assigned: moco)

References

Details

(Keywords: polish, verified1.8.1.8)

Attachments

(6 files, 1 obsolete file)

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.
Screenshot of mentioned dialog with truncated text.
*** Bug 339280 has been marked as a duplicate of this bug. ***
*** Bug 340096 has been marked as a duplicate of this bug. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
*** Bug 346959 has been marked as a duplicate of this bug. ***
Version: unspecified → 1.5.0.x Branch
Attached patch Possible patch (obsolete) — Splinter Review
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.
Attachment #231739 - Flags: review?(mconnor)
*** Bug 352798 has been marked as a duplicate of this bug. ***
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.
Flags: blocking-firefox2?
Keywords: polish
(In reply to comment #7)
> Assuming this is just a XUL fix

No XUL here.
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?
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.
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.
Attached image 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.
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.
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...
Flags: blocking-firefox2? → blocking-firefox2-
Flags: blocking-firefox3+
*** Bug 354730 has been marked as a duplicate of this bug. ***
Summary: update installation progress dialog doesn't stretch to fit contents → software update installation progress dialog doesn't stretch to fit contents (cut short, text is truncated)
*** Bug 360027 has been marked as a duplicate of this bug. ***
*** Bug 362499 has been marked as a duplicate of this bug. ***
*** Bug 363469 has been marked as a duplicate of this bug. ***
Attachment #231739 - Flags: review?(mconnor) → review?(gavin.sharp)
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.
Attachment #231739 - Flags: review?(gavin.sharp)
Attachment #231739 - Flags: review?(sspitzer)
Attachment #231739 - Flags: review?(robert.bugzilla)
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.
Seth, another for b1
Assignee: nobody → sspitzer
Target Milestone: --- → Firefox 3 beta1
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?
Attachment #231739 - Flags: review?(sspitzer)
(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. :)
Does no-one read the bug comments these days? Hint: try comment 5, where I attached the patch. :P
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.
(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 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
Attachment #231739 - Flags: review?(robert.bugzilla) → review+
Back to you, Silver. :)
Assignee: sspitzer → silver
Localization folks want this in 2.0.0.5 -- any chance it'll land soon?
Flags: wanted1.8.1.x+
Gah, don't assign things to me. I am no longer working on Mozilla stuff, someone else will have to own this.
Assignee: silver → nobody
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
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Comment on attachment 271871 [details] [diff] [review]
patch, as checked into the trunk

addressed nits from rstrong, carrying over his review.
Attachment #271871 - Flags: review+
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
Attachment #271871 - Flags: approval1.8.1.6?
Attachment #271871 - Flags: approval1.8.1.5?
Whiteboard: [awaiting trunk verification before landing on the MOZILLA_1_8_BRANCH]
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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!
Assignee: nobody → sspitzer
Status: REOPENED → NEW
fixed (see comment #33)
Status: NEW → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Attachment #271871 - Flags: approval1.8.1.5?
Comment on attachment 271871 [details] [diff] [review]
patch, as checked into the trunk

approved for 1.8.1.7, a=dveditz for release-drivers
Attachment #271871 - Flags: approval1.8.1.7? → approval1.8.1.7+
Seth, could you land this patch on the branch?
axel, thanks for the reminder.  I'll land it today.
> I'll land it today.

didn't get to it yet, due to some m8 work.
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
Keywords: fixed1.8.1.7
Whiteboard: [awaiting trunk verification before landing on the MOZILLA_1_8_BRANCH]
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.
Version: 1.5.0.x Branch → 2.0 Branch
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.
Ah, I missed that portion of how the fix would work. Thanks.

I'll mark it verified since you just looked at it.
Status: RESOLVED → VERIFIED
Product: Firefox → Toolkit
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
(In reply to comment #46)
> Created an attachment (id=414914) [details]
> Screenshot of es-ES nightly build upgrading
That is bug 524294
You need to log in before you can comment on or make changes to this bug.