Closed Bug 79889 Opened 23 years ago Closed 6 years ago

Download progress dialog too small [clipped on right side]

Categories

(Firefox :: File Handling, defect)

Product:
Firefox
Component:
File Handling
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: mikepinkerton, Assigned: janv)

References

Details

(Keywords: helpwanted, polish, regression, Whiteboard: [se-radar])

Attachments

(17 files, 5 obsolete files)

[img] dialog too small
27.88 KB, image/jpeg
Details
The dialog looks fine on Win32 platform
25.68 KB, image/gif
Details
linux classic shot of dialog
22.37 KB, image/jpeg
Details
http://www.mozilla.org/releases/ (version 0.9.2) then click on Microsoft Windows Talkback download
19.36 KB, image/gif
Details
http://www.mozilla.org/releases/ (version 0.9.2) then click on Microsoft Windows Talkback download
19.36 KB, image/gif
Details
classic theme on Mac 10.0.4, branch
16.64 KB, image/png
Details
classic theme on Mac 9.1, branch
5.01 KB, image/png
Details
Issue with classic on W2K
17.83 KB, image/png
Details
Download dialog window after applying the patch (during/after download)
18.59 KB, image/png
Details
Like this in Modern on Windows
7.60 KB, image/png
Details
Patch to .xul and removal of unnecessary sizeToContent() call
1.88 KB, patch
Details | Diff | Splinter Review
The top image is dialog shown directly, the bottom two are progress / completed.
17.23 KB, image/png
Details
buttons go to the right when download is complete(win2k, 2002051006)
11.28 KB, image/png
Details
screenshot on firebird localized,winxp.
24.76 KB, image/jpeg
Details
this bug still happens in Moz 1.4
36.15 KB, image/pjpeg
Details
Still happening in 1.6
15.49 KB, image/gif
Details
example of File Bookmark dialog with incorrect size
4.45 KB, image/png
Details 
- start downloading a file, like from ftp

the download dialog is 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...

->bill.
Assignee: blakeross → law
Blocks: 78106
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.
Keywords: pp
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
*** Bug 81853 has been marked as a duplicate of this bug. ***
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

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.
*** 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
nav triage team:

Reassigning to pchen
Assignee: law → pchen
*** 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.
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
->evaughan, clearing target.
Assignee: trudelle → evaughan
Target Milestone: mozilla0.9.2 → ---
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
downloads.

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
I see this bug 100% of the time on windows XP.... using today's sweetlou 
build.
Is this bug related to bug 85690?
*** 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
mozilla.

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

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. ***
Keywords: mostfreq
*** Bug 87760 has been marked as a duplicate of this bug. ***
Keywords: nsBranch
*** Bug 88037 has been marked as a duplicate of this bug. ***
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.
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. ***
Keywords: mozilla0.9.3
fwiw, i don't think i've run into this with my baseline testing of bug 88066
[using trunk bits]...
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?
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...
dimitrios, sounds like you're encountering bug 88453...
.

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...
*** Bug 89227 has been marked as a duplicate of this bug. ***
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.
*** Bug 89348 has been marked as a duplicate of this bug. ***
*** 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.
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
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.

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

Besides which, when it clipped for me it clipped *vertically*! ;-)
Download dialogs now seem OK on the latest Windows builds here
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
*** 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]
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

*** Bug 94541 has been marked as a duplicate of this bug. ***
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.
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
 
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?
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.
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").
Why do we need hacks like this? Isn't there some fundamental XUL dialog sizing 
issue that needs fixing?

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

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.
Status: NEW → ASSIGNED
r=hewitt
Per hewitt, I'll change the <spring/> I'm adding to a <spacer/>
Attachment #49321 - Flags: review+
nsbranch+, 0.9.5
Keywords: nsbranch → nsbranch+
Target Milestone: --- → mozilla0.9.5
sr=hyatt
Attachment #49321 - Flags: superreview+
And checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Keywords: mozilla0.9.2, mozilla0.9.3, nsbeta1+, nsmac2
Resolution: FIXED → ---
Whiteboard: 1 day [se-radar] → [se-radar]
Er, checked in on the trunk, right? But this needs to go on the branch too, no?
Reopening for PDT approval and branch checkin.
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
check it in - PDT+.
Whiteboard: [se-radar] → [se-radar], PDT+
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.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
yay!

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!
Status: RESOLVED → REOPENED
Keywords: vtrunk
Resolution: FIXED → ---
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
Whiteboard: [se-radar], PDT+,[correctness] → [se-radar], [PDT+],[correctness] [vrfy fixed for 094 branch on 09.26]
Blocks: 107066
Keywords: nsbranch+
I also see the "100%" clipped when the download is finished, on Win98 builds.
*** Bug 114089 has been marked as a duplicate of this bug. ***
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.
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%.
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
terminal). 
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).
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%").
nsbeta1+ per ADT triage team, ->1.0
Keywords: nsbeta1 → nsbeta1+
Target Milestone: Future → mozilla1.0
The new progress dialog code and FE is in.  pink/others, are you still able to
reproduce?
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.
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
Status: REOPENED → NEW
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
...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.
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.
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
Thanks for the patch, Andreas.  I think this will also permit us to remove the
"sizeToContent" call in nsProgressDialog.js.
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)?
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.
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.
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]
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
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
(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.
note that attachement from comment 138 still shows the stretching of the d/l
window in some cases when a d/l completes
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.
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]
*** Bug 136553 has been marked as a duplicate of this bug. ***
*** Bug 130844 has been marked as a duplicate of this bug. ***
I had this problem with LittleMozilla (when it last was a compatible skin)
Okay, I see it now, but only after the download completes, when I check the
'keep this window open' checkbox.  
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.
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.
No, but there is another bug on that, that should make beta.
*** Bug 122776 has been marked as a duplicate of this bug. ***
*** Bug 139320 has been marked as a duplicate of this bug. ***
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1-
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+
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
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)
*** Bug 147857 has been marked as a duplicate of this bug. ***
*** Bug 149742 has been marked as a duplicate of this bug. ***
*** Bug 134265 has been marked as a duplicate of this bug. ***
[re]nominating...for buffy.
Keywords: nsbeta1- → nsbeta1
*** Bug 160872 has been marked as a duplicate of this bug. ***
*** Bug 147094 has been marked as a duplicate of this bug. ***
*** Bug 152993 has been marked as a duplicate of this bug. ***
Appears to be fixed in 1.1b (2002072104) on Win2K
*** Bug 158484 has been marked as a duplicate of this bug. ***
QA Contact: sairuh → petersen
Nav triage team: nsbeta1+/adt3
Keywords: nsbeta1 → nsbeta1+
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]
WFM on Win2000 with Mozilla 1.2.1, classic and orbit 3+1 themes.
Target Milestone: mozilla1.0.1 → mozilla1.4beta
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.
Nav triage team: nsbeta1-
Keywords: nsbeta1+ → nsbeta1-
Whiteboard: [se-radar], [adt3] → [se-radar]
Blocks: majorbugs
Firebird also has this problem on windows.
Is it caused by this?
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
*** Bug 231946 has been marked as a duplicate of this bug. ***
Attached image Still happening in 1.6 — 
Still happening in 1.6...
This does not happen in Mozilla 1.6 ~ the current 1.7 RC1
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.
*** Bug 281790 has been marked as a duplicate of this bug. ***
No longer blocks: majorbugs
see also Bug 280909 and Bug 234859
QA Contact: chrispetersen → file-handling
Priority: P3 → --
Product: Core → Firefox
Target Milestone: mozilla1.4beta → ---
Version: Trunk → unspecified
I don't think this is an issue anymore.
Status: NEW → RESOLVED
Closed: 23 years ago → 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: