187650 - option-return in URL bar should download the link

Status: RESOLVED FIXED

(Camino Graveyard :: Location Bar & Autocomplete, enhancement)

Description

[Michael Zajac]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20021227 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20021227 Chimera/0.6+

In the browser, option-click on a link or option-return on a focussed link
begins a download.  

Currently, option-clicking adds a [CR] in the URL bar, which is of no use. 
There seems to be no way to download a URL that I've copied from another
application without displaying it in the browser window, so this behaviour would
add functionality.  

Reproducible: Always

Steps to Reproduce:
1 Copy an URL from somewhere.
2 Paste it into the URL bar.
3 Hold the option key and press the return key.

Actual Results:  
A [CR] character is added in the URL bar.  You can now scroll up and down in it
using the arrow keys.

Expected Results:  
Chimera should have begun a download of the URL to disk.

Running on Mac OS X 10.1.5.

Comment 1

[Stephane Moureau]

See Bug 155863, for consistency

Shift-Return : for a quick download.

Cmd-Return : open selected link in a New Window
Opt-Return : open selected link in a New Tab

I did not check AAHIG, but doing the same also with the Enter key would be good too.

Comment 2

[S Woodside]

I like this idea. I would have found it useful already for download links that
have the wrong content-type set on the server.

Comment 3

[Mike Pinkerton (not reading bugmail)]

while it shouldn't necessarily d/l the link, we should load the url just like
normal return.

Comment 4

[Gabriel Radic]

Great idea, anyone on this?

Comment 5

[Chris Lawson (gone)]

I'll see what I can work out in the next week or so. Someone with privileges can
assign this one to me, and then if I haven't posted at least a preliminary patch
within a week, someone yell at me. :)

cl

Comment 6

[Chris Lawson (gone)]

OK, I've got some logging code in there and I'm watching what keystrokes get
sent to performKeyEquivalent (in BrowserWindow.mm).

If I simply type a URL (or its first few characters) and hit return, I get no
NSEvent triggering. I get sent to the proper URL.

If I hold down option and hit return, nothing happens. I get an opt-return
(whatever Unicode character that is) inserted in the location bar. No NSEvent is
triggered at all, it seems.

If I hold down command and option and hit return, I get the URL opened in a new
tab, as per my preference. If I look for NSAlternateKeyMask in the resultant
NSEvent, it's there, as expected.

I may not be understanding NSEvent's notifications, but I've got no idea at all
why this is happening. Anyone?

cl

Comment 7

[Wevah (Nate Weaver)]

Perform key equivalent is only for command-key combinations. You should probably
be testing [NSApp currentEvent] in the location field's action selector instead.

Comment 8

[Wevah (Nate Weaver)]

(In reply to comment #7)
> Perform key equivalent

Err, performKeyEquivalent: .

Comment 9

[Wevah (Nate Weaver)]

Er...that won't work anyway, because option-return is caught too early (I think).

Comment 10

[Stuart Morgan]

Chris, take a look at http://developer.apple.com/documentation/Cocoa/Conceptual/TextEditing/Tasks/InterceptKeys.html

It covers a couple of ways of doing what you want to do.

Comment 11

[Chris Lawson (gone)]

Attachment: traps opt-return/enter and fires a save

This should do it.

cl

Comment 12

[Chris Lawson (gone)]

Re-targeting for 1.0 now that we have a patch.

cl

Comment 13

[Chris Lawson (gone)]

Attachment: don't leak the URL string, break up into two lines for clarity

Forgot to autorelease the string copy. Woops.

cl

Comment 14

[Samuel Sidler (old account; do not CC)]

-> 1.1

Comment 15

[Stuart Morgan]

Comment on attachment 209189 [details] [diff] [review]
don't leak the URL string, break up into two lines for clarity

r=me

Comment 16

[Mike Pinkerton (not reading bugmail)]

+  [bwc saveURL:nil url:[[[self string] copy] autorelease] suggestedFilename:nil];

who is responsible for not messing up if the string changes, the caller or the callee? what pattern do we generally follow here? 

Comment 17

[Stuart Morgan]

Good point; the underlying function that saveURL:suggestedFilename: calls creates its own internal representation of the URL, so it doesn't matter what happens to the original. The copy can be removed.

Comment 18

[Chris Lawson (gone)]

Attachment: no more copying strings

Here ya go, guys.

cl

Comment 19

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 213970 [details] [diff] [review]
no more copying strings

sr=pink

Comment 20

[Mike Pinkerton (not reading bugmail)]

landed trunk and 18branch