Option-click links doesn't save file

VERIFIED FIXED in mozilla1.0

Status

()

P3
normal
VERIFIED FIXED
19 years ago
8 days ago

People

(Reporter: devsin, Assigned: bugzilla)

Tracking

(Blocks: 1 bug, {helpwanted})

Trunk
mozilla1.0
PowerPC
Mac System 9.x
helpwanted
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

19 years ago
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.

Comment 1

19 years ago
Does option-click work that way in 4.x?
(Reporter)

Comment 2

19 years ago
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

Comment 5

19 years ago
Bill, is this a regression?
Assignee: don → law
Whiteboard: [rtm need info]

Comment 6

19 years ago
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.

Comment 7

19 years ago
OK, let's minus it then.
Whiteboard: [rtm need info] → [rtm-]
(Reporter)

Comment 8

19 years ago
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).
Keywords: relnoteRTM
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. ***

Updated

19 years ago
Blocks: 50673
(Reporter)

Comment 12

19 years ago
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.
(Assignee)

Comment 13

19 years ago
reassigning to me
Assignee: law → blakeross
Target Milestone: --- → mozilla1.0
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

19 years ago
OS: All → Mac System 9.x
Hardware: All → Macintosh
(Assignee)

Comment 14

19 years ago
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.
(Assignee)

Comment 17

19 years ago
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.
(Assignee)

Comment 19

19 years ago
...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...

Comment 21

19 years ago
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.

Comment 22

18 years ago
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
(Assignee)

Comment 24

18 years ago
Posted patch patch (obsolete) — Splinter Review
Keywords: relnoteRTM, rtm → patch
Whiteboard: [rtm-] relnote-devel relnote-user → relnote-devel relnote-user

Comment 25

18 years ago
lookin' good!
sr=alecf

Comment 26

18 years ago
Shouldnt this be closed now since it was checked in? :)
Keywords: nsCatFood
Keywords: nsdogfood
(Assignee)

Comment 27

18 years ago
Yup. Thanks for the reminder.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 28

18 years ago
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.
(Assignee)

Updated

18 years ago
Target Milestone: mozilla1.0 → mozilla0.9.3
(Assignee)

Updated

18 years ago
Target Milestone: mozilla0.9.3 → mozilla0.9.4
(Assignee)

Updated

18 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5
(Assignee)

Updated

18 years ago
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.

Updated

18 years ago
Blocks: 104166
(Assignee)

Updated

18 years ago
Target Milestone: mozilla0.9.6 → mozilla1.0
(Assignee)

Updated

18 years ago
Target Milestone: mozilla1.0 → mozilla1.2

Comment 31

18 years ago
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.
(Assignee)

Comment 32

18 years ago
Umm...what checkin...?

Comment 33

18 years ago
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. ***
Keywords: nsbeta1
(Assignee)

Comment 35

17 years ago
-> default owner
Assignee: blaker → aaronl
Status: ASSIGNED → NEW
Target Milestone: mozilla1.2 → ---

Comment 36

17 years ago
-> saari, for retriage
Assignee: aaronl → saari

Comment 37

17 years ago
nsbeta1-, per ADT triage team
Keywords: nsbeta1 → nsbeta1-

Comment 38

17 years ago
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.

Comment 39

17 years ago
-> 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

Updated

17 years ago
Target Milestone: --- → mozilla0.9.9

Comment 40

17 years ago
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
(Assignee)

Comment 41

17 years ago
Attachment #21028 - Attachment is obsolete: true
Attachment #27214 - Attachment is obsolete: true

Updated

17 years ago
Keywords: nsbeta1 → nsbeta1+

Comment 42

17 years ago
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+

Updated

17 years ago
Whiteboard: relnote-devel relnote-user → have patch, relnote-devel relnote-user
(Assignee)

Comment 43

17 years ago
-> me

sdagley, you tested the fix and it worked?
Assignee: sdagley → blaker

Comment 44

17 years ago
Blake, y, that patch works for me.  You've got my r=, you just need sr= and a=
to land it.

Comment 45

17 years ago
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?
(Assignee)

Comment 46

17 years ago
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 47

17 years ago
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.
(Assignee)

Comment 50

17 years ago
fixed.
Status: NEW → RESOLVED
Last Resolved: 18 years ago17 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
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.