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

NEW
Unassigned

Status

()

Core
Selection
17 years ago
a year ago

People

(Reporter: Matthew Paul Thomas, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 2 bugs)

Trunk
Future
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

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

17 years ago
setting to future
Target Milestone: --- → Future

Comment 2

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

Comment 3

17 years ago
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 ...)
Summary: Can't start a selection inside a link → Can't start/end a selection inside a link or <button>
(Reporter)

Updated

17 years ago
Blocks: 58840
Depends on: 58841
Keywords: 4xp

Comment 4

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

17 years ago
Sure.

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

Comment 6

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

17 years ago
add myself to CC.. I'm doing D&D stuff for the browser
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

17 years ago
I love to futz.
Assignee: mjudge → blakeross

Comment 10

17 years ago
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.
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla1.0
(Reporter)

Comment 11

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

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

Comment 13

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

17 years ago
Nevermind.  It doesn't work because of contiguous selection...

Comment 15

17 years ago
Created attachment 18693 [details] [diff] [review]
partial patch

Comment 16

17 years ago
Created attachment 18694 [details] [diff] [review]
without the bad formatting this time

Comment 17

17 years ago
Created attachment 18695 [details] [diff] [review]
still bad spacing! try #3
(Reporter)

Comment 18

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

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

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

Comment 21

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

Updated

17 years ago
Depends on: 55686

Updated

17 years ago
Priority: P3 → P2
Target Milestone: mozilla1.0 → mozilla0.9

Comment 22

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

Comment 23

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

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

Updated

16 years ago
Target Milestone: mozilla0.9 → mozilla1.0.1

Updated

16 years ago
Priority: P2 → --
Target Milestone: mozilla1.0.1 → Future

Comment 25

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

16 years ago
changing selection qa to tpreston.
QA Contact: blaker → tpreston

Comment 27

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

Comment 28

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

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

Comment 30

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

12 years ago
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.
Assignee: bross2 → selection
Status: ASSIGNED → NEW
QA Contact: tpreston
Duplicate of this bug: 408617
Assignee: selection → nobody
QA Contact: selection

Updated

9 years ago
Duplicate of this bug: 407241

Updated

7 years ago
Duplicate of this bug: 546363

Comment 35

6 years ago
(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).
Depends on: 378775

Comment 36

4 years ago
Related: bug 215926.

Comment 37

4 years ago
Not an issue since bug 713052 landing.

Comment 38

4 years ago
(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

4 years ago
(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

4 years ago
(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

4 years ago
(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.

Updated

4 years ago
Duplicate of this bug: 850032

Comment 43

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

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

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

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

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

4 years ago
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).

Updated

4 years ago
Duplicate of this bug: 953436
Duplicate of this bug: 1247118
Duplicate of this bug: 494177
Created attachment 8718195 [details] [diff] [review]
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.
Attachment #18693 - Attachment is obsolete: true
Attachment #18694 - Attachment is obsolete: true
Attachment #18695 - Attachment is obsolete: true
Duplicate of this bug: 407241
Blocks: 565512

Comment 54

a year ago
(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

a year ago
(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.
(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

a year ago
(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.
> why shouldn't we allow a selection without any key pressed?

Because breaking dragging of links is a non-starter.

Comment 59

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

This could be configurable.

Comment 60

a year ago
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.
> 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
You need to log in before you can comment on or make changes to this bug.