Closed Bug 55686 Opened 22 years ago Closed 20 years ago

Option-click links doesn't save file

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

PowerPC
Mac System 9.x
defect

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: devsin, Assigned: bugzilla)

References

(Blocks 1 open bug)

Details

(Keywords: helpwanted, Whiteboard: have patch, relnote-devel relnote-user)

Attachments

(1 file, 2 obsolete files)

Mozilla M18 2000100608, Mac OS 9.0.4 -

1) Option-click on a link
2) The file/document is loaded in the browser

When you Option-click a link, it should be saved to disk.
Does option-click work that way in 4.x?
Yep. It's a way to get around the snafu of having unmapped or incorrectly mapped 

MIME types. Just option-click to download the link to disk.

[note to self: check out if alt+click does this on other platforms. or, was that
a mac-only (pp) thing in 4.x?]
Keywords: 4xp
yep, alt+click link will prompt use to save the link on linux and win32. marking
all/all.

i don't know how trivial or difficult this would be to implement --if easy, i
nominate for rtm. if not...helpwanted.
Keywords: helpwanted, rtm
OS: Mac System 9.0 → All
Hardware: Macintosh → All
Bill, is this a regression?
Assignee: don → law
Whiteboard: [rtm need info]
No, it is not a regression.  This has never been possible due to the way Gecko
handles link clicks.  It decides to go to the link on its own, regardless of the
shift key state, or what Navigator might want to do.

See also bug 12056.

I don't think we should hack a fix for this for rtm.
OK, let's minus it then.
Whiteboard: [rtm need info] → [rtm-]
Note: several websites instruct users to use this method to download files to
disk. If it's not supported in Netscape 6, these websites will have to be
updated (else either the website author will receive a lot of email or there
will be a lot of bug reports about this).
Nominating for both relnote types, for the two facets of this problem.

Gerv
Whiteboard: [rtm-] → [rtm-] relnote-devel relnote-user
Dup of bug 58841, or vice versa.
*** Bug 58841 has been marked as a duplicate of this bug. ***
Reposting mpt's comments from bug 58841 (now that this behavior has been
implemented (albeit incorrectly)):

> On Mac OS, the modifier key for saving a link should be Option+click
> rather than Shift+click.

> As well as preserving 4xp, this will allow the modifier key for making
> or extending a selection to be Shift consistently whether the cursor is
> inside or outside a link or button (bug 50673).

I 100% agree with this. Option-click is the method expected by users and web
developers and should be maintained.
reassigning to me
Assignee: law → blakeross
Target Milestone: --- → mozilla1.0
Status: NEW → ASSIGNED
OS: All → Mac System 9.x
Hardware: All → Macintosh
Attached patch [patch] use option-click on mac (obsolete) — Splinter Review
Personally I'm thinking yuck... I dislike this hackish platform detection code in multiple places... Especially since there'll be more places where different platforms will want special treatment.
r=bzbarsky, for what it's worth.
cc'ing alecf for sr

jag, this isn't really hackish.  you just suggested replacing it with IsMac() 
or some such, but that's still doing the same 'hack' (with a cleaner name), and 
it requires pulling in a file for one tiny function.
Yes, but placing it inside an isMac() function makes cleaning up the hack easier
later. Also, I don't see what your objection is to pulling in a file, assuming
the files are decently factored.
...There are currently two uses of this (navigator.platform.indexOf) in all of 
LXR, three with my patch.  My objection is that, as Ben said, pulling in a file 
for a function that has the potential to be 1-2 lines long isn't worth it...for 
performance and just logical reasons.
Hrm, I interpreted Ben's comment as being about factoring out code into platform
specific files/overlays.

I still say it's yucky, but if everyone else says this is the best way to do it
I'll just grmbl quietly...
wait, the correct way to do this, IMO, is to add a preference to all.js that's
overridden by macprefs.js... then there is no platform-specific stuff in our
code, just our preferences.
I think we should try to get this in, nsbeta1.
Keywords: nsbeta1
nominating for dogfood (from sdagley's list of bugs that are good candidates for 
our next release) 
Keywords: nsdogfood
Attached patch patch (obsolete) — Splinter Review
Keywords: relnoteRTM, rtmpatch
Whiteboard: [rtm-] relnote-devel relnote-user → relnote-devel relnote-user
lookin' good!
sr=alecf
Shouldnt this be closed now since it was checked in? :)
Keywords: nsCatFood
Keywords: nsdogfood
Yup. Thanks for the reminder.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
This does not work on Mac. On Mac, option-click should save the link target to a 
file, and command-click should open it in a new window. The latter works, the 
former does not.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
same observation as smfr using 2001.05.22.09 moz bits.

addendum: tested on linux, and shift+click in both 4.x and mozilla save the link 
[contrary to my 2000-10-09 14:32 comment, heh], which is expected.
Target Milestone: mozilla1.0 → mozilla0.9.3
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Status: REOPENED → ASSIGNED
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Not clear from the comments if this was checked in or not...  It doesn't work on
Fizzilla if it was.
Blocks: 104166
Target Milestone: mozilla0.9.6 → mozilla1.0
Target Milestone: mozilla1.0 → mozilla1.2
This (or another checkin, but this looks most likely) seems to have broken
shift-click to save on Unix.  I'll reassign that bug to blake.
Umm...what checkin...?
Oh, I got the dates messed up.  You had checked in code that changed the way
this feature worked, but it was quite a while ago so it probably wasn't
responsible for this problem.  Don't know what was, then ...
*** Bug 97884 has been marked as a duplicate of this bug. ***
-> default owner
Assignee: blaker → aaronl
Status: ASSIGNED → NEW
Target Milestone: mozilla1.2 → ---
-> saari, for retriage
Assignee: aaronl → saari
nsbeta1-, per ADT triage team
Keywords: nsbeta1nsbeta1-
Whaaa. Option-click is my knee-jerk reaction to download files that spew binary 
into the browser window. Without this, I have to laboriously inspect the context 
menu for the relevant item.
-> sdagley for consideration. Steve, if you contest this not being nsbeta1+,
please bring it up with EDT. Simon, you could bring it up also (I suggest going
to a EDT meeting)
Assignee: saari → sdagley
Target Milestone: --- → mozilla0.9.9
I agree we really want this (I hit it a _lot_) but it's not gonna make the 0.9.9 
train
Keywords: nsbeta1-nsbeta1
Target Milestone: mozilla0.9.9 → mozilla1.0
Attachment #21028 - Attachment is obsolete: true
Attachment #27214 - Attachment is obsolete: true
Keywords: nsbeta1nsbeta1+
Comment on attachment 70048 [details] [diff] [review]
does this fix it...?

r=sdagley (since Blake submitted the patch and it Does The Right Thing™ for me)
Attachment #70048 - Flags: review+
Whiteboard: relnote-devel relnote-user → have patch, relnote-devel relnote-user
-> me

sdagley, you tested the fix and it worked?
Assignee: sdagley → blaker
Blake, y, that patch works for me.  You've got my r=, you just need sr= and a=
to land it.
Comment on attachment 70048 [details] [diff] [review]
does this fix it...?

Wait, are you changing Linux/Windows to match mac behavior?

is saveModifier some sort of pref?
Yes:

saveModifier = pref.getBoolPref("ui.key.saveLink.shift");

So if that's set, we use shiftKey.  Otherwise, we use altKey.  The mac pref file
overrides this to false, it's true on linux/win. The cause of this bug is just
my confusion over our event system's name for mac's option key. I thought it was
metaKey (apparently), but it's altKey.
Comment on attachment 70048 [details] [diff] [review]
does this fix it...?

sr=hewitt
Attachment #70048 - Flags: superreview+
Comment on attachment 70048 [details] [diff] [review]
does this fix it...?

a=shaver for 1.0 trunk.
Attachment #70048 - Flags: approval+
a=shaver for the branch, too.
fixed.
Status: NEW → RESOLVED
Closed: 21 years ago20 years ago
Resolution: --- → FIXED
vrfy'd fixed using 2002.03.06.08 comm bits on mac 10.1.3. thanks a lot, blake!
Status: RESOLVED → VERIFIED
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.