Closed Bug 58283 Opened 24 years ago Closed 24 years ago

Shift+Click or Alt+Click on a link to save it?

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9

People

(Reporter: bugzilla, Assigned: bugzilla)

References

Details

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...
.
Assignee: don → blakeross
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.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
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.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
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.
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.