Closed
Bug 79889
Opened 24 years ago
Closed 6 years ago
Download progress dialog too small [clipped on right side]
Categories
(Firefox :: File Handling, defect)
Firefox
File Handling
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: mikepinkerton, Assigned: janv)
References
Details
(Keywords: helpwanted, polish, regression, Whiteboard: [se-radar])
Attachments
(17 files, 5 obsolete files)
27.88 KB,
image/jpeg
|
Details | |
25.68 KB,
image/gif
|
Details | |
22.37 KB,
image/jpeg
|
Details | |
19.36 KB,
image/gif
|
Details | |
19.36 KB,
image/gif
|
Details | |
16.64 KB,
image/png
|
Details | |
5.01 KB,
image/png
|
Details | |
17.83 KB,
image/png
|
Details | |
18.59 KB,
image/png
|
Details | |
7.60 KB,
image/png
|
Details | |
1.88 KB,
patch
|
Details | Diff | Splinter Review | |
17.23 KB,
image/png
|
Details | |
11.28 KB,
image/png
|
Details | |
24.76 KB,
image/jpeg
|
Details | |
36.15 KB,
image/pjpeg
|
Details | |
15.49 KB,
image/gif
|
Details | |
4.45 KB,
image/png
|
Details |
- start downloading a file, like from ftp
the download dialog is too small
Reporter | ||
Comment 1•24 years ago
|
||
Comment 3•24 years ago
|
||
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
Comment 5•24 years ago
|
||
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
Comment 6•24 years ago
|
||
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
Comment 7•24 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.
Dale
Comment 10•24 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.
Comment 11•24 years ago
|
||
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•24 years ago
|
||
*** Bug 82746 has been marked as a duplicate of this bug. ***
Comment 13•24 years ago
|
||
Ben - can you fix this in m0.9.2? thanks! Vishy
Assignee: law → ben
Priority: -- → P3
Comment 16•24 years ago
|
||
*** Bug 83491 has been marked as a duplicate of this bug. ***
Comment 17•23 years ago
|
||
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•23 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.
Comment 19•23 years ago
|
||
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•23 years ago
|
||
->evaughan, clearing target.
Assignee: trudelle → evaughan
Target Milestone: mozilla0.9.2 → ---
Comment 21•23 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.
Comment 22•23 years ago
|
||
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
Comment 24•23 years ago
|
||
I see this bug 100% of the time on windows XP.... using today's sweetlou
build.
Comment 25•23 years ago
|
||
Is this bug related to bug 85690?
Comment 26•23 years ago
|
||
*** Bug 85690 has been marked as a duplicate of this bug. ***
Comment 27•23 years ago
|
||
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•23 years ago
|
||
*** Bug 86080 has been marked as a duplicate of this bug. ***
Comment 29•23 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•23 years ago
|
||
Erm, aren't all the the buttons using images?
Comment 31•23 years ago
|
||
*** Bug 85664 has been marked as a duplicate of this bug. ***
Comment 32•23 years ago
|
||
*** Bug 87064 has been marked as a duplicate of this bug. ***
Comment 33•23 years ago
|
||
*** Bug 87760 has been marked as a duplicate of this bug. ***
Comment 34•23 years ago
|
||
*** Bug 88037 has been marked as a duplicate of this bug. ***
Comment 35•23 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•23 years ago
|
||
The download dialog seems ok under Mac with 2001062823 but I got sometime the
same problem with the "Prompt" dialog.
Comment 37•23 years ago
|
||
*** Bug 88601 has been marked as a duplicate of this bug. ***
Comment 38•23 years ago
|
||
*** Bug 83924 has been marked as a duplicate of this bug. ***
Comment 39•23 years ago
|
||
*** Bug 88763 has been marked as a duplicate of this bug. ***
Keywords: mozilla0.9.3
Comment 40•23 years ago
|
||
fwiw, i don't think i've run into this with my baseline testing of bug 88066
[using trunk bits]...
Comment 41•23 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•23 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
clicked).
But that is not the case when the linked file is a dll. I wonder why...
Comment 43•23 years ago
|
||
dimitrios, sounds like you're encountering bug 88453...
Comment 44•23 years ago
|
||
.
Comment 45•23 years ago
|
||
frank burleigh, what sort of file are you trying to download [an example link
would be great!].
Comment 46•23 years ago
|
||
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•23 years ago
|
||
*** Bug 89227 has been marked as a duplicate of this bug. ***
Comment 48•23 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•23 years ago
|
||
*** Bug 89348 has been marked as a duplicate of this bug. ***
Comment 50•23 years ago
|
||
*** Bug 89406 has been marked as a duplicate of this bug. ***
Comment 51•23 years ago
|
||
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•23 years ago
|
||
Comment 53•23 years ago
|
||
Comment 54•23 years ago
|
||
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•23 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
evaughan.
Reporter | ||
Comment 56•23 years ago
|
||
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
Comment 57•23 years ago
|
||
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.
Reporter | ||
Comment 58•23 years ago
|
||
why on earth are we hardcoding widths in dialogs!?
Comment 59•23 years ago
|
||
Besides which, when it clipped for me it clipped *vertically*! ;-)
Comment 60•23 years ago
|
||
Download dialogs now seem OK on the latest Windows builds here
Comment 61•23 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.
Dale
Comment 62•23 years ago
|
||
*** Bug 92567 has been marked as a duplicate of this bug. ***
Comment 63•23 years ago
|
||
*** Bug 93708 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Whiteboard: 1 day → 1 day [se-radar]
Comment 64•23 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.
Dale
Comment 65•23 years ago
|
||
*** Bug 94541 has been marked as a duplicate of this bug. ***
Comment 66•23 years ago
|
||
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•23 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.
Dale
Comment 68•23 years ago
|
||
So is anyone still seeing the vertical cutting?
Comment 69•23 years ago
|
||
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•23 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
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•23 years ago
|
||
Comment 72•23 years ago
|
||
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•23 years ago
|
||
Why do we need hacks like this? Isn't there some fundamental XUL dialog sizing
issue that needs fixing?
Comment 74•23 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.
Comment 75•23 years ago
|
||
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•23 years ago
|
||
Can we do a SizeToContent() after showing the Pause button?
Comment 77•23 years ago
|
||
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•23 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.
sr=hyatt
Comment 79•23 years ago
|
||
Comment 80•23 years ago
|
||
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
Comment 81•23 years ago
|
||
r=hewitt
Comment 82•23 years ago
|
||
Per hewitt, I'll change the <spring/> I'm adding to a <spacer/>
Updated•23 years ago
|
Attachment #49321 -
Flags: review+
Comment 83•23 years ago
|
||
nsbranch+, 0.9.5
Comment 84•23 years ago
|
||
sr=hyatt
Updated•23 years ago
|
Attachment #49321 -
Flags: superreview+
Comment 85•23 years ago
|
||
And checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Updated•23 years ago
|
Status: RESOLVED → REOPENED
Keywords: mozilla0.9.2,
mozilla0.9.3,
nsbeta1+,
nsmac2
Resolution: FIXED → ---
Whiteboard: 1 day [se-radar] → [se-radar]
Comment 86•23 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•23 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 ...!
Dale
Comment 89•23 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 ?
Comment 90•23 years ago
|
||
gabriel, that's a separate issue. in fact, it might already be filed as one of
daniel's [db48x] page info bugs...
Comment 91•23 years ago
|
||
Adding correctness Status Whiteboard, correct/expected behavior does not occur.
Whiteboard: [se-radar], PDT+ → [se-radar], PDT+,[correctness]
Comment 92•23 years ago
|
||
Checked into the 0.9.4 branch.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 93•23 years ago
|
||
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
Comment 94•23 years ago
|
||
*** Bug 101849 has been marked as a duplicate of this bug. ***
Comment 95•23 years ago
|
||
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•23 years ago
|
||
Comment 97•23 years ago
|
||
Comment 98•23 years ago
|
||
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 100•23 years ago
|
||
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
Updated•23 years ago
|
Whiteboard: [se-radar], PDT+,[correctness] → [se-radar], [PDT+],[correctness] [vrfy fixed for 094 branch on 09.26]
Comment 101•23 years ago
|
||
I also see the "100%" clipped when the download is finished, on Win98 builds.
Comment 102•23 years ago
|
||
*** Bug 114089 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Comment 103•23 years ago
|
||
have been seeing this more often...wonder why it has regressed...
Keywords: nsbeta1
Target Milestone: Future → ---
Comment 105•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
Won't this cause the progress bar's size to shrink as the "percent done" text grows?
Comment 109•23 years ago
|
||
Yes, it will, but this has been happening all along.
Comment 110•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
Attachment #67858 -
Attachment is obsolete: true
Comment 113•23 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.
Comment 114•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
*** Bug 123619 has been marked as a duplicate of this bug. ***
Comment 117•23 years ago
|
||
I'll see tomorrow what this looks like on Mac (which uses a larger font iirc).
Comment 118•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
nsbeta1+ per ADT triage team, ->1.0
Comment 121•23 years ago
|
||
The new progress dialog code and FE is in. pink/others, are you still able to
reproduce?
Comment 122•23 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
Comment 123•23 years ago
|
||
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•23 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.
Comment 126•23 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.
Dale
Comment 127•23 years ago
|
||
...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•23 years ago
|
||
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•23 years ago
|
||
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
Comment 130•23 years ago
|
||
Comment 131•23 years ago
|
||
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
Comment 132•23 years ago
|
||
*** Bug 129587 has been marked as a duplicate of this bug. ***
Comment 133•23 years ago
|
||
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•23 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.
Comment 135•23 years ago
|
||
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.
Updated•23 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•23 years ago
|
||
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•23 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.
Dale
Comment 138•23 years ago
|
||
(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•23 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•23 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•23 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•23 years ago
|
||
*** Bug 136553 has been marked as a duplicate of this bug. ***
Comment 143•23 years ago
|
||
*** Bug 130844 has been marked as a duplicate of this bug. ***
Comment 144•23 years ago
|
||
I had this problem with LittleMozilla (when it last was a compatible skin)
Comment 145•23 years ago
|
||
Okay, I see it now, but only after the download completes, when I check the
'keep this window open' checkbox.
Comment 146•23 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
Comment 147•23 years ago
|
||
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•23 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.
Reporter | ||
Comment 149•23 years ago
|
||
i'm running branch builds and i've yet to see the d/l manager. it does _not_
come up by default.
Comment 150•23 years ago
|
||
No, but there is another bug on that, that should make beta.
Comment 151•23 years ago
|
||
*** Bug 122776 has been marked as a duplicate of this bug. ***
Comment 152•23 years ago
|
||
*** Bug 139320 has been marked as a duplicate of this bug. ***
Comment 153•23 years ago
|
||
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-
Comment 154•23 years ago
|
||
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+
Comment 155•23 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.
Comment 156•23 years ago
|
||
i´m using win2000 and mozilla 2002051006(1.0rc2), and the dialog shows fine
Comment 157•23 years ago
|
||
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•23 years ago
|
||
*** Bug 147857 has been marked as a duplicate of this bug. ***
Comment 159•22 years ago
|
||
*** Bug 149742 has been marked as a duplicate of this bug. ***
Comment 160•22 years ago
|
||
*** Bug 134265 has been marked as a duplicate of this bug. ***
Comment 161•22 years ago
|
||
[re]nominating...for buffy.
Comment 162•22 years ago
|
||
*** Bug 160872 has been marked as a duplicate of this bug. ***
Comment 163•22 years ago
|
||
*** Bug 147094 has been marked as a duplicate of this bug. ***
Comment 164•22 years ago
|
||
*** Bug 152993 has been marked as a duplicate of this bug. ***
Comment 165•22 years ago
|
||
Appears to be fixed in 1.1b (2002072104) on Win2K
Comment 166•22 years ago
|
||
*** Bug 158484 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
QA Contact: sairuh → petersen
Comment 169•22 years ago
|
||
chrisp, are you able to reproduce this?
Summary: Download progress dialog too small → Download progress dialog too small [clipped on right side]
Comment 170•22 years ago
|
||
WFM on Win2000 with Mozilla 1.2.1, classic and orbit 3+1 themes.
Assignee | ||
Updated•22 years ago
|
Target Milestone: mozilla1.0.1 → mozilla1.4beta
Comment 171•22 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•22 years ago
|
||
Nav triage team: nsbeta1-
Comment 173•21 years ago
|
||
Firebird also has this problem on windows.
Is it caused by this?
Comment 174•21 years ago
|
||
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•21 years ago
|
||
*** Bug 231946 has been marked as a duplicate of this bug. ***
Comment 176•21 years ago
|
||
Still happening in 1.6...
Comment 177•21 years ago
|
||
This does not happen in Mozilla 1.6 ~ the current 1.7 RC1
Comment 178•20 years ago
|
||
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•20 years ago
|
||
*** Bug 281790 has been marked as a duplicate of this bug. ***
Comment 180•18 years ago
|
||
see also Bug 280909 and Bug 234859
Updated•15 years ago
|
QA Contact: chrispetersen → file-handling
Updated•8 years ago
|
Priority: P3 → --
Product: Core → Firefox
Target Milestone: mozilla1.4beta → ---
Version: Trunk → unspecified
Assignee | ||
Comment 181•6 years ago
|
||
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.
Description
•