50673 - Can't start/end a selection inside a link or <button>

Status: NEW

(Core :: DOM: Selection, defect, P5)

Description

[Matthew T (active 1999-2002)]

To reproduce:
* Go to <http://news.bbc.co.uk/>.
* Move over the `low graphics version' link at the top of the page.
* Hold down the Shift key, and drag from one end of the word `graphics' to the
  other.

What should happen:
* When the Shift key is held down over the link, the cursor changes to an I-beam,
  and the link no longer appears in :hover style (until Shift is released).
* The drag successfully selects the word `graphics'.

What actually happens:
* The cursor remains as a pointing hand.
* The link is dragged, instead of a selection being made.

Occurs with:
* Mozilla 2000082608 build, Mac OS 9.0

Does not occur with:
* Netscape Communicator 4.7, Mac OS 9.0

Comment 1

[rubydoo123]

setting to future

Comment 2

[Akkana Peck]

Note, this can't be done with shift -- shift-click saves a link, see bug 58283.
I recommend ctrl because alt-click is frequently usurped by window managers on
linux.  Better yet, make it configurable like our other key modifiers.

Comment 3

[Matthew T (active 1999-2002)]

Sorry Akkana, Ctrl+click is taken for opening the link in a new window. If
Shift+click is used for saving on Windows and Linux, it looks like this is going 
to be a Mac-only feature. (Which is what I was trying to avoid ...)

Comment 4

[Akkana Peck]

Any chance we can make ctrl-click select on Unix, since Unix users already have
middle-click to open a link in a new window?  It's silly to have two buttons
doing the same thing while we can't get the select functionality at all.

Comment 5

[Blake Ross]

Sure.

So akkana, what do you think it'll take to implement link selection?

Comment 6

[Akkana Peck]

Well, currently, the drag code takes over when you start a drag (with any
modifiers) inside a link.  So the first step is to find that code and disable it
if modifier bits are set.  Cc'ing pinkerton and blizzard, who might know more
about how the drag code works.

Comment 7

[Alec Flett]

add myself to CC.. I'm doing D&D stuff for the browser

Comment 8

[Mike Pinkerton (not reading bugmail)]

if you want this feature (which doesn't exist in 4.x or IE, btw), it's out of
the realm of xpToolkit. You need to futz around with the JS event handlers the
XPApps team has written that listen for the dragGesture. You also need to fix
gecko to do the right thing with the mouse cursor.

Comment 9

[Blake Ross]

I love to futz.

Comment 10

[Blake Ross]

I have a partial patch for selection within links, but it doesn't make all the 
underlining and links go away.  I'll work on <button>, but it'll be 
significantly harder.

Comment 11

[Matthew T (active 1999-2002)]

[Fixing errors in summary, again. Sorry.]

Akkana, you could change Ctrl+click from {open link in a new window} to
{starting extend selection within a link} on Unix, but not on Windows or Linux, 
since a majority of users of Windows and (I would guess) Linux don't have a 
middle mouse button.

You can't really start or extend a selection using a context menu item, so it 
needs a modifier key if it is to be accessible at all. So what you really have 
(thanks to bug 58283) is a situation where you have both a modifier key and a 
context menu item for each of {opening a link in a new window} and {saving a 
link}, and (as you said) no way at all to start or extend a selection within a 
link.

Mike, this feature exists for links (but not for buttons) on 4.x for Mac, hence 
the 4xp.

Comment 12

[Blake Ross]

Why can't shift+click be save link and shift+drag be highlight?  No one's 
answered this yet.

Comment 13

[Akkana Peck]

That's a good question -- I don't see any reason that wouldn't work, and it
would be easier to rememeber and more discoverable.

Comment 14

[Blake Ross]

Nevermind.  It doesn't work because of contiguous selection...

Comment 15

[Blake Ross]

Attachment: partial patch

Comment 16

[Blake Ross]

Attachment: without the bad formatting this time

Comment 17

[Blake Ross]

Attachment: still bad spacing! try #3

Comment 18

[Matthew T (active 1999-2002)]

As Blake noted, Shift+drag is fine for if you want to start a selection inside a 
link, but it's no good for the other end, if you want to extend an existing 
selection to a point inside a link -- since you will typically Shift+click to do 
so.

Here's my current proposal.

The operation of extended selection will change slightly. Previously, if you had 
an existing selection: (1) if you Shift+clicked, the last-specified end of the 
selection (the `tail') would move to the the place where you clicked; (2) if you 
Shift+dragged, the `tail' would move to the place where you clicked, and would 
update as you continued to drag.

Under my proposal, (2) will change, in that if you drag closer to another entity 
(character or object) boundary than to the one where you mouseddown, the existing 
selection will be cleared and a new one will be begun. And (1) will be delayed 
from mousedown to mouseup, to avoid momentary flashing of spurious selections 
caused by (2). I think the likelihood of anyone noticing either of these changes 
is practically zero.

This change in behavior will be used to allow a selection to be started inside a 
link by Shift+dragging, and ended inside a link by Shift+clicking. Where there is 
not an existing selection, a Shift+click in a link will make a selection from the 
invisible caret position (which defaults to the beginning of the document) to the 
click position, just as a Shift+mousedown in non-link text does now; but a
Shift+drag will instead clear the existing selection (if there is one) and begin 
a new selection.

Comment 19

[Blake Ross]

Alt+drag now selects within a link because it was part of the fix for bug 
48876; but don't worry, this can (and will) be easily changed shortly once a 
final decision is reached here.  What do you all think of Matthew's proposal?

(also, I know that right now the menubar is selected when you release the Alt 
button, on windows anyways.  I'll need to consume the event if we go with Alt, 
but I'm sure we won't)

Comment 20

[Stephan Niemz]

    If my vote counts, Matthew's proposal sounds like a good idea to me.
There is only one thing I'm missing: where did the previous functionality
"Save as" for Shift-Click go?  I definitely could live without it, because
it's also in the context menu, but I suspect many couldn't.

Comment 21

[Matthew T (active 1999-2002)]

Stephan: Saving a link as would be Shift+click on platforms other than Mac 
because of bug 58283, which means this feature would be Mac only (after bug 58841 
is fixed) -- and that in turn, to answer your question in bug 58840, is why bug 
58840 would be a Mac-only enhancement too. Unfortunately, making/extending a 
selection within a link can't really be implemented without using a modifier key; 
that isn't the case for saving a link, but people on Windows and X are obviously 
used to Shift+click saving a link, so they miss out on this feature. :-(

This could conceivably be implemented using Alt+click on Windows, provided menu 
and ACCESSKEY fun is dealt with. But that couldn't be done on Linux because
Alt+click is taken by many X window managers for their own purposes.

Blake: I don't know what others think of my proposal, but I have to admit it 
makes me nervous. I suggest you implement it, but do whatever you need to do to 
make it easy to back out. That way we can test it and find out how much (if at 
all) it affects the look and feel of ordinary selection.

Comment 22

[Blake Ross]

I'm not sure I like the proposal.  Subtlely tweaking standard selection 
behavior doesn't seem good.  And it's not that easy to "just implement this", 
nor would I want to spend the time to do so just to back it out the next day.

Comment 23

[Matthew T (active 1999-2002)]

Well, I apologize for not being certain that no-one would notice the change, but 
I can't guess *everything* in advance. :-)

Any other ideas?

Comment 24

[Blake Ross]

I think the best I will be able to do with this is to allow you to select text 
in buttons if you start dragging outside of the button, not within the button.  
I have no idea how to do the latter.

Comment 25

[Jim Avera]

IMO this is a serious usability issue.  There's bee no activity posted
for about 9 months (last was December 2000). 
Is someone still thinking about the problem.

I gather that the main problem is that, unlike in Netscape 4.x,
dragging the mouse while clicking on a link is supposed to drag
the link somewhere to be dropped, rather than select text
(in Netscape 4.x, Button 2+drag starts a selection and, apparently,
disables following the link as happens if Button 2 goes Down & Up
without mouse motion).

QUESTION: In Linux, Button 2 does not seem to drag links anyway, so
why can't it be used to select as in Netscape 4.x?  I realize that
it would be better to make selection work uniformly in all contexts, 
including extending selections, but as it stands it is
impossible to select the text of an isolated link (at least I couldn't
discover how); 

IMO it would be better to always start a new selection
with Button 2+motion than to not be able to select link text at all.

Comment 26

[Blake Ross]

changing selection qa to tpreston.

Comment 27

[Jesse Ruderman]

*** Bug 142473 has been marked as a duplicate of this bug. ***

Comment 28

[Jesse Ruderman]

Is it really necessary to reserve a modifier for selecting text in a link?  It
may be possible to make shift+click save or open in a new window while still
allowing shift+drag to select text within a link.  See also bug 85169,
"Shift-click should open new browser window", and bug 165584, "change default
pref for Ctrl+Enter to open page in new tab".

Comment 29

[Alfonso Martinez]

*** Bug 201575 has been marked as a duplicate of this bug. ***

Comment 30

[John A.]

any more work on this? There's still interest.

Personally, I miss being able to drag a link to an invalid drop point and have
the link text end up selected for copying. Worked in 1.0x, but stopped working
by 1.4. Still gone in 1.6.

Comment 31

[Vincent Lefevre]

What's the status of this bug? I've been able to select parts of links using the
mod1 modifier (a.k.a. Alt or Meta) with Mozilla under Linux. But with Firefox,
this also downloads the link here (I've been told I'm the only one suffering
from this problem), under both Linux and Mac OS X.

Comment 35

[Dave Webber]

(In reply to comment #31)
> I've been able to select parts of links using
> the mod1 modifier (a.k.a. Alt or Meta [or Option]).... But, ... this 
> also downloads the link here (I've been told I'm the only one suffering
> from this problem), under both Linux and Mac OS X.

You're not the only one "suffering" from this: in Fx 5 on Mac OS X, one can start selection within a link, but if one also ends the selection within the same link, the linked item will be downloaded (although the selection will be correct).

Comment 36

[[:Aleksej]]

Related: bug 215926.

Comment 37

[Sid]

Not an issue since bug 713052 landing.

Comment 38

[Vincent Lefevre]

(In reply to Sid from comment #37)
> Not an issue since bug 713052 landing.

I don't think so. Bug 713052 seems to be about clicking on a link, not dragging over a link. Or could you explain how to start a selection inside a link?

I've tried with any modifiers, and I can't.

Comment 39

[Sid]

(In reply to Vincent Lefevre from comment #38)
> Or could you explain how to start a selection inside a link?

Press and hold Alt, make a selection, release Alt.

Comment 40

[Vincent Lefevre]

(In reply to Sid from comment #39)
> (In reply to Vincent Lefevre from comment #38)
> > Or could you explain how to start a selection inside a link?
> 
> Press and hold Alt, make a selection, release Alt.

This doesn't work: a drag'n-drop of the link is started. I've even tried on the nightly version 22.0a1 (2013-03-12).

Comment 41

[Vincent Lefevre]

(In reply to Vincent Lefevre from comment #40)
> (In reply to Sid from comment #39)
> > Press and hold Alt, make a selection, release Alt.
> 
> This doesn't work: a drag'n-drop of the link is started. I've even tried on
> the nightly version 22.0a1 (2013-03-12).

Actually it seems to be another bug: the Alt key doesn't seem to work in Firefox (no such problem with other applications like Evince or Gnome Terminal - that's under Linux). For instance, with the English version, Alt-F does nothing while it should make the File menu appear.

Comment 43

[Akkana Peck]

Many, perhaps most, Linux window managers intercept alt-click and alt-drag for window manager events (e.g. to move the window when the titlebar isn't visible). Alt-F might be a different issue -- I think there's a separate bug on menu mnemonics and it's handled by different code.

In FF 19.0.2 under Openbox (configured to use the Windows key instead of Alt for window dragging), alt-drag is working nicely to select within a link. Thanks for mentioning it, Sid.

Comment 44

[Vincent Lefevre]

Since a drag is initiated (whatever key modifier is used) when I start dragging from a link, there doesn't seem to be any interception by the window manager.

Comment 45

[Vincent Lefevre]

I think I understand the problem. I've looked at the mousewheel.* about:config options:

  https://wiki.mozilla.org/Gecko:Mouse_Wheel_Scrolling#Mozilla_17_.28Firefox_17.29_or_later

and Firefox differentiates Alt and Meta. I've played with mousewheel.with_alt.action and mousewheel.with_meta.action preferences, and the "Windows key" only acts as Meta here. Perhaps that's the same for dragging over a link. But with other applications, the "Windows key" is fine for operations advertised as requiring Alt.

The problem is that I don't have Alt on my keyboard, as I already use the Alt/AltGr keys as ISO_Level3_Shift for alternate characters (I need both for practical maters). My Xkb config for these modifiers is:

    key <LALT> {
        type = "ONE_LEVEL",
        symbols[Group1] = [ ISO_Level3_Shift ]
    };
    key <RALT> {
        type = "ONE_LEVEL",
        symbols[Group1] = [ ISO_Level3_Shift ]
    };
    key <LMTA> {
        type = "ONE_LEVEL",
        symbols[Group1] = [ Meta_L ]
    };
    key <RMTA> {
        type = "ONE_LEVEL",
        symbols[Group1] = [ Meta_L ]
    };

Changing Meta_L to Alt_L here may break other applications (this did in the past).

Because keyboards only have a limited number of modifier keys, it is really bad to distinguish too many modifiers, unless there are options (like with mousewheel.*) to let the user choose, depending on what is available on his keyboard.

Comment 46

[Vincent Lefevre]

I changed Meta_L to Alt_L in my Xkb config on 2013-03-14. This solved the problem with Firefox and I didn't see any regression in other applications. I think that this should be configurable in some way, as done for other features. See bug 751749 for instance. If it isn't, then *both* Alt and Meta should be accepted (like with other applications), otherwise it may happen that it is not possible to start a selection inside a link with some keyboard configurations.

Note: I think that for the accel key, instead of changing Meta_L to Alt_L, I could have changed the value of ui.key.chromeAccess from 4 to 8 [*]. I don't know whether this would have any effect to selection inside a link...

[*] http://kb.mozillazine.org/Ui.key.generalAccessKey
    http://kb.mozillazine.org/Ui.key.chromeAccess

Comment 47

[Dan Jacobson]

As to if bug 953436 is a dupe of this,
all I know is why can't one copy a few letters out of the middle of my blue name above,
by just using the usual method, no new learning needed.
Instead one ends up 'hauling the whole name off the screen' to where I don't know...

Comment 48

[Vincent Lefevre]

IMHO, it is the same bug (this bug covers wherever inside a link one wants to start a selection). And still with my change of the Meta key to Alt_L done in April (comment #46), I can't reproduce your example from bug 953436, or with your blue name above (e.g. "ni@jid" <- done by copy-paste).

Comment 52

[Mats Palmgren (inactive)]

Attachment: WIP

Here's a stab at fixing this.  This makes it possible to select the link
text using Shift+press + dragging, and Ctrl+Shift+click extends the selection.
Shift+click and Ctrl+click opens a new window/tab as usual.
(As far as I know, we don't currently have any special behavior tied to
Ctrl+Shift+click)

The price is that you can't *start* dragging a link with shift pressed
anymore.  I think most systems allow you to change the type of drag operation
after it started though, so you can start dragging a link without pressing
shift and then press shift later to make it into a "move" operation.
That seems to work on Linux at least with the patch applied.

Comment 54

[Yaron]

(In reply to Mats Palmgren (:mats) from comment #52)

Thanks for your work.

I'd like to make sure I understand it correctly.
Would it be possible to select a link without any key pressed?
If not, are you proposing to replace Alt (the current key on Windows) with Shift?

Comment 55

[Vincent Lefevre]

(In reply to Yaron from comment #54)
> Would it be possible to select a link without any key pressed?

I would like that. I never use link drag and drop in particular because not all applications (e.g. xterm) support it (and it is not possible across desktop pages). So, when I drag over a link, the goal is always to select text.

Moreover, text selection should do text selection, not more. This is currently broken. For instance, try to select the author of a comment on this bug page. In addition to text selection, a menu opens.

Comment 56

[Mats Palmgren (inactive)]

(In reply to Yaron from comment #54)
> Would it be possible to select a link without any key pressed?

No, you would need to press Shift.

> If not, are you proposing to replace Alt (the current key on Windows) with Shift?

I wasn't aware Alt can be used on Windows.  I suspect that's more of an accident than
anything we intentionally designed.  (It doesn't work on Linux which I'm using since
the window manager is using that combo for moving around windows on the desktop.)
If we decide to use Alt+click for some function (like we do for Shift+click and
Ctrl+click) then selecting link text using Alt will likely break.

So, no, I'm not proposing to replace Alt on Windows with Shift.  Shift will be
a complement in that case.

Comment 57

[Yaron]

(In reply to Mats Palmgren (:mats) from comment #56)
> (In reply to Yaron from comment #54)
> > Would it be possible to select a link without any key pressed?
> 
> No, you would need to press Shift.

This bug was opened in 2000.
If you're working on it now, why shouldn't we allow a selection without any key pressed?
Could you have a look at this add-on?
https://addons.mozilla.org/en-US/firefox/addon/select-like-a-boss

It has some issues, but it works fine in general.

Comment 58

[Mats Palmgren (inactive)]

> why shouldn't we allow a selection without any key pressed?

Because breaking dragging of links is a non-starter.

Comment 59

[Vincent Lefevre]

(In reply to Mats Palmgren (:mats) from comment #58)
> Because breaking dragging of links is a non-starter.

This could be configurable.

Comment 60

[janm.l]

ofc dragging links should not be blocked, although I don't know wherefore you need it?

IMAO you should implement it as it is realized in Text Processing Software with "CTRL" and use the Text Select Cursor.

Comment 61

[Neil Deakin]

> I wasn't aware Alt can be used on Windows.  I suspect that's more of an
> accident than
> anything we intentionally designed.

It was intentionally implemented. It is implemented in nsContentAreaDragDrop.cpp

Comment 62

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, 4 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.