270894 - Freeze nsIProgressDialog

Status: RESOLVED WONTFIX

(Core Graveyard :: Embedding: APIs, defect)

Description

[jhp (no longer active)]

Freeze nsIProgressDialog.

In use by Eclipse.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

hmm, what does eclipse use this for?

Comment 2

[jhp (no longer active)]

They have a Java class that implements nsITransfer and nsIProgressDialog.  Right
now, the nsIProgressDialog functions are stubbed out, but I'm sure they plan to
use it to display an SWT dialog showing the download progress.  Should they be
using something else?

Comment 3

[Darin Fisher]

Hmm... nsITransfer was created only recently (for 1.7 IIRC), so they are going
to have an interesting time supporting older versions of Moz.

In this case, there may be less need to freeze nsIProgressDialog as is.  We may
have some wiggle room to define a better set of interfaces.

nsIProgressDialog is mentioned here:
http://www.mozilla.org/projects/embedding/EmbedInterfaceFreeze.html
(of course that document is very stale, and the embedding client mentioned is
probably the defunct AOL/Gecko.)

Since this interface is not used by any of our embedding samples, I would be
more willing to accomodate interface changes for 1.8, but we should still
provide a frozen means to do what this interface does.

Eclipse can code against different interfaces for 1.4, 1.5, 1.6, 1.7 and 1.8,
but it cannot code against different interfaces introduced for 1.9 ;-)

biesi: do you have cycles to work on freezing this API?

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

I am not sure that we want to freeze this interface. embeddors do not have to
use it. in mozilla, it is really a private interface between the dl manager and
the progress dialog (and the ftp upload code) - i.e. it is only used by code
that embeddors do not use.

Comment 5

[Darin Fisher]

biesi: ok, that's fine.  but, perhaps we need to freeze some alternative
interface that an embedder can use to handle downloads.  i think that eclipse is
basically wanting to show something like our unknown content dialog.

Comment 6

[Boris Zbarsky [:bzbarsky]]

That would be nsIHelperAppLauncherDialog, not nsIProgressDialog (the latter is
the interface for the progress dialog you get once you decide what you're doing
with the data).  This interface is in fact an embedding interface that the
embedding layer is expected to implement and we do want to move towards freezing
it once we decide whether the modality behavior is specified.

Comment 2 indicates that they in fact are trying to show progress, however, so
nsIHelperAppLancherialog is not quite relevant to them...

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

>(the latter is
>the interface for the progress dialog you get once you decide what you're doing
>with the data).

no, nsITransfer (or, currently, nsIDownload) is that interface... consider
firefox: it does not use a progressdialog.

Comment 8

[jhp (no longer active)]

Ah, ok, so a combination of nsITransfer and nsIWebProgressListener are all
that's needed to display the download progress?

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

that's correct. see also
http://lxr.mozilla.org/seamonkey/source/uriloader/base/nsIDownload.idl#144

Comment 10

[Christian :Biesinger (don't email me, ping me on IRC)]

WONTFIX in favor of bug 270897