Change posing of download progress for embedding.



Core Graveyard
File Handling
17 years ago
2 years ago


(Reporter: Peter Trudelle, Assigned: Bill Law)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(3 attachments)



17 years ago
Need to change how this dialog is invoked so it can be overridden by embedding 
clients.  Some details below, more at URL above; danm will be happy to help and 
answer questions.

UI Posed by Gecko (Up Calls)
These are calls to, in one form or another, which are relevant to 
embedding. They're split into calls and callers, where a call is considered to 
be a base-level call to which should be API-ized like we're 
discussing, and a caller is something which currently uses but 
should use one of these new APIs when they're created.

I've tried to categorize these sensibly... Each category implies a UI-posing 
component with methods for each item marked "CALL" in that category. Items 
marked "CALLER" in a given category may imply a new method in that component 
(eg. the print dialog stuff), or may just be a caller of some other extant 
method in a different component (eg. the uri loader opening a new window).

Download Progress:
CALL: /xpfe/components/xfer/src/nsStreamXferOp.cpp#102

Comment 1

17 years ago
Adding mozilla0.9 keyword, dependency
Blocks: 71837
Keywords: mozilla0.9


17 years ago
No longer blocks: 71837


17 years ago
Blocks: 65233

Comment 2

17 years ago
Apologies for all the bug spam. For the detailed overview of this task, see
danm's document:

See my first cut at a component-wise categorization:

And if you want to laugh, see also my brainless incomplete IDL for these components:

Keywords: embed


17 years ago

Comment 3

17 years ago
Targetting mozilla0.9 and adding "nsbeta1+" so it appears on my radar.
Keywords: nsbeta1+
Target Milestone: --- → mozilla0.9

Comment 4

17 years ago
I'm not getting to this dialog till next round...
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 5

17 years ago
OK, moving back to mozilla0.9 'cause these are "embedding" bugs.
Target Milestone: mozilla0.9.1 → mozilla1.2


17 years ago
Target Milestone: mozilla1.2 → mozilla0.9.2

Comment 6

17 years ago
damnit, mozilla0.9!
Target Milestone: mozilla0.9.2 → mozilla0.9

Comment 7

17 years ago
Setting date in status whiteboard.
Whiteboard: Apr 24

Comment 8

17 years ago
Bill, you can move this to 0.9.1, unless you have other need for it in 0.9.

Comment 9

17 years ago
We changed our minds; targetting 0.9.1 now.
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 10

17 years ago
Overlaps with bug 65770
Whiteboard: Apr 24 → eta 5/11 .5 days


17 years ago
Blocks: 74012
nav triage: dont think this is holding any product release, it shd be targeted 
to the mozilla1.0 architecture freeze. moving as such. 
Target Milestone: mozilla0.9.1 → mozilla1.0

Comment 12

17 years ago
Vishy, this is an *embedding* bug, why are you triaging it, and delaying it past
all known embedding deadlines?  cc vishy, marek

Comment 13

17 years ago
Created attachment 35226 [details] [diff] [review]
New progress dialog stuff

Comment 14

17 years ago
Created attachment 35227 [details] [diff] [review]
xfer component changes to use new progress dlg

Comment 15

17 years ago
I attached a new "progress dialog" component (first patch), and, changes to the 
xfer component (file-save-as, save-link-as code) that changes it to use this 

The progress dialog is implemented using one of the existing progress dialogs 
so the implementation is a little thin.  It just creates some JS glue objects 
that bind the new interface to the old implementation.

What's missing is the change to the other client of the progress dialog: the 
uriloader/exthandler code.  Either it needs to change to use the stream 
listener from the xfer component (desirable, because that gets it error 
handling; undesirable because it's more work), or, it needs to be wired up to 
the new interface/component (so that embedders can hook in).  The latter 
probably isn't too hard (it's sort of the inverse of the glue layer in that 
component now).

This code isn't ideal, but probably accomplishes the objective.
Peter- sorry about that. I moved it out of mozilla0.9.1 as it was not a netscape 
beta stopper. Pls work with Bill to get the fix we need for embedding. 

Comment 17

17 years ago
This bug seems to be depressingly stalled. Apart from the null plugin issue,
this is the last non-compliant dialog left, and it's looking as if the null
plugin will be fixed in such a way as to use the prompt service so embedders
will get it for free. 

I don't know what other embedders feel about this, but for galeon it's a very
frustrating bug. Due to the way the external helper service is setup, even
though it's technically non-compliant, there isn't a problem because 
ShowProgressDialog lives in nsIHelperAppLauncherDialog, but nsStreamXferOp's
usage cannot be overridden without this landing. So, our users are placed in
the confusing situation of seeing our gnome progress dialog if the download
goes through the external helper service and the xul dialog when it goes 
through the stream transfer service.

What's the new embedding api finalisation target seeing as 0.9.2 has come and

Comment 18

17 years ago
I think we should try applying the patches I've attached and see if that gets
things working better.  I'll work on applying them to my current source tree and
verifying that it works for me (bringing up the same xul progress dialog as we
get via the uriloader).  I'd also like to make sure that it works OK with your
"override" of that dialog.

I'll post an update (and updated patch if necessary) later today.

Comment 19

17 years ago
Created attachment 47515 [details] [diff] [review]
Updated patch for mozilla/xpfe/components/xfer/src files

Comment 20

17 years ago
I've attached the updated patch (no substantive changes).  This appears to 
still work for me.

The other patch attached previously (the one labelled "New progress dialog 
stuff" is unchanged.

Comment 21

17 years ago
I've successfully applied the patches and mozilla works as it should. I'm going
to start looking at constructing our GNOME impl of the interface as soon as I 
can. Have to think about the best way to reuse our existing nsIWebProgressListener.

Comment 22

17 years ago
Heh, this implementation is pretty crazy. :-)

I'm tempted to run screaming for the trees and hope that adam lock's new
nsIWebBrowserPersist lands. It uses nsIWebProgressListener in the same way that
nsIHelperAppLauncher does. We can use it's save function instead of going
through the stream transfer manager.

I'd hate to see what the c++ version of this ( ie: what our code would be )
would look like. :-)


17 years ago
Blocks: 98995
spam: over to File Handling.
Component: XP Apps: GUI Features → File Handling

Comment 24

16 years ago

See also bug 102556.
Target Milestone: mozilla1.0 → mozilla0.9.8


16 years ago
Depends on: 27609

Comment 25

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


16 years ago
Target Milestone: mozilla0.9.9 → ---


16 years ago
Whiteboard: eta 5/11 .5 days
Target Milestone: --- → mozilla1.0

Comment 26

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

Comment 27

16 years ago
New nsIProgressDialog interface is now in place.  Embedders, have at it.
Last Resolved: 16 years ago
Resolution: --- → FIXED
over to embed qa [load-balancing]...
QA Contact: sairuh → mdunn

Comment 29

15 years ago
Clean up verification of dated code change bus
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.