37471 - Saving File dialog needs to be converted to new xul widgets

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P3)

Description

[sairuh (rarely reading bugmail)]

another one... (for endusers: you get this when downloading a file is in
progress.) the text as well as the Cancel button are in html (outlined in
green), which should be converted.

Comment 1

[leger]

Putting on [nsbeta2-] radar. Not critical to beta2.  Not a top level window.  
Can be skinned in beta3.

Comment 2

[Chuck R.]

I noticed on build 2000051808 that when downloading a file, as the progress bar 
in the download window gets bigger, so does the window. Download a large file 
(1MB or more) and see. Perhaps this problem is part of this bug.

Comment 3

[sairuh (rarely reading bugmail)]

Chuck, the ever-growing problem is bug 38376.

Comment 4

[sairuh (rarely reading bugmail)]

i'd really like this to get fixed for beta2, mainly since the basic buttons (OK,
Cancel) are, well, absent. adding dogfood kw, and will attach a screenshot to
illustrate the lack of functionality.

Comment 5

[sairuh (rarely reading bugmail)]

Attachment: sparse-lookin' dialog

Comment 6

[sairuh (rarely reading bugmail)]

ugh, silly me --the only button that needs to be in this dialog is Cancel. need
caffeine... anyhow, if you click the 'O' it does cancel ('O' acting like a
substitute button). adding relnote kw in case this doesn't get fixed for beta2.

Comment 7

[don]

Ben, is this required for skinability?

Comment 8

[don]

Move to M20 target milestone.

Comment 9

[Robert Kaiser]

Attachment: zip file with patch

Comment 10

[Robert Kaiser]

OK, I have a patch here (just added). There is one problem left though: You have
to click into the textfields to get the content showed. Dunno why that happens,
perhaps a XUL problem.
I hope that's the only real bug there. The zip contains 3 files in unix format:
2 diffs, for downloadPrgress.xul and downloadProgress.js - and a new file,
downloadProgress.css with the appropriate styles.
xul and js should naturally change the existing files in /packages/widget-
toolkit/global/conent/ while css should go into chrome/skins/modern/gloval/skin/.

The patch works for me with win32 nightly 2000-05-28-08.

Comment 11

[sairuh (rarely reading bugmail)]

added patch kw, so that Robert's patch can be reviewed. :-)

Comment 12

[Robert Kaiser]

If someone wants to use the patch in the meantime: I've uploaded it to http:
//www.kairo.at/mozilla/shots/ProgressPatch.zip - no diffs, just extract into moz
dir  (\bin for win32, /package for linux - correct folders are in the zip)

Comment 13

[leger]

Putting on [dogfood-] radar since already [nsbeta2-]

Comment 14

[Robert Kaiser]

The problem I described when submitting the patch has gone away now, and the
püatch is working exactly like it should in 2000060408 (win32) now - without any
clicking in the dialog you get what you expect to get :)

Comment 15

[Robert Kaiser]

Killing [nsbeta2-][dogfood-] from Status Whiteboard, setting that bug for
nsbeta2 & dogfood reviewing again.
As there is a patch now and I have a bunch of people working alright with that
patch, it's worth reviewing.
And with that shifting around of things in current dialog while downloading
(that started _after_ legers nsbeta- comment), it's almost unuseable currently.
No "consumer" dling beta2 can be bugged with the current dialog IMHO (esp if we
have a much better patch).

Comment 16

[leger]

Putting on [nsbeta2+][dogfood-] radar.  not urgent to fix, but fix for beta2.

Comment 17

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

fix in hand, will check in when verifications complete. 

Comment 18

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

fixed!

Comment 19

[sairuh (rarely reading bugmail)]

yep! vrfy 2000.06.14.08-m17 commercial all/all.

Comment 20

[Stephen Walker]

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