79889 - Download progress dialog too small [clipped on right side]

Status: RESOLVED WORKSFORME

(Firefox :: File Handling, defect)

Description

[Mike Pinkerton (not reading bugmail)]

- start downloading a file, like from ftp

the download dialog is too small

Comment 1

[Mike Pinkerton (not reading bugmail)]

Attachment: [img] dialog too small

Comment 2

[Mike Pinkerton (not reading bugmail)]

more of what makes us look bad.

Comment 3

[sairuh (rarely reading bugmail)]

good companion to bug 79236. i bet this also occurs on win32 [cannot check at
the present], but not on linux...

->bill.

Comment 4

[doctor__j]

Attachment: The dialog looks fine on Win32 platform

Comment 5

[sairuh (rarely reading bugmail)]

thx for the screenshot --i couldn't repro this either using the classic theme on
win32.

shrir, has the download progress dialog ever appeared clipped for you on win32?

adding pp, but do remove if it's seen on non-mac platforms.

Comment 6

[sairuh (rarely reading bugmail)]

i now see this on linux [2001.05.17.08], with both modern and classic themes.
moreover, the checkmark for the checkbox no longer appears. will attach a
screenshot soon.

might be related to the additional regression seen in bug 79543?

Comment 7

[sairuh (rarely reading bugmail)]

Attachment: linux classic shot of dialog

Comment 8

[doctor__j]

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

Comment 9

[dales]

I am seeing this bug in Windows NT4 and in the Mac.

This morning I downloaded Build 2001052020 and it is there.  It was also in the 
20010517 (late day) build that I started this morning with.  One difference I 
have noticed on WinNT and have not confirmed on the Mac, is that if you start 
several downloads one after another but downloading concurrently, the 2nd and 
3rd "Saving File" dialogs do NOT get created too small to contain the buttons.  
Only the first dialog suffers this problem, being about the width of the title 
bar too short.

I have not down multiple concurrent downloads on the Mac, so I don't know 
whether it's the same but I suspect it will be.

Dale

Comment 10

[Bill Law]

We lost the implied "dialog=yes" feature when we switched to opening this 
dialog via nsIWindowWatcher::OpenWindow (versus nsIDOMWindow::OpenDialog).  We 
just need to add that feature in nsHelperAppDlg.js.

The same fix is needed for the helper app dialog.

Comment 11

[sairuh (rarely reading bugmail)]

bug 82563 has worsened things for this bug: at least on mac and winnt
[2001.05.24.0x comm bits] the first time the download progress dialog appears
during a session, the checkmark in the checkbox won't appear.

Comment 12

[doctor__j]

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

Comment 13

[Viswanath Ramachandran]

Ben - can you fix this in m0.9.2? thanks! Vishy

Comment 14

[Ben Goodger (use ben at mozilla dot org for email)]

Back to bill. My .9.2 list is lengthy. 

Comment 15

[Paul Chen]

nav triage team:

Reassigning to pchen

Comment 16

[doctor__j]

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

Comment 17

[Viswanath Ramachandran]

reassigning to Ben as you have most of your patches for 0.9.2 stuff ready,
making a wild guess that this takes 1 day to fix, eta 6/15. 

Comment 18

[Frank Tang]

Just want to remind you that when you fix this bug, please consider german UI 
usuaully use 150% of space than English string. So... don't hard code your size 
in xul and make sure your have enough size for german translation. The 
localization process should not touch xul file at all. 

Comment 19

[Ben Goodger (use ben at mozilla dot org for email)]

This is not a XUL issue. This dialog used to work just fine. 

Testing shows that the dialog sizes correctly the second time you launch it. 

XPToolkit issue, => trudelle for triage. 

Comment 20

[Peter Trudelle]

->evaughan, clearing target.

Comment 21

[Simon Fraser [no longer active]]

I don't think evaughan is the right owner for this. Isn't this our old friend, 
the bug about dialog sizing happening before all the images are loaded, and thus 
getting a size that is too small?

Since this is one of the bugs that cause downloading to appear completely broken, 
I think this is important to fix.

Comment 22

[sairuh (rarely reading bugmail)]

actually, this is still a problem --at least on the mac-- when i use
2001.06.07.11-branch comm bits, using the modern theme. even with subsequent
downloads.

doesn't seem to be a problem using the mac classic theme [again, testing with
subsequent downloads].

Comment 23

[sairuh (rarely reading bugmail)]

danm, would you be the right person here?

Comment 24

[andreww]

I see this bug 100% of the time on windows XP.... using today's sweetlou 
build.

Comment 25

[doctor__j]

Is this bug related to bug 85690?

Comment 26

[Simon Fraser [no longer active]]

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

Comment 27

[Andreas Premstaller]

To not lose the information from duplicate bug 85690:

I see this too small window not only on the download window, but also on 
password dialogs that come up from a protected web sites. Or should that be a
different bug?

Both happens only the first time the dialog is brought up after the start of
mozilla.

Comment 28

[gabriel]

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

Comment 29

[Dan M]

I don't think this is our old friend, asynchronous image loading throwing off the 
size of an intrinsically sized window. There aren't any images in this dialog.

Comment 30

[Simon Fraser [no longer active]]

Erm, aren't all the the buttons using images?

Comment 31

[Asa Dotzler [:asa]]

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

Comment 32

[Matthias Versen [:Matti]]

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

Comment 33

[Asa Dotzler [:asa]]

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

Comment 34

[Asa Dotzler [:asa]]

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

Comment 35

[Phil Randal]

I think Simon Fraser has hit the nail on the head - the dialog box is too short
on my PC by what appears to be the height of the buttons.

Comment 36

[Benjamin Mucci]

The download dialog seems ok under Mac with 2001062823 but I got sometime the 
same problem with the "Prompt" dialog.

Comment 37

[Matthias Versen [:Matti]]

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

Comment 38

[Henrik Lynggaard Hansen]

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

Comment 39

[Matthias Versen [:Matti]]

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

Comment 40

[sairuh (rarely reading bugmail)]

fwiw, i don't think i've run into this with my baseline testing of bug 88066
[using trunk bits]...

Comment 41

[Frank Burleigh]

I also don't see it on 2001070204 trunk win2k.  Only problem now is that the
"Launch file" button is still disabled.  Is that a separate issue?

Comment 42

[Dimitrios]

build 2001070108, Win98: Left click on a zip file link. Filepicker appears.
Click "Advanced", then click "Cancel" button on the new window. The lower part
of the parent window (main filepicker) becomes garbled ("Advanced" button almost
not visible, separator line broken, "Cancel" button produces a second image when
clicked).
But that is not the case when the linked file is a dll. I wonder why...

Comment 43

[sairuh (rarely reading bugmail)]

dimitrios, sounds like you're encountering bug 88453...

Comment 44

[Benjamin Mucci]

.

Comment 45

[sairuh (rarely reading bugmail)]

frank burleigh, what sort of file are you trying to download [an example link
would be great!].

Comment 46

[sairuh (rarely reading bugmail)]

hrm, i might've jumped the gun saying that the download progress dialog looks
fine these days [as i had mentioned in bug 88066, tests (2)]... using a mac
mozilla build from 2001.06.29.04-trunk, the dialog [at least in modern] was
clipped on the right side. oh well!

will test later on with more recent builds...

Comment 47

[gabriel]

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

Comment 48

[Frank Burleigh]

Typically the first thing I download each day is mozilla-win32-installer.exe.  I
haven't seen our friend the clipped dialog for probably a week on several win2k
and winnt machines.  The "launch file" button continues to be unavailable, though.

Comment 49

[Chris Lyon]

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

Comment 50

[Chase Tingley]

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

Comment 51

[sairuh (rarely reading bugmail)]

frank burleigh: the inability to launch an .exe file is a separate issue...
that's by design for security reasons. see bug 68279 for details.

Comment 52

[Moiz Dohadwala]

Attachment: http://www.mozilla.org/releases/ (version 0.9.2) then click on Microsoft Windows Talkback download

Comment 53

[Moiz Dohadwala]

Attachment: http://www.mozilla.org/releases/ (version 0.9.2) then click on Microsoft Windows Talkback download

Comment 54

[Moiz Dohadwala]

Hello,

I submitted an attachment ( gif image ) on 7/7/01. I am running Mozilla 0.9.2 on
Windows 2K (SP2).
The download window sizing is inconsitent. Sometimes it is too small, mostly it
is sized correctly so that the buttons are displayed without any clipping.

Hope this helps.

-Moiz

Comment 55

[Simon Fraser [no longer active]]

Some sizing/layout issues in editor dialogs were "fixed" by adding or removing 
"flex" attributes in the XUL, suggestiong that there is a XUL layout bug here. cc 
evaughan.

Comment 56

[Mike Pinkerton (not reading bugmail)]

danm isn't around, over to jag to look and see if this is an easy fix for rtm.

Comment 57

[jag (Peter Annema)]

Currently the width of the dialog is hardcoded to 36em

The easiest way to fix this is to hardcode it to 40em, that way it doesn't clip
the buttons on the Mac.

Comment 58

[Mike Pinkerton (not reading bugmail)]

why on earth are we hardcoding widths in dialogs!?

Comment 59

[Frank Burleigh]

Besides which, when it clipped for me it clipped *vertically*! ;-)

Comment 60

[Phil Randal]

Download dialogs now seem OK on the latest Windows builds here

Comment 61

[dales]

I agree that this bug no longer shows up in both NT 4.0 and Mac OS 9.1 or MacOSX
builds over the last week or so.  It's either fixed or dodged; I'm hoping it's
the former.

Dale

Comment 62

[Tuukka Tolvanen (sp3000)]

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

Comment 63

[sairuh (rarely reading bugmail)]

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

Comment 64

[dales]

I just recently discovered that this bug has morphed two different sizing
problems (bugs) into one.  There was a vertical sizing problem which I had
reported in Bug# 81853 which was marked as a duplicate of this bug on 5/20.  At
the time, I didn't look closely enough to recognize that this bug has to do wth
a HORIZONTAL sizing problem, and when the vertical problem went away, I posted
my last comments that it seemed to be fixed ... at least the vertical sizing
symptoms went away and haven't returned.

But the horizontal problem is still present in Mac OS and Mac OS X builds (but
not in WinNT 4) for the Saving File download progress window when doing an FTP
tranfer, but not when doing an http transfer from the same FTP server.  I posted
a screen shot under Bug 93708 that illustrates the problem seen.
 
            Dale

Comment 65

[Alfonso Martinez]

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

Comment 66

[Jaime Rodriguez, Jr.]

This looks like a nice to have enhancement, that is not targeted, and has not
been commented on in a long while . . . Propose we nsbranch- for this round.

Comment 67

[dales]

I was rechecking this bug under Mac OS and Mac OS X ... 

The "Saving File" progress window for an FTP download, has 4 buttons across the
bottom.  I have found that on BOTH Mac OS and Mac OS X builds from today (Build
IDs 2001091203 (0.9.4) and 2001091121 (trunk-OSX)) the width of the window IN
MODERN THEME is not enough to hold the width of the 4 buttons; in CLASSIC THEME
the window is enough.  This does not happen in Modern Theme under NT 4.

I have screenshots, but they are essentially the same as the one I had posted
last month and referenced in a comment above this.

It does now appear to be a continuing problem and is specific to the Modern Theme.

Dale
 

Comment 68

[jag (Peter Annema)]

So is anyone still seeing the vertical cutting?

Comment 69

[sairuh (rarely reading bugmail)]

i still see attachment 33798 [details] on mac os x and mac os 9.1, where the download
progress dialog isn't wide enough. how difficult would it be to fix?

Comment 70

[dales]

Re: vertical cutting

In my messege in this bug on 7/24/2001 I indicated a fix ... this was when I saw
the vertical cutting off fixed.  There has been no vertical sizing problem since
then.

However, the horizontal sizing problem remains.  As I discovered yesterday, it
is a problem only in the Modern theme at this time.  It seems like the fix has
to happen in the theme, when it's done.

Comment 71

[jag (Peter Annema)]

Attachment: Different approach that scales better I believe.

Comment 72

[jag (Peter Annema)]

hewitt: could you take a look at my patch and if you like it come up with 
something cleaner than I hacked up there?

Basically what I'm doing is creating some buffer space with that <spring/>, so 
that after the window width is determined (no more fixed width!), and the button 
text is set, there's some space up for grabs by any button that needs it 
(including the text changing from "pause" to "resume").

Comment 73

[Simon Fraser [no longer active]]

Why do we need hacks like this? Isn't there some fundamental XUL dialog sizing 
issue that needs fixing?

Comment 74

[David Hyatt]

jag, does this spring have zero width after the dialog shows (but before the
button has changed to the larger size)?  If not, then there's a bug here (in
that the spring should have given up some width to the button when the button's
width grows).  

If the spring does have zero width after the dialog shows, then the XUL fix is
correct, since you need to ensure that the dialog is wide enough to accommodate
the button, and to do so would necessarily involve ensuring the spring has some
width to give up.

Comment 75

[jag (Peter Annema)]

Yes, the spring was zero width (as much as I could determine with my eyes, all
four buttons were packed closely together). Also see the very first attachment.

Simon, this is not as much of a hack as you think, though there may be a better
way of fixing the problem than I presented. Here's the situation:

Initially, these buttons are visible:
[Cancel]      [Launch File] [Reveal Location]

The dialog sizes to something that will fit those buttons and the visible text
above them. The [Pause] button at that point is hidden, because we don't know
whether we can offer [Pause] until we know whether it's a FTP download, which we
(apparently) can't determine until way after the dialog is sized.

Now the download starts, it's determined to be an FTP download, so the [Pause]
is shown. This eats up all slack space the <spring> provided, and then some,
pushing the [Launch File] and [Reveal Location] buttons to the right, and out of
the dialog.

If there's a way for the [Pause] button to be used in the dialog's initial width
calculation, without having to resort to displaying it and then hiding it when
the download turns out to not be an FTP download (flicker!), I'd go for that
option. Disabling instead of hiding comes to mind, but I'm sure there are good
UE/UI reasons for not doing that.

Another related issue is that when you click the [Pause] button its text changes
to [Resume], so we'll be needing to add some extra slack space regardless of how
we fix the main issue here.

Comment 76

[Simon Fraser [no longer active]]

Can we do a SizeToContent() after showing the Pause button?

Comment 77

[jag (Peter Annema)]

You'll get strange visual effects where you see a dialog pop up and shortly
after grow larger horizontally. It's as much of a hack as having some extra
slack space.

Comment 78

[David Hyatt]

Yes, since we don't want to see the dialog jump in size, sizeToContent() is
right out.  

I think adding the slack is the right fix.

sr=hyatt

Comment 79

[jag (Peter Annema)]

Attachment: Just what I was looking for. Hide the button but have its width be part of the dialog's intrinsic sizing calculation

Comment 80

[jag (Peter Annema)]

Hewitt came up with that solution. I think it's a good one, something we might
even want to encourage for writing dialogs which could run into this same
problem.

Comment 81

[Joe Hewitt (gone)]

r=hewitt

Comment 82

[jag (Peter Annema)]

Per hewitt, I'll change the <spring/> I'm adding to a <spacer/>

Comment 83

[Peter Trudelle]

nsbranch+, 0.9.5

Comment 84

[David Hyatt]

sr=hyatt

Comment 85

[jag (Peter Annema)]

And checked in.

Comment 86

[John Morrison]

Er, checked in on the trunk, right? But this needs to go on the branch too, no?
Reopening for PDT approval and branch checkin.

Comment 87

[dales]

I've now verified that this bug is fixed using builds from 9/18 on both Mac OS
and Mac OS X.

Way to go ...!
 
          Dale

Comment 88

[Jaime Rodriguez, Jr.]

check it in - PDT+.

Comment 89

[gabriel]

I am seeing this also in the 'Security Window', i.e the one that pops up when
you click on the padlock icon, only in that case it is the width rather than the
height which is too small. Is that related in any way to this bug, or is that a
separate bug ?

Comment 90

[sairuh (rarely reading bugmail)]

gabriel, that's a separate issue. in fact, it might already be filed as one of
daniel's [db48x] page info bugs...

Comment 91

[Jaime Rodriguez, Jr.]

Adding correctness Status Whiteboard, correct/expected behavior does not occur.

Comment 92

[jag (Peter Annema)]

Checked into the 0.9.4 branch.

Comment 93

[sairuh (rarely reading bugmail)]

yay!

vrfy fixed using comm *branch* bits from 2001.09.25.xx on linux, winnt, mac os
9.1 and os 10.0.4.

Comment 94

[sairuh (rarely reading bugmail)]

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

Comment 95

[sairuh (rarely reading bugmail)]

ack, when using the *classic* theme on only Mac 10.x and 9x, i'm still seeing
clipping on the right side: the rightmost button is fine, but the "100%" is
clipped. tested using 2001.10.03.0x-branch bits --this appears when the download
has finished.

screenshots coming up.

reopening --however, pls do let me know if what i'm now seeing is a *different*
issue altogether!

Comment 96

[sairuh (rarely reading bugmail)]

Attachment: classic theme on Mac 10.0.4, branch

Comment 97

[sairuh (rarely reading bugmail)]

Attachment: classic theme on Mac 9.1, branch

Comment 98

[sairuh (rarely reading bugmail)]

also a problem with recent trunk bits on mac os 10.0.4 and mac os 9.1. again,
only a problem with the classic theme.

Comment 99

[jag (Peter Annema)]

-> 0.9.7

Comment 100

[sairuh (rarely reading bugmail)]

spam: over to File Handling. i have not changed the assigned developer [or the
other fields for that matter], so if anyone realizes that a bug should have a
more appropriate owner, go ahead and change it. :)

Comment 101

[Warner Young]

I also see the "100%" clipped when the download is finished, on Win98 builds.

Comment 102

[Dimitrios]

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

Comment 103

[sairuh (rarely reading bugmail)]

have been seeing this more often...wonder why it has regressed...

Comment 104

[jag (Peter Annema)]

-> future

Comment 105

[Jaime Rodriguez, Jr.]

hmmmmmm ... this was PDT+, nsbrnach+, and it seems that people have been
encountering it more often than before ... so, why are we gonna future this one,
when many folks before thought it was important to fix this one.

Comment 106

[jag (Peter Annema)]

That's rather simple. The original bug, where (parts of) buttons were missing
(outside the window boundaries) was fixed a while back. It was reopened recently
because part of the percentage done number is now missing, which, though a
visual glitch, I don't think is as important. It has nsbeta1, so if it gets
plussed I'll pull it back.

Comment 107

[Andreas Premstaller]

Attachment: Patch to correct the 100% cut-off

Here is the patch to correct the cut-off of the progress percentage. Tested on
W2K against build 2002020208.

The reason for the problem is that in nsProgressDlg.xul a grid with 2 columns
is defined, but the row containing the progressmeter has three elements.
Changing the second hbox to contain the progressmeter and the progress-text
solves the problem (and yields a little bit more horizontal space for filename
and destination).

jag, would you please review the patch?

Comment 108

[jag (Peter Annema)]

Won't this cause the progress bar's size to shrink as the "percent done" text grows?

Comment 109

[Andreas Premstaller]

Yes, it will, but this has been happening all along. 

Comment 110

[jag (Peter Annema)]

I thought the % done was pushed out the window because of the inflexibility of
the progress bar, where it starts like:

          |
 _______ %|
          |

and ends with:

          |
 ======= 1|
          |

I could be wrong though.

Regardless, I think this should be fixed in such a way that the progress bar
doesn't shrink when the size of the percent done text grows.

One hack is to put "100 %" in a <deck> behind the label that displays the real
percent, or we simply put a style="width:5em;" on it

Comment 111

[Andreas Premstaller]

I am pretty sure my analysis of the problem is not completely of. If you watch
carefully, you will see that presently the "saving from" and "to" field shrink
as percentage goes from 9 to 10% and from 99 to 100%, leaving a bigger free
space at their right.

I attach a second patch that assigns a fixed width of 3em to the percentage
text. This is tested on W2K and Linux with build 2002020208 and 2002020508,
respectively, both using Classic and Modern, and the progressbar does not shrink
any more. With a width of 2.5em, the progressbar shrinks slightly using Modern
on Linux when percentage jumps from 99 to 100%.

Comment 112

[Andreas Premstaller]

Attachment: Improved patch that corrects the 100% cut-off and keeps the progressbar from shrinking.

Comment 113

[Simon Fraser [no longer active]]

Someone should evaluate that patch with respect to how much redrawing of the 
download window occurs whenever the amount changes (hint: paint flashing or 
reflow counts). I've seen the download dialog flash like crazy with double 
buffering off, which is bound to slow refresh (and hence download speed) a bit.

Comment 114

[Andreas Premstaller]

sfraser, does your comment apply to the patch in attachment 67937 [details] [diff] [review]?
I don't really see how it would change the reflows compared to before, since it
just changes the grouping of the elements but otherwise keeps them the same.

Is there some documentation available on how to use the paint flashing and
reflow counts in the debug menu, turning them on and off does not have any
effect for me (on Linux, with js console open and calling mozilla from the
terminal). 

Comment 115

[jag (Peter Annema)]

smfr: by specifying the width to 3em, we should be cutting down on the number of
reflows caused by updating the percent done text, I would think.

Comment 116

[Matthias Versen [:Matti]]

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

Comment 117

[jag (Peter Annema)]

I'll see tomorrow what this looks like on Mac (which uses a larger font iirc).

Comment 118

[Andreas Premstaller]

Peter, did you have time to check this on Mac?

Btw, bug 124203 describes the same problem with the same underlying code in the
print progress dialog.

Comment 119

[jag (Peter Annema)]

Hmmm, I don't seem to be able to reproduce the problem on my Mac (without your
patch) but it certainly looks like the right thing to do, so sr=jag. I would
suggest 4em though, instead of 3em (4 chars in "100%").

Comment 120

[Peter Trudelle]

nsbeta1+ per ADT triage team, ->1.0

Comment 121

[Blake Ross]

The new progress dialog code and FE is in.  pink/others, are you still able to
reproduce?

Comment 122

[Patrick]

build 2002022203 on xp : all buttons now fit the window!

Although imho the window behaves kinda strange: the window changes size when
download completes. 

Now i truly know nothing about the underlying code but i thought when changing
from "d/l" to "d/l complete" the window size does not need changing, but only
the LAUNCH FILE and SHOW FILE LOCATION need to be changed to ACTIVE

Comment 123

[sairuh (rarely reading bugmail)]

using 2002.02.25.0x comm bits, i can reproduce this only in one setup [so far],
and that's on win2k using the modern theme: the "show file location" button is
clipped on the right side.

on linux rh7.2 and mac 10.1.3 in both themes this is fine, as well as with the
classic theme on win2k.

Comment 124

[Patrick]

indeed it's only happens for the MODERN theme. Seen it in several builds, most
recently in 2002022503.

Upon d/l complete the window stretches a bit to the right.

Comment 125

[jag (Peter Annema)]

-> law

Comment 126

[dales]

I confirm the observation that the download window stretches toward the right at
the transition to "Download complete" ... this on Windows NT4 (SP6a) in Classic
Theme.  I have occasionally seen instances when it didn't happen ... two
downloads in progress at the same time ... one window stratched and the other
didn't.  I haven't identified the factor(s) related to this differential bahavior.

I do not see any clipped buttons and the percent complete figures remain fully
within the window.  These observations limited to Classic Theme.

Dale

Comment 127

[sairuh (rarely reading bugmail)]

...and i found another case where this occurs: ftp download progress dlg on
linux using either theme. it's wider due to the additional pause/resume button.

Comment 128

[Andreas Premstaller]

Attachment: Issue with classic on W2K

This picture shows the download dialog window during (top) and after (bottom)
download (as observed by Patrick, dales, I guess). When the download is
complete, the text in the status line changes to a longer one, and is widening
up all other fields in the same column in the grid so the text can squeeze into
one line, and thus increases the width of the window.

The underlying problem is, IMHO, still the same: a grid is defined in
nsProgressDialog.xul with 2 columns, but the Progress line has 3 distinct
horizontal elements. The last horizontal element, the label, is defined with a
constant width so the text "100%" will remain in the window, and thus the
middle element has to grow and increases the size of the window.

Comment 129

[Andreas Premstaller]

Attachment: Patch that inhibits the horizontal growing of the download window.

This patch puts the progressbar and the percentage-label into one hbox, so that
the grid as defined earlier in the file nsProgressDialog.xul is respected. The
effect is that all the upper elements in the second column, and especially the
textboxes, have more horizontal space and the change in the status line text
does not affect window width any more. 

A second possible approach was taken in bug 124203, where a third column in the
grid is defined. However, it may be difficult to calculate in advance the final
length of the text for the middle column in the progress dialog. 

Moreover, this patch makes better use of the available space in the progress
dialog, avoiding the large empty block on the right of the dialog that is just
filled by the percentage-line.

Comment 130

[Andreas Premstaller]

Attachment: Download dialog window after applying the patch (during/after download)

Comment 131

[Bill Law]

Thanks for the patch, Andreas.  I think this will also permit us to remove the
"sizeToContent" call in nsProgressDialog.js.

Comment 132

[sairuh (rarely reading bugmail)]

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

Comment 133

[sairuh (rarely reading bugmail)]

i think i might have a good test case for this --see bug 130132 for details.

questions for those who see this:

* when you see this clipping, is the Launch File button also disabled?
* are you able to reproduce it using the recipe in bug 130132 (basically going
thru the helper app in a very fast manner)?

Comment 134

[Warner Young]

Sairuh, I'm still seeing this problem in some cases.  Build 2002031103, Win98,
Modern theme.  The Launch File button is disabled, and the Show File Location
button is clipped.  I'm downloading from McAfee's site, which is an
automatically triggered download.  I don't know if that qualifies for the "fast
helper-app" recipe.

When I trigger the download myself (for other files), nothing is clipped, but
the Download Dialog resizes itself when complete, which I find very disconcerting.

Comment 135

[Shark Daddy (Jonathan L.)]

Attachment: Like this in Modern on Windows

I just got Win2000, getting rid of Win98. In both cases, when a download
completes it looks like this (always). This is only the case in Modern and has
been the case for a while.

Comment 136

[Bill Law]

Attachment: Patch to .xul and removal of unnecessary sizeToContent() call

I removed the sizeToContent call from the .js file.  I'd like new r= and sr=.

Comment 137

[dales]

Since Download manager has been added, the dialogs that are the object of this
bug have become the Property dialogs under Download manager and they are
seriously regressed ... much more narrowed than ever before.

I'm putting the note here because I think it may be the same bug showing in a
somewhat different environment.

Dale

Comment 138

[Anthony Jenkins]

Attachment: The top image is dialog shown directly, the bottom two are progress / completed.

(Build 20020404)
The save dialog appears to be too small only when the progress bar is shown
first (Win98SE, 800x600 laptop, Trident Cyberblade graphics chipset). 
Apparently the dialog does not resize after switching from the progress dialog,
which shorts it by ~40 pixels.	If the dialog is shown directly (ie, the
download has completed before the dialog is shown), then it is displayed
correctly.

Comment 139

[Patrick]

note that attachement from comment 138 still shows the stretching of the d/l
window in some cases when a d/l completes

Comment 140

[jsp]

The attachments to comment 138 demonstrate something that I've noticed: the
Launch button is never enabled if the dialog is displayed while the download is
in progress. If the dialog is not displayed until the download is complete
(because it took you longer to specify where the file was going than it did to
download it), the Launch button is enabled properly.

Comment 141

[Peter Trudelle]

I'm not seeing this using today's build on Win2K, modern theme. QAWanted:
Sairuh, what defect is reproducible here, and what is the impact on typical users?

Comment 142

[R.K.Aa.]

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

Comment 143

[José Jeria]

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

Comment 144

[timeless]

I had this problem with LittleMozilla (when it last was a compatible skin)

Comment 145

[Peter Trudelle]

Okay, I see it now, but only after the download completes, when I check the
'keep this window open' checkbox.  

Comment 146

[Peter Trudelle]

Mass moving nsbeta1+/adt3 bugs assigned to Navigator team engineers out to
target milestone 1.0.1.  Please confine your attentions to driving down our list
of TM 1.0 bugs for beta.  Better to help, debug, or test one of them than fix
one of these.

Comment 147

[sairuh (rarely reading bugmail)]

whoops, this fell off my radar for a bit --sorry for the delay.

i don't see this all the time. difficult to judge how much this impacts typical
users, but it certainly hasn't completely disappeared. (and, understandably
annoying when it does occur.)

my comment 133 might lend more info here. as well as, perhaps, comment 127 and
comment 123.

Comment 148

[Peter Trudelle]

Since the DL mgr will open by default, and you'll need to open properties and
then click on 'keep window open' to see this, and even then it is just cosmetic,
I think it should be nsbeta1-, but in any case it will be minussed by ADT on Monday.

Comment 149

[Mike Pinkerton (not reading bugmail)]

i'm running branch builds and i've yet to see the d/l manager. it does _not_
come up by default.

Comment 150

[Peter Trudelle]

No, but there is another bug on that, that should make beta.

Comment 151

[John Levon]

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

Comment 152

[Vadim Berezniker]

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

Comment 153

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 154

[scottputterman]

Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email [e-mail].  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.

Comment 155

[Steve Etheredge]

This bug is present in the Win32 platform.
This bug only occurs after the download is 100% complete and you have the option
of keeping the window open after the download is complete selected.

Comment 156

[Francisco Areas Guimaraes]

i´m using win2000 and mozilla 2002051006(1.0rc2), and the dialog shows fine

Comment 157

[Francisco Areas Guimaraes]

Attachment: buttons go to the right when download is complete(win2k, 2002051006)

while the download is incomplete the dialog looks fine(top image), but when it
reaches 100%, the buttons change place and the end of the "show file location"
button goes off the dialog(bottom image). I´m using win2000 and mozilla 1.0 rc2
(2002051006)

Comment 158

[WD]

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

Comment 159

[Matthias Versen [:Matti]]

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

Comment 160

[Michael Lefevre]

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

Comment 161

[sairuh (rarely reading bugmail)]

[re]nominating...for buffy.

Comment 162

[Michael Lefevre]

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

Comment 163

[Michael Lefevre]

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

Comment 164

[Michael Lefevre]

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

Comment 165

[Jim Garrison]

Appears to be fixed in 1.1b (2002072104) on Win2K

Comment 166

[Michael Lefevre]

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

Comment 167

[Samir Gehani]

Nav triage team: nsbeta1+/adt3

Comment 168

[Samir Gehani]

Over to Jan.

Comment 169

[sairuh (rarely reading bugmail)]

chrisp, are you able to reproduce this?

Comment 170

[jsp]

WFM on Win2000 with Mozilla 1.2.1, classic and orbit 3+1 themes.

Comment 171

[Chris Petersen]

Using the 2003-02-17-03 Mach-0 build with classic or modern skin, I 'm not able
to reproduce this issue. Download dialog displays correctly without cropped
text. Tested under 10.2.3.

Comment 172

[Samir Gehani]

Nav triage team: nsbeta1-

Comment 173

[Shaohua Wen]

Attachment: screenshot on firebird localized,winxp.

Firebird also has this problem on windows.
Is it caused by this?

Comment 174

[Peter Kroll]

Attachment: this bug still happens in Moz 1.4

I've uploaded an image which shows the dialog is too small when the description
of the file being downloaded at the top is long.
Mozilla 1.4

Comment 175

[Torben]

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

Comment 176

[Jim Garrison]

Attachment: Still happening in 1.6

Still happening in 1.6...

Comment 177

[Lawrence]

This does not happen in Mozilla 1.6 ~ the current 1.7 RC1

Comment 178

[Leonardo Morelli]

Attachment: example of File Bookmark dialog with incorrect size

getting this on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6)
Gecko/20050111, several windows, including File Bookmark. Personal toolbar also
doesn't show an arrow for more items that fit on it until I resize the window.

Comment 179

[Joachim Noreiko]

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

Comment 180

[OstGote!]

see also Bug 280909 and Bug 234859

Comment 181

[Jan Varga [:janv]]

I don't think this is an issue anymore.