Guys, we need to decide which modifier+click on a link will save it: alt or shift? See bug 12056. Present your arguments, and let the war begin...
If I could cc: jwz, I would. Shift+leftClick has saved since Mozilla/1.0, on Unix anyway. My fingers will thank you if that continues in Mozilla/5.0 (user agent speak here -- I mean "in the trunk builds, soon"). My fingers will hunt you down and strangle you if you break their memory. I have no idea what usability dictates. I am skeptical that there is one true answer for all platforms. Compatibility matters, even if jwz was following a Motif guide here. /be
I'm for history. Shift-Click.
Eugene, you baffle me. Less than two weeks ago, in n.p.m.ui, you said you agreed to Matthew's comment that alt+click should be used for saving the link. cc'ing kerz who has an interest in this also.
Really? Just do not count my vote - I do not use it anyway. I wait for CTRL+click. :) Sorry...
i'd prefer the 4.x way, too: i vote for shift+click --tho' shift+click doesn't do anything on 4.75 on Mac; option+click does save there. cc'ing akkana and jag to see what they think. would it be possible to implement shift+click on unix and win32, but have option+click on mac, to be consistent w/4.x?
sounds like a shift click party all around... everyone so far agree's with me (or i agree with them) that shift click is the way to go. Yay, shift click!
I would vote for Shift+Click on Unix. Alt+Click is often a windowmanager shortcut for something like "lower window". I believe that that is the default binding for MWM.
Sarah, I suppose that's possible. We already do cmd+click for opening in a new window on mac. But I don't know if there's currently a way to identify if Option is pressed (unless that's what we call Alt for the mac). Maybe Akkana can shed some light there... I also throw my support towards shift+click, fwiw. I've heard and understand all the reasons presented in the newsgroups for shift+click to select text in a link and alt+click to save the link, but I still think that backwards compatibility with a prominent accelerator overrules all of them...
I like shift-click because I'm used to it and suspect users won't discover alt-click, but OTOH shift does make sense for selecting within a link and I'd love to have that behavior (I'm forever frustrated at not being able to do that) and users won't discover that if it's on alt-click either. I won't get into the religious war, I'll be happy if we have both behaviors on any key and document them. Assuming that we'd be doing this save-as definition in JS, it's trivial to get the modifier set and then key off the accel pref, the current platform, some other pref, or any number of other things. Harder is selection and link behavior: if we want to make shift-drag or alt-drag not follow a link, that behavior is hardwired in layout and we either need to use platform #ifdefs (blech ptui, please let's not do that) or pref it. Or change layout so that if any modifier is set, it doesn't follow or drag links, which might be the best option.
Oh, just read Boris' comment. Yes, that's true, I use alt-click myself as a windowmanager control. So I'd like to be able to use shift- and control-click (or meta-, if we ever get that working) so I can have both behaviors.
Akkana: yes, we're doing the save-as et. al in JS. I have the patch all ready to checkin if the tree ever clears up. Agreed that it would be easy to pref this and make platform-specific distinctions if that's the route we decide to go. Why isn't meta-click working now? It seems like it is. Do you know anything about how we can tell if option is pressed, though, per sairuh's request?
For key events on linux, gtk doesn't set a flag for the meta key, though it does give us a keyup and keydown, so we could implement it by tracking those. (It does set the meta bit on some Sun systems, apparently.) It's possible (but seemed unlikely to me) that it does set a modifier bit for meta key on mouse events.
I think option on mac maps to alt in our event system; cc'ing brade to get a definite answer.
.. yet another vote for shift-clicking fingers.. 4.x on both windows and unix do this, and have for as long as _I_ can remember. Windows 4.x has an odd side effet in that it ALSO extends the current selection, at the same time as saving the link, but think that's a bug in 4.x...
So are we going to have the following, then? Mac OS Windows, Linux/Unix -------------------------------------------------------------------------- open link click click open link in new window Command+click Ctrl+click open in window behind current Command+Shift+click Ctrl+Shift+click save link Option+click Shift+click* save link in last-used folder Option+Shift+click Alt+Shift+click* extend selection not in a link Shift+click Shift+click* make/extend selection in a link Shift+click Alt+click* It is the inconsistency of the *ed items which prompted me to suggest that Windows and X use Alt+click for saving the link and Shift+click for making the suggestion. Those items break the usual rule of a Shifted combo performing a variation of the command performed by the unShifted combo (e.g. Ctrl+S = Save, Ctrl+Shift+S = Save As, Ctrl+F = Find, Ctrl+Shift+F = Search Messages). They don't seem to have much rhyme or reason behind them at all. I appreciate that this breaks backward compatibility, but I would hope that the number of people who will use Mozilla in the future is greater than the number of people who have used it in the past. So I would suggest that making the modifiers more intuitive for future users is more important, and I would volunteer to be hunted down and strangled if that was necessary to make them more intuitive. :-) With Mozilla currently having (hopefully) the smallest user base in its lifetime (past or future), and with users' memories of Shift+click being dulled by Netscape 6.0x (and Mozilla thus far) not having this feature at all, now would be the ideal time to change to a more internally consistent set of modifiers.
Sorry, `Shift+click for making the suggestion' --> `Shift+click for making the selection'. By the way Blake, this is the second time you have started this discussion, the first time being in n.p.m.ui. If you want to start it for a third time, in a forum where I will be unable to to present my arguments *at all*, I suggest you use IRC. ;-)
Matthew, I was asked to create this bug so it could be discussed in a way that everyone would be held accountable for their arguments. Your arguments are wanted, and that is why you were cc'ed from the bug's creation.
I also suggested to Blake that the newsgroup thread be re-started. I did say that newsgroup consensus is influential, but not decisive (for one thing, there is no one person tending the code as the change gets used and liked, or not liked, who is accountable for such a "decision"). mpt wrote "Those items break the usual rule of a Shifted combo performing a variation of the command performed by the unShifted combo..." and I am at a loss trying to figure out how selecting a run of characters from a link is performing a variation on the usual action associated with clicking the link. What about "variation" am I missing that so demands shift+click-as-selection-gesture rather than as save-link? Wasn't there another argument, that some word processors use shift+click that way? Mozilla/5.0 (user-agent version speak) may have the fewest users to annoy with an incompatibility, but Netscape has more. IE seems to have no modified click for save to file, from my quick test: shift+click opens in new window. Sorry if I missed mpt or someone else mapping out all the popular browsers' behaviors. /be
Shift is often used with a keyboard combo to perform a variant on the command performed by the unShifted combo, whereas Alt is hardly ever used in this way. Using Shift+click to save a link means this rule is broken -- because Alt, rather than Shift, is used as the extra modifier to specify the variant save command of saving immediately in the last-used directory (without showing a save file dialog). That is one side of the argument. The other, as Brendan suggested, is the general convention (in all apps that have selectable objects) that Shift is used to make or extend a selection. Under the scheme I mapped out for Windows and Linux/Unix (which is the best I can make it while still using Shift+click for saving, though others are welcome to offer alternative schemes), the usual modifier for making or extending a selection in file managers, word processors, spreadsheets etc -- the Shift key -- is *replaced* by Alt if the text happens to be in a link. That makes very little intuitive sense at all. And if a user does use Alt in this way, but accidentally clicks before releasing the Shift key from his previous use of Shift for selection, he will immediately download the link without intending to! Ouch. Microsoft Word uses Shift+click to allow selection of text in a hypertext link, rather than opening the link, just as I am suggesting for Mozilla. Similarly, the Mac OS Finder uses Shift+click when in single-click-to-open mode to allow selection of an item, rather than opening the item. From the discussion in n.p.m.ui it appears that Windows Explorer does not provide any modifier key for the same purpose, though it does offer Shift as usual for extending a selection. On the Linux/Unix side, I would be interested in finding out what modifier key Nautilus uses (or will use) to select an item when in single-click-to-open mode; but given that it is full of ex-Apple people with a clue, I wouldn't be at all surprised if Nautilus will use Shift for this purpose like the Mac OS Finder and MS Word do. When I referred to the number of Mozilla users being at its minimum now, I was including Netscape users in that tally. I suggest that changing the modifier to be more consistent (both with other modifiers, and with other apps) now would cause less temporary hurt from relearning than changing it at any other time. This is especially the case since a sizable chunk of Mozilla users (those using the Netscape 6.0 distribution, and those who have been using mozilla.org builds thus far) will not have (had) a modifier for saving a link at all, allowing them to unlearn Shift+click (if they were Windows or Linux/Unix users) before the new modifiers arrive. I should also note that the use of Shift+click for selection is completely harmless to those who were expecting it to do something else -- so those who do not completely unlearn Shift+click will not come to any grief. :-) If Shift+click is used for selection rather than saving, I also plan on filing an RFE to temporarily remove the underlining from links when the Shift key is held down -- so as to indicate that clicking on a link will select link text, rather than following the link. (Temporarily removing the underlines would also be useful, of course, for allowing the user to easily read links which consist of large chunks of text.)
Doing a quick survey of the unix apps people around here commonly use as regards selection extension: StarOffice: shift-click, same as MS Word, by design Lyx: no way to extend selection that I can find xterm: right click emacs: right click Mozilla: shift-click Netscape 4.x: no way that I can find gnumeric: no way that I can find There is no real standard here, is there? I still think that the biggest problem with Alt-click is that many windowmanagers use it as a shortcut. As a result, whatever functionality is mapped to Alt-click will effectively become unreachable for a number of people. I hesitate to suggest that this behavior be pref-able, because I don't know how difficult that would be to do.
Yes, this would be easily pref-able, but I don't want to do that. I want to see if we're able to reach at least one final decision in this project without just adding another pref.
Too many window managers on linux/unix use alt+click as a window manager function. You will break them, or force linux/unix users to remap the keys for their window managers if you use alt+click. This is not good. Why not... Shift+click on a link = save Shift+click not on a link = extend selection.
when a decision is reached, the patch for this is attached to bug 58333...
To answer Akkana's question way back... yes, in our event system, the option key on mac is known as "alt" (most Mac keyboards have both "alt" and "option" on these keys).
The only problem I see with Matthew's table of actions is that it leaves Unix users two ways to open in new window (middle-click and ctrl-click; three if you count the context menu) and no way to make/extend selection in a link (since alt-click is usurped by window managers), something which seems much more useful. I would therefore vote for ctrl-click to make/extend selection on Unix, since Unix users will have a middle mouse button and can use that to open in a new window (which is the behavior users expect from 4.x). Whereas in 4.x/unix, ctrl-click just opened the link, like a click without any modifiers, so users won't be expecting it to open in a new window.
Matthew, I thought you said Shift+Click was selecting text within links in 4.x and Word. But in my win32 copies of 4.x and Word2k, that's not the case - 4.x it just doesn't work, and in Word, it's Ctrl+Click that lets me do that.
The overwhelming consensus here seems to be shift+click. If someone really feels that strongly about having alt+click, let me know and...well..sorry.
So shift-click saves (wonderful, for all those of us who are used to it). What about selecting within a link -- did you check in anything for that, or is that a separate bug (and if so, which one)?
Yes, shift+click now saves. There's currently no code to handle the selection within a link, it's just if (event.altKey); I would be happy to help implement that, but I'd probably need some hand-holding since I'm not all that familiar with selection code. The bug for that is bug 50673.
Akkana: Windows and Linux users do not necessarily have three-button mice, so using Ctrl+click for selection inside a link (or <input type="submit"/>, or <button>, for that matter) will leave no method of opening a link (or form submission) in a new window. Blake: By 4.x and Word, I was referring to 4.7 for Mac OS, and MS Word 98 -- I was not aware that Word 2000 used different modifiers for selecting text depending on whether you were inside or outside a link. Since this seems to have been decided, filed bug 58841 for maintaining 4xparity on Mac (Option+click).
*** Bug 58743 has been marked as a duplicate of this bug. ***
verified on winnt and linux [2000.11.21.08] that shift+click link will save the link.