Closed Bug 67216 Opened 24 years ago Closed 21 years ago

Three different .xul files for the download progress window

Categories

(Core Graveyard :: File Handling, defect, P2)

Product:
Core Graveyard
Component:
File Handling
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: bzbarsky, Assigned: law)

References

(
URL
)

Details

(Keywords: helpwanted, testcase, Whiteboard: [Hixie-P0])

Attachments

(1 file)

patch
9.09 KB, patch
jag+mozilla
: review+
bzbarsky
: superreview+
Details | Diff | Splinter Review 
We seem to have three different .xul files (each with its own javascript) for
the download progress dialog:

xpfe/components/ucth/resources/helperAppDldProgress.xul
xpfe/browser/src/downloadProgress.xul
xpfe/components/xfer/resources/downloadProgress.xul

Only the first of these seems to affect the download dialog.  I can't find any
places where the other two are used, and if there are such places, should we not
be using a single download dialog for everything??

ccing the people who wrote the second and third files to get their input
The third file you list is the "classic" download progress dialog that is still
used when you save a page, save a link, or save an image.  The  second file is
the older version of that dialog (and should be removed from the source tree).

There should be only one version and I'm working to merge the two that are still
in use.
Assignee: ben → law
This is essential in order to ensure all paths that download have the same
features (and lack of bugs :-).  Marking nsbeta1+.
Status: NEW → ASSIGNED
Keywords: nsbeta1+
Priority: -- → P1
Target Milestone: --- → mozilla0.9
A plan:
1. Add new method to nsIStreamTransfer that returns an nsIStreamListener (i.e., 
an nsStreamXferOp).
2. Change nsExternalHelperAppService so that it uses GetInterface to get the 
nsIStreamListener from the nsExternalAppHandler object.
3. Change nsExternalAppHandler so that it stores the object returned from 
nsIStreamTransfer::CreateTransferListener.
4. Change nsExternalAppHandler::GetInterface so that it returns the 
nsStreamXferOp object when asked for nsIStreamListener.
5. Let the nsStreamXferOp open the dialog (details TBD).

Issues: Synchronizing dialog with nsExternalAppHandler (getting starting time 
set, propagating cancel back, etc.).
Blocks: 27609
*** Bug 67103 has been marked as a duplicate of this bug. ***
simple testcases which currently reveal the old-only-has-the-Cancel-button
download progress dialog:

* select File > Save ... from the main menu
* selecting from the context menu [when available, o'course]: Save Image, Save
Link, Save As, Save Frame
Keywords: testcase
Bill, if you're redoing the download progress XUL, would you be able to clean up 
its UI at the same time, or are you just doing the back end? At the moment the 
front end is a dog's breakfast ...

[Resummarizing for meme-killing: progress windows are not dialogs.]
Summary: Three different .xul files for the download progress dialog → Three different .xul files for the download progress window
I'm mostly targeting the back-end (actually, I'd call it more the "middle").
But the front-end will be tweaked, at least.  New xul is welcome.
There's a patch to bug 67965 that may be worth looking at (UI changes to the
dialog).
Bill is too busy for mozilla0.9, resetting target milestone
Target Milestone: mozilla0.9 → ---
pchen, should this be nsbeta1-'d then?
*** Bug 71667 has been marked as a duplicate of this bug. ***
Marking mozilla0.9.1
Target Milestone: --- → mozilla0.9.1
*** Bug 75380 has been marked as a duplicate of this bug. ***
*** Bug 72760 has been marked as a duplicate of this bug. ***
OS: Linux → All
Hardware: PC → All
Suggested design for the download progress window is in my 2001-02-12 comment 
in bug 67965. It's not perfect, but I don't think we can get perfect without 
having a separate download manager window (so that we don't need the `Close' 
and `Close this window when download is finished' evilness).
Keywords: helpwanted
*** Bug 78747 has been marked as a duplicate of this bug. ***
law: have you unified the two download windows yet? 

If you arrange that, or give me a clue as to how to do it, I'll work on the 
front-end XUL to implement mpt's spec.

Gerv
Doron and I are working on this.
URL: http://www.nexgenmedia.net/download.png
Is this critical for beta?  What bad behavior results from this bug?  (And can
we live with it for a beta?)
The bad behavior is that depending on how the user saves a file (click vs shift
click vs context menu) they get different download progress windows.  Two of the
methods use the same XUL file, the third uses a different one.  The last XUL
file is not used.  The dialogs differ in the functionality they offer and in how
they present information.  This is a fairly major UI problem, in my opinion.

There is the secondary problem of this being a barrier to people who want to
improve the dialog in question -- they have to figure out what code to modify...


nav triage: its too late to be doing this work for netscape beta1. moving to 
mozilla1.0.
Target Milestone: mozilla0.9.1 → mozilla1.0
Blocks: 75364
The last comment in bug 78193 claims that this bug will implement the
pause/resume UI for downloads. Is this true or should a separate bug be filed?
pause/resume has already been implemented [in the download progress dialog]. :)
In reference to the last two comments, bug 78193 does implement pause and resume
but there's been some debate about the UI. For one thing, the dialogue now has
about five buttons in it (see
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=32664 for a
screenshot). MPT suggested that this is the current home for fixing up the UI. I
believe Peter was asking if this is correct, but Sairuh seems to think the
pause/resume UI is already complete. I'm confused now, is the UI complete or
not? And if not, is this the right place to fix it?

For those interested, I just created bug 83261 "UI for Pause/Resume in Download
Progress Window" to track this issue - hope it helps.
Unsetting milestone for reconsideration.  Currently, the Pause/Resume button is 
only available for ftp downloads, because a different dialog (one without 
Pause/Resume) is apparently used for http.  It would be a shame to not fix or 
workaround this, given the work that went into implementing Pause and Resume.
Target Milestone: mozilla1.0 → ---
I am an idiot. Ignore me. Live your life as if I never existed.
Target Milestone: --- → mozilla1.0
Actually, what I am doing is redoing the UI for the ftp download window.  I
guess I'll try to merge the two as well.
*** Bug 83261 has been marked as a duplicate of this bug. ***
*** Bug 84119 has been marked as a duplicate of this bug. ***
merging the 2 needs someone who knows more about that code than me
Doron, could you attach here the XUL/JS you have done so far, so whoever fixes 
this bug can use it?
Blocks: 90134
*ping*
Keywords: mozilla0.9.4
*ping* 
Doron, you're the one being pinged here :-)

Gerv
*** Bug 102355 has been marked as a duplicate of this bug. ***
*** Bug 102447 has been marked as a duplicate of this bug. ***
my code is dead due to XUL changes. Not that it matter, first combine the 3
files, then I will fix it :)
This is a major loss of functionality for anyone who picks "Save Link As" rather
than clicking on it (as I often do when I want to make sure the file is saved and
not displayed in the browser). Ergo, Severity -> Major.
Severity: normal → major
Whiteboard: [Hixie-P0][Hixie-1.0]
spam: over to File Handling.
Component: XP Apps: GUI Features → File Handling
Also of note, shift-click brings up the older download dialog.  I wanted to file
a different bug for this, but it seems to fall under this one.
->098/p2, should be handled by same fix as for bug 27609
Priority: P1 → P2
Target Milestone: mozilla1.0 → mozilla0.9.8
*** Bug 112138 has been marked as a duplicate of this bug. ***
Flip-floppping relationship to bug 27609 because I'm working the fix from there.
No longer blocks: 27609
Depends on: 27609
All these download related items are moving out; delayed due to overhaul of 
downloading and many regressions in this area.
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Target Milestone: mozilla0.9.9 → ---
Whiteboard: [Hixie-P0][Hixie-1.0] → [Hixie-P0]
Target Milestone: --- → mozilla1.0
Spam: Setting target milestone for all these to Future.

Please note that most, if not all, will be fixed in the course of the work I'm 
doing for bug 27609.  That fact is noted in the "depends on" field for each of 
these bugs (I think; go ahead and remedy that if you like).

I just don't have time to deal with the wrath that comes with having too many 
bugs.
Target Milestone: mozilla1.0 → Future
OK, I landed the fix for bug 27609.  There are still 3 (or maybe 4 
now) "progress dialogs."

BUT ONLY ONE OF THEM IS USED!!!!!  That would be nsProgressDialog.xul, but 
don't even think about using that file directly; see nsIProgressDialog.idl for 
the one true way.

I'll leave this bug to track cleaning up the old stuff.
Blocks: 54216
alecf just removed the components/ucth and component/xfer dirs completely in bug
156723.  So only xpfe/browser/src/downloadProgress.xul still needs removing.
QA Contact: sairuh → petersen
Attached patch patch — — Splinter Review 
removes xpfe/browser/src/downloadProgress.*
Attachment #113952 - Flags: superreview?(bzbarsky)
Attachment #113952 - Flags: review?(jaggernaut)
Comment on attachment 113952 [details] [diff] [review]
patch

Great!

Is anyone using downloadProgress.dtd and downloadProgress.properties? (over in
xfer/resources/locale/)
Attachment #113952 - Flags: superreview?(bzbarsky) → superreview+
If nsProgressDlg.xul is the only thing using that DTD file, it should be moved
out of xpfe/ and into the right dir (things in embedding/ should _not_ depend on
things in xpfe/).  Separate bug, though.  ;)
yes, that is a separate bug (namely Bug 158695), and that bug is mentioned in
bug 156723 which you cited earlier ;)
Comment on attachment 113952 [details] [diff] [review]
patch

r=jag
Attachment #113952 - Flags: review?(jaggernaut) → review+
patch checked in. I think that fixes this bug, none of the files listed in
comment 0 exist anymore.

There is another unused progress dialog; that will be addressed in bug 211169.

marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: