Build ID: 20000731008 M18 If you download from an FTP site, the old pickapp dialog is still thrown. We need to use the new 'super helper app' dialog. See bug 28584...

Must fix for beta3 or user can't use helper apps when downloading from FTP sites (PickApp doesn't work from that dialog).

nav triage team: gotta use that spiffy new 'super helper app' dialog!

marking nsbeta3+, which I assume pchen meant to do.

This will be fixed when 45066 is fixed.

This depends on a P2...moving this to P2. Adding [PDTP2]

adding mostfreq, to ease my queries --coz i run into this often, but can never remember the bugid. ;) found a useful test case: 1. go to ftp://ftp.mozilla.org/pub/mozilla/nightly/ and go into any subdirectory that has a zip file, eg, mozilla-win32.zip. 2. double-click on the zip file to start downloading. result: the unknown file type dialog appears. actual: since it's a known filetype (zip), the new downloading dialog should appear. by contrast, this *does* work if you access an ftp link that's on an html page. for example, clicking the Windows build link on http://www.mozillazine.org (in the builds status bar near the top of the page).

PDT agrees P2

Removing mostfreq - this bug does not yet qualify for this keyword under the established criteria. Gerv

adding se-radar to status so that i can find this bug more easily. pls don't remove it [yet], thx.

re-assigning. I have a fix for this in my tree now that i have a progress dialog for the helper app dialog. I think we're ready to throw the switch.

selmer and i decided to hold off on this fix until rtm since we are so close to getting the beta out the door. I didn't get it checked by the deadline of last thursday at midnight.

nsbeta3- then

rtm+, part of Scott's helper app package.

I just realized I never posted the diffs....

mscott can you list the reviewers in order to get an rtm++.

oops, I posted the wrong patch to this bug. attaching the correct patch. sr=rpotts

still waiting for the extra plsus from PDT so I can check this in tonight....I'll ping them directly.

just to re-iterate, r=alecf, sr=rpotts

PDT marking [rtm++], cc'ing mcarlson just in case there's l10n impact (we think there shouldn't be)

there shouldn't be any I10N impact. I re-used strings we already had for another dialog.

This is now fixed on the tip and the branch. Clicking on ftp urls, typing urls in the urlbar, etc. all properly invoke the helper app dialog instead of the ucth handler dialog. Before, only links clicked in a web page used to trigger this dialog.

I believe there is still a L10N impact even if you do re-use strings from another dialog. But nonetheless, this fix is fine since it's checked in before 10/13. thanks

using today's 2000.10.04.xx-n6 [opt comm branch] bits on linux, winnt and mac os 9.0, i've vrfy'd this as fixed (ie, the helper app download dialog appears instead of the old unknown filetype one) via these tests: 1. went through all the http and ftp links on this webpage (single-clicked the links): http://www.mozilla.org/quality/browser/front-end/testcases/xpapps-gui/download.html 2. double-clicked (to initiate download) links from ftp pages, namely directories in ftp://ftp.mozilla.org/pub/mozilla/nightly/ --tested on zip, exe, tar.gz and bin files. if someone could vrfy this on the trunk, that'd be great!

1. went through all the http and ftp links on this webpage (single-clicked the links): 2. double-clicked (to initiate download) links from ftp pages, namely directories in ftp://ftp.mozilla.org/pub/mozilla/nightly/ --tested on zip, exe, tar.gz and bin files. Verified Fixed on trunk builds linux 101708 RedHat 6.2 win32 101704 NT 4 mac 101704 Mac OS9 Setting bug to Verified and removing vtrunk keyword se, thanks for pointing to good verification resources. you made this one very easy.