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?]
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
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.
nominating for dogfood (from sdagley's list of bugs that are good candidates for our next release)
Keywords: relnoteRTM, rtm → patch
Whiteboard: [rtm-] relnote-devel relnote-user → relnote-devel relnote-user
lookin' good! sr=alecf
Shouldnt this be closed now since it was checked in? :)
Yup. Thanks for the reminder.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 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.
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.
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.
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: nsbeta1 → nsbeta1-
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
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
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.
Status: NEW → RESOLVED
Last Resolved: 18 years ago → 17 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.