Closed Bug 219056 Opened 21 years ago Closed 1 month ago

Would like to be able to bypass the 'save to' dialogue when using option+click

Categories

(Camino Graveyard :: Downloading, enhancement, P3)

Product:
Camino Graveyard
Component:
Downloading
Platform:
All
macOS
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: aamcc, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030912 Camino/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.5b) Gecko/20030912 Camino/0.7+

Using option+click, the save to dialogue appears (as in many browsers, except
Safari).  Is there a way of making it possible to simply download to the default
location without having to okay every single file?

Reproducible: Always

Steps to Reproduce:
1.Option+click any file for direct download
2.Dialogue appears
3.

Actual Results:  
Dialogue appears

Expected Results:  
Dialogue appears - hoping to be able to bypass this.....
i thought 0.7 used to be able to do this. i guess not.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Camino0.9
1.0, not 0.9
Target Milestone: Camino0.9 → Camino1.0
Priority: -- → P3
Target Milestone: Camino1.0 → Camino1.1
Is there a need for this to remain open? Camino now simply downloads to the
default location when you click, and option-click brings up the save dialog in
case you want to d/l the file to a different location.
Shouldn't this be closed?
No, because if you want to download something that would otherwise be viewed
inline (i.e., you have a list of links that go to images, and you want to
download all those images), you need opt-click.  

Besides, opt-click is standard behavior for "download this to my default
location and don't bother me with dialogues" in other Mac browsers.
Mike, any progress on this one? If you're not actively working on something, I might be able to have a go at it within the next couple weeks.

cl
May not be too hard a fix, we just need to be carefull of regressions since this sits in our necko/gecko code
i'm not working on this at all (note the target of 1.1)
Taking. Expect a patch within a week.

cl
Assignee: mikepinkerton → bugzilla
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
(In reply to comment #8)
> Taking. Expect a patch within a week.

Whew... it's been a long week. How's this coming? ;)
QA Contact: downloading
It's on my fairly short "talk about this with smarter people than I" list. I can't remember if I got started on it or not.

cl
This is going to need to happen inside

|nsHeaderSniffer::PerformSave| in SaveHeaderSniffer.mm.

Do we want to change the callers into that so that they pass along a BOOL |optionKeyIsPressed| ?

Nick, when your "summer project" of fixing our evil sniffing downloader comes to fruition, might you want to take care of this too?

CCing Simon, too, so he can take a look.
Could be, I can't commit on what the in-parmams could/should be without getting into coding.
Blocks: 328665
Target Milestone: Camino1.1 → Camino1.2
There's no way I'm gonna be able to fix this any time soon. This code is just too damn nasty.
Assignee: bugzilla → nobody
Status: ASSIGNED → NEW
And if this ever comes about, please make it so that Camino doesn't save files dynamically generated with a file name equal to the name of the script doing the generation, e.g. option-clicking on a link of "image.php?id=1" shouldn't generate a file named image.php as long as a filename can be found in the content-dispostion header.
(In reply to comment #14)
> And if this ever comes about, please make it so that Camino doesn't save files
> dynamically generated with a file name equal to the name of the script doing
> the generation, e.g. option-clicking on a link of "image.php?id=1" shouldn't
> generate a file named image.php as long as a filename can be found in the
> content-dispostion header.

That's a completely unrelated issue. Please file a new bug if you can give examples of Camino ignoring filenames in well-formed content-disposition headers.


Is breaking existing behavior worth it? Why not add an additional shortcut (opt shift return) for bypassing it?
(In reply to comment #16)
> Is breaking existing behavior worth it? Why not add an additional shortcut (opt
> shift return) for bypassing it?

If keeping current behaviour is important, it would be better to add an additional shortcut for current behaviour, since the current behaviour is considered to be inferior.

In other words, that's a fine solution, but the dialog should still go away by default, and be brought back by (for example) the Shift key.

I'm not sure who decided the current behavior was considered inferior by, but as long as the option isn't entirely removed, sure.
(In reply to comment #18)
> I'm not sure who decided the current behavior was considered inferior by

The person who filed the bug, the people who confirmed the bug, and the people who've been working on the bug, among others. :)
(In reply to comment #19)
> The person who filed the bug, the people who confirmed the bug, and the people
> who've been working on the bug, among others. :)

Not necessarily, since the bug merely indicates the current method is inadequate, not inferior.

> Expected Results:  
> Dialogue appears - hoping to be able to bypass this.....

not

> Expected Results:  
> Dialogue does not appear

Again, though, as long as the current behavior is accessible, I'm fine.
In Mac browsers, opt-click has traditionally downloaded the link target (page, file, image, etc.) to the default download location without getting in your way with a dialogue.

I have a download location set; I'm using a *shortcut*; for pete's sake, just download.  That's the way Mac apps work ;)

If I want to do something funky, I should use one of the built-in options for downloading/saving to some other location. ;) 
I'm mostly complaining about it in the URL bar, and doing so in this bug since cl indicated (rightly) that the two behaviors should be linked.

I don't want to download the 8gb uncompressed video clip which someone sent me the link to over IM onto my main HD (which at that time had about 7GB available).

I ended up just using wget, but seriously, I should be able to use my browser to do a simple task like that.
Target Milestone: Camino1.6 → ---
Blocks: 309920
Because this is blocking two other bugs (both of which have p-safari implications), it seems like it's a little more important than just an "enhancement". Raising severity to "normal".
Severity: enhancement → normal
Hardware: Macintosh → All
Erm, enhancement is a type, not an importance, and being p-safari doesn't automatically make current behavior buggy.
Severity: normal → enhancement
I accidentally discovered that Firefox 3.6 appears to do this successfully (although it may be a function of whether they have the wacky-behavior pref off or on) :O

I don't have time to trace the whole thing right now to see what they do, but for reference, here's where it starts, in browser.js's

function handleLinkClick(event, href, linkNode)

http://mxr.mozilla.org/mozilla1.9.2/source/browser/base/content/browser.js#4988

> 4988       if (event.altKey) {
> 4989         saveURL(href, linkNode ? gatherTextUnder(linkNode) : "", null, true,
> 4990                 true, doc.documentURIObject);
> 4991         return true;
> 4992       }

which throws them over to |function saveURL(aURL, aFileName, aFilePickerTitleKey, aShouldBypassCache, aSkipPrompt, aReferrer)| in contentAreaUtils.js: http://mxr.mozilla.org/mozilla1.9.2/source/toolkit/content/contentAreaUtils.js#118, which in turn calls |internalSave|, and that's all the farther I can go right now…
(Which is to say, perhaps there's another way to implement this other than changing all the callers of |nsHeaderSniffer::PerformSave| as comment 11 suggests.)
Firefox's contentAreaUtils.js |internalSave| goes through a few more levels of indirection and eventually ends up in its |internalPersist| function, which sets up a nsIWebBrowserPersist to do the actual downloading.

We could in theory route around |nsHeaderSniffer::PerformSave| and go straight to |nsHeaderSniffer::InitiateDownload| (which is roughly the equivalent of the Firefox |internalPersist|), but it's all pretty much a rat's nest, and, having wasted several hours, pretty much agree with Chris's comment 11, except it's worse than I thought.

For reference, ContentClickListener calls BWC's |saveURL:url:suggestedFilename|, which calls CHBV's function of the same name, which calls CHBV's |saveInternal:withDocument:suggestedFilename:bypassCache:filterView:|, which creates a new nsHeaderSniffer (::OnStateChange-->::PerformSave-->::InitiateDownload, the first and last of which set up nsIWebBrowserPersists), which returns to CHBV's |saveInternal:| to let the last WBP finish saving…

So we'd have to pass the opt key through BWC's method and both of CHBV's methods, and two of SaveHeaderSniffer's, which may well be a lot of callers to change :-(
Status: NEW → RESOLVED
Closed: 1 month ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.