Download progress dialog too small [clipped on right side]




18 years ago
5 months ago


(Reporter: mikepinkerton, Assigned: janv)


({helpwanted, polish, regression})

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [se-radar])


(17 attachments, 5 obsolete attachments)

27.88 KB, image/jpeg
25.68 KB, image/gif
22.37 KB, image/jpeg
19.36 KB, image/gif
19.36 KB, image/gif
16.64 KB, image/png
5.01 KB, image/png
17.83 KB, image/png
18.59 KB, image/png
7.60 KB, image/png
1.88 KB, patch
Details | Diff | Splinter Review
17.23 KB, image/png
11.28 KB, image/png
24.76 KB, image/jpeg
36.15 KB, image/pjpeg
15.49 KB, image/gif
4.45 KB, image/png
- start downloading a file, like from ftp

the download dialog is too small
Created attachment 33798 [details]
[img] dialog too small
more of what makes us look bad.
Keywords: nsbeta1, nsmac2, polish, regression
good companion to bug 79236. i bet this also occurs on win32 [cannot check at
the present], but not on linux...

Assignee: blakeross → law
Blocks: 78106

Comment 4

18 years ago
Created attachment 33835 [details]
The dialog looks fine on Win32 platform
thx for the screenshot --i couldn't repro this either using the classic theme on

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.
Keywords: pp


18 years ago
Keywords: nsbeta1 → nsbeta1+
Target Milestone: --- → mozilla0.9.2
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?
OS: Mac System 9.x → All
Hardware: Macintosh → All
Created attachment 34997 [details]
linux classic shot of dialog

Comment 8

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

Comment 9

18 years ago
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.


Comment 10

18 years ago
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.
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

18 years ago
*** Bug 82746 has been marked as a duplicate of this bug. ***
Ben - can you fix this in m0.9.2? thanks! Vishy
Assignee: law → ben
Priority: -- → P3
Back to bill. My .9.2 list is lengthy. 
Assignee: ben → law

Comment 15

18 years ago
nav triage team:

Reassigning to pchen
Assignee: law → pchen

Comment 16

18 years ago
*** Bug 83491 has been marked as a duplicate of this bug. ***
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. 
Assignee: pchen → ben
Whiteboard: 1 day, eta 6/15.

Comment 18

18 years ago
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. 
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. 
Assignee: ben → trudelle

Comment 20

18 years ago
->evaughan, clearing target.
Assignee: trudelle → evaughan
Target Milestone: mozilla0.9.2 → ---

Comment 21

18 years ago
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.
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

doesn't seem to be a problem using the mac classic theme [again, testing with
subsequent downloads].
Keywords: pp → mozilla0.9.2
danm, would you be the right person here?
Assignee: evaughan → danm

Comment 24

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

Comment 25

18 years ago
Is this bug related to bug 85690?

Comment 26

18 years ago
*** Bug 85690 has been marked as a duplicate of this bug. ***
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

Comment 28

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

Comment 29

18 years ago
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

18 years ago
Erm, aren't all the the buttons using images?
*** Bug 85664 has been marked as a duplicate of this bug. ***
*** Bug 87064 has been marked as a duplicate of this bug. ***


18 years ago
Keywords: mostfreq
*** Bug 87760 has been marked as a duplicate of this bug. ***


18 years ago
Keywords: nsBranch
*** Bug 88037 has been marked as a duplicate of this bug. ***

Comment 35

18 years ago
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

18 years ago
The download dialog seems ok under Mac with 2001062823 but I got sometime the 
same problem with the "Prompt" dialog.
*** Bug 88601 has been marked as a duplicate of this bug. ***
*** Bug 83924 has been marked as a duplicate of this bug. ***
*** Bug 88763 has been marked as a duplicate of this bug. ***


18 years ago
Keywords: mozilla0.9.3
fwiw, i don't think i've run into this with my baseline testing of bug 88066
[using trunk bits]...

Comment 41

18 years ago
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

18 years ago
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
But that is not the case when the linked file is a dll. I wonder why...
dimitrios, sounds like you're encountering bug 88453...

Comment 44

18 years ago
frank burleigh, what sort of file are you trying to download [an example link
would be great!].
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

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

Comment 48

18 years ago
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

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

Comment 50

18 years ago
*** Bug 89406 has been marked as a duplicate of this bug. ***
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

18 years ago
Created attachment 41548 [details] (version 0.9.2) then click on Microsoft Windows Talkback download

Comment 53

18 years ago
Created attachment 41547 [details] (version 0.9.2) then click on Microsoft Windows Talkback download

Comment 54

18 years ago

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.


Comment 55

18 years ago
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 
danm isn't around, over to jag to look and see if this is an easy fix for rtm.
Assignee: danm → jaggernaut
Whiteboard: 1 day, eta 6/15. → 1 day
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.
why on earth are we hardcoding widths in dialogs!?

Comment 59

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

Comment 60

18 years ago
Download dialogs now seem OK on the latest Windows builds here

Comment 61

18 years ago
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.

*** Bug 92567 has been marked as a duplicate of this bug. ***
*** Bug 93708 has been marked as a duplicate of this bug. ***
Whiteboard: 1 day → 1 day [se-radar]

Comment 64

18 years ago
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.

Comment 65

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


18 years ago
Blocks: 99227
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

18 years ago
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.

So is anyone still seeing the vertical cutting?
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

18 years ago
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

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.
Created attachment 49210 [details] [diff] [review]
Different approach that scales better I believe.
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

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

Comment 74

18 years ago
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.
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

18 years ago
Can we do a SizeToContent() after showing the Pause button?
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

18 years ago
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.

Created attachment 49321 [details] [diff] [review]
Just what I was looking for. Hide the button but have its width be part of the dialog's intrinsic sizing calculation
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

Comment 81

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


18 years ago
Attachment #49321 - Flags: review+

Comment 83

18 years ago
nsbranch+, 0.9.5
Keywords: nsbranch → nsbranch+
Target Milestone: --- → mozilla0.9.5

Comment 84

18 years ago


18 years ago
Attachment #49321 - Flags: superreview+
And checked in.
Last Resolved: 18 years ago
Resolution: --- → FIXED


18 years ago
Keywords: mozilla0.9.2, mozilla0.9.3, nsbeta1+, nsmac2
Resolution: FIXED → ---
Whiteboard: 1 day [se-radar] → [se-radar]

Comment 86

18 years ago
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

18 years ago
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 ...!
check it in - PDT+.

Whiteboard: [se-radar] → [se-radar], PDT+

Comment 89

18 years ago
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 ?
gabriel, that's a separate issue. in fact, it might already be filed as one of
daniel's [db48x] page info bugs...
Adding correctness Status Whiteboard, correct/expected behavior does not occur.
Whiteboard: [se-radar], PDT+ → [se-radar], PDT+,[correctness]
Checked into the 0.9.4 branch.
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

vrfy fixed using comm *branch* bits from 2001.09.25.xx on linux, winnt, mac os
9.1 and os 10.0.4.
Keywords: vtrunk
*** Bug 101849 has been marked as a duplicate of this bug. ***
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!
Keywords: vtrunk
Resolution: FIXED → ---
Created attachment 52139 [details]
classic theme on Mac 10.0.4, branch
Created attachment 52140 [details]
classic theme on Mac 9.1, branch
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.
-> 0.9.7
Target Milestone: mozilla0.9.5 → mozilla0.9.7
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. :)
Component: XP Apps: GUI Features → File Handling


17 years ago
Whiteboard: [se-radar], PDT+,[correctness] → [se-radar], [PDT+],[correctness] [vrfy fixed for 094 branch on 09.26]


17 years ago
Blocks: 107066


17 years ago
Keywords: nsbranch+

Comment 101

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

Comment 102

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


17 years ago
Severity: major → normal
Keywords: helpwanted
Target Milestone: mozilla0.9.7 → Future
have been seeing this more often...wonder why it has regressed...
Keywords: nsbeta1
Target Milestone: Future → ---
-> future
Target Milestone: --- → Future
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.
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.
Created attachment 67858 [details] [diff] [review]
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?
Won't this cause the progress bar's size to shrink as the "percent done" text grows?
Yes, it will, but this has been happening all along. 
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
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%.
Created attachment 67937 [details] [diff] [review]
Improved patch that corrects the 100% cut-off and keeps the progressbar from shrinking.
Attachment #67858 - Attachment is obsolete: true

Comment 113

17 years ago
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.
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
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.
*** Bug 123619 has been marked as a duplicate of this bug. ***
I'll see tomorrow what this looks like on Mac (which uses a larger font iirc).


17 years ago
No longer blocks: 107066
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.
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

17 years ago
nsbeta1+ per ADT triage team, ->1.0
Keywords: nsbeta1 → nsbeta1+
Target Milestone: Future → mozilla1.0

Comment 121

17 years ago
The new progress dialog code and FE is in.  pink/others, are you still able to

Comment 122

17 years ago
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
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

17 years ago
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.
-> law
Assignee: jaggernaut → law

Comment 126

17 years ago
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.

...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.
Created attachment 71810 [details]
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.
Created attachment 71811 [details] [diff] [review]
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.
Attachment #67937 - Attachment is obsolete: true
Created attachment 71812 [details]
Download dialog window after applying the patch (during/after download)

Comment 131

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


17 years ago
Attachment #71811 - Attachment is obsolete: true
*** Bug 129587 has been marked as a duplicate of this bug. ***
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

17 years ago
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.
Created attachment 73605 [details]
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.


17 years ago
Whiteboard: [se-radar], [PDT+],[correctness] [vrfy fixed for 094 branch on 09.26] → [se-radar], [PDT+],[correctness] [vrfy fixed for 094 branch on 09.26][adt3]

Comment 136

17 years ago
Created attachment 74250 [details] [diff] [review]
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=.
Attachment #49210 - Attachment is obsolete: true
Attachment #49321 - Attachment is obsolete: true

Comment 137

17 years ago
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.


Comment 138

17 years ago
Created attachment 77661 [details]
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

Comment 139

17 years ago
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

17 years ago
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

17 years ago
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?
Whiteboard: [se-radar], [PDT+],[correctness] [vrfy fixed for 094 branch on 09.26][adt3] → [se-radar], [adt3]

Comment 142

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

Comment 143

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

Comment 144

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

Comment 145

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

Comment 146

17 years ago
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.
Target Milestone: mozilla1.0 → mozilla1.0.1
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

17 years ago
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.
i'm running branch builds and i've yet to see the d/l manager. it does _not_
come up by default.

Comment 150

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

Comment 151

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

Comment 152

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

Comment 153

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

Comment 154

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

Comment 155

17 years ago
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.
i´m using win2000 and mozilla 2002051006(1.0rc2), and the dialog shows fine
Created attachment 83364 [details]
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

Comment 158

17 years ago
*** Bug 147857 has been marked as a duplicate of this bug. ***
*** Bug 149742 has been marked as a duplicate of this bug. ***

Comment 160

17 years ago
*** Bug 134265 has been marked as a duplicate of this bug. ***
[re]nominating...for buffy.
Keywords: nsbeta1- → nsbeta1

Comment 162

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

Comment 163

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

Comment 164

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

Comment 165

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

Comment 166

17 years ago
*** Bug 158484 has been marked as a duplicate of this bug. ***
QA Contact: sairuh → petersen

Comment 167

16 years ago
Nav triage team: nsbeta1+/adt3
Keywords: nsbeta1 → nsbeta1+

Comment 168

16 years ago
Over to Jan.
Assignee: law → varga
chrisp, are you able to reproduce this?
Summary: Download progress dialog too small → Download progress dialog too small [clipped on right side]

Comment 170

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


16 years ago
Target Milestone: mozilla1.0.1 → mozilla1.4beta

Comment 171

16 years ago
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

16 years ago
Nav triage team: nsbeta1-
Keywords: nsbeta1+ → nsbeta1-
Whiteboard: [se-radar], [adt3] → [se-radar]


16 years ago
Blocks: 163993

Comment 173

16 years ago
Created attachment 126889 [details]
screenshot on firebird localized,winxp.

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

Comment 174

16 years ago
Created attachment 127862 [details]
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

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

Comment 176

15 years ago
Created attachment 145289 [details]
Still happening in 1.6

Still happening in 1.6...

Comment 177

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

Comment 178

14 years ago
Created attachment 173050 [details]
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

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


14 years ago
No longer blocks: 163993

Comment 180

12 years ago
see also Bug 280909 and Bug 234859
QA Contact: chrispetersen → file-handling


3 years ago
Component: File Handling → File Handling
Priority: P3 → --
Product: Core → Firefox
Target Milestone: mozilla1.4beta → ---
Version: Trunk → unspecified

Comment 181

5 months ago
I don't think this is an issue anymore.
Last Resolved: 18 years ago5 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.