Starting with the 20090609 SM 2 nightly trunk build, right-clicking on a download link and selecting "Save Link Target" pops up an unwanted/unnecessary "Save As" dialog. This appears to be a regression caused by the Bug 426742 checkin (although opinions may vary). To Reproduce: right-click any ordinary download link (HREF) and select Save Link Target. Expected behavior: if your Downloads Preferences are set to "Automatically download files to specified download folder", this should immediately initiate a download without further interaction. What actually happens: since the checkin of Bug 426742 for the 20090609 SM 2 nightly trunk build, this now pops up an extraneous Save As dialog. This should not happen - the needed filename is available, independent of any content-disposition considerations. Note that this may not be properly classified as a "Download Manager" bug...

"if your Downloads Preferences are set to" might be a bit misleading, as the preference panel isn't very functional right now, mostly setting preferences to new download manager won't follow. Bug 490464 is dealing with that.

Thanks - I mostly added that reference to the main Browser>Downloads prefs to "legitimize" my comments on expectations. ;) Also, nothing posted in Bug 490646 indicates that any of the proposed "disabling" actually happened... Finally, the referenced behavior change appeared on the checkin from Bug 426742 - which at least overtly is dealing with what happens when one *has* a Save As dialog, rather than altering what set of circumstances lead up to *getting one*.

You suspected correctly. Before the checkin of bug 426742 saveLink() was always calling saveURL() which calls internalSave() which calls getTargetFile() (all in contentAreaUtils.js). The latter checks the browser.download.useDownloadDir pref and skips the file picker if that is set to TRUE. The problem with the new approach is that nsExternalAppHandler::SaveToDisk() only skips prompting for a filename if its first parameter is set. Here it is invoked by nsExternalAppHandler::OnStartRequest() which unconditionally passes nsnull which equals "always prompt". I guess the chances for changing nsExternalAppHandler on the 1.9.1 branch used for SM 2.0 are zero (FF 3.5 is almost out the door and this would neither be a simple nor a security fix). But maybe we could check the browser.download.useDownloadDir pref in saveLink() (SM code) and just use saveURL() as before in case it is TRUE.

I think we never should skip the prompt if chances are that we end up with e.g. attachment.cgi (Bugzilla case) as the name on disk, and that's probably the case the toolkit code is coded for. I wouldn't say that chances are zero to get something in, but it needs to be logical and have good arguments (platform people are likely to take a bunch of not-so-small changes between 1.9.1.0 and 1.9.1.1 to enable Fennec releasing off the branch, for example).

Filed bug 498949. Let's see how that works out.

(In reply to comment #5) > Filed bug 498949. Let's see how that works out. So far, not so well... I just looked at the new "stats" displays on KaiRo's page, and it looks like neither this bug nor the bug you opened are even being considered for SM2. I don't get it - this was a feature that worked perfectly well, and *as documented*, and it was trashed by the checkin on 426742... and the fallout is "tough luck!" And 426742 wasn't marked as being "high priority", so why was a regression caused by a "Normal" priority bug allowed to stand, rather than being fixed by reverting the checkin (or a fix provided some other way)? Are regressions the hip new thing? ;)