Open Bug 378775 Opened 17 years ago Updated 11 months ago

implement Opera's behavior for selecting text inside of a link and link drag and drop

Categories

(Core :: DOM: Selection, enhancement)

enhancement

Tracking

()

ASSIGNED

People

(Reporter: asa, Assigned: ke5trel)

References

(Blocks 3 open bugs, )

Details

Attachments

(1 file, 7 obsolete files)

Firefox currently requires the use of a modifier key to select text inside of a link. This is not discoverable and suffers from bug 215926.  

We should implement Opera's behavior where click and drag in mostly vertical directions triggers a link drag while click and drag in mostly horizontal directions triggers text selection. 

Not sure if this is an app level bug or an editor bug. Sending to Firefox for triage.

See also bug 50637 for background.
sorry,
see also bug 50673
I find Opera's behavior confusing.  Wanting to drag a link horizontally isn't that uncommon.
(In reply to comment #2)
Pressing keys makes for an inconsistent and arcane interface.  You don't want one method for selecting ordinary text or the whole link and another for selecting part of the link.

Opera's behavior is quite discoverable, and is VERY nice for selecting.  If someone selects when they intended to drag, they will find out instantly and should be able to deal with it.
If Opera's behavior is discoverable, it's because it's surprising and inconsistent.
Assignee: nobody → selection
Component: General → Selection
Product: Firefox → Core
QA Contact: general
What about checking whether mouse up occurs within the link area plus a threshold instead of analyzing the movement. This would allow horizontal drags.
There you go.  Ideally, the direction of the motion should not have anything to do with it.  It's where the mouse up occurs that's important.
I don't understand. How can you use the mouse up location as a differentiator?  If you are selecting text WITHIN THE LINK then won't the mouse up always be WITHIN THE LINK too, or am I missing something?
If the mouse up is within the link, then you MUST be selecting.  If it's outside the link, then the idea is that you are dragging.  (But Opera allows selecting part of the link and other text as well.)

Of course, if mouseup is at the edge of the link, well, that's up to you to figure out -- maybe that's the threshold that Percy Cabello mentioned.  One other problem is that you can't decide whether to highlight or display a dragging hand until either mouseup or you are out of the link.
Yes, that would be the problem. The simple ugly solution could be just to start highlighting until the cursor leaves the link. If it's a drag my guess would be that it's done fast enough that the user won't notice the highlight. 
I really can't understand this idea of watching the mouse-up event. What if I want to select text that goes beyond the link (i.e. starting selection on the link but going further)? And, more importantly, isn't waiting for the mouse-up event a bit late? Selecting text and dragging links produce very different results while the mouse moves, with quite bad results if you take the wrong behavior (clearing the user's selection when he/she just wanted to drag the link, or providing no/wrong feedback when the user expects text to change color).

So, I am in favor of Opera's behavior. Not a very good behavior (it's one of those cases where the application attempts to be too clever), but it sort of works, and, for better or worse, it's still arguably discoverable.

For the record, Safari's text selection/dragging behavior is based on how fast you start moving the cursor after holding down the button: if you hold down the mouse button over a text selection and drag right away, it will start a new text selection; if you hold down the button and wait a bit, it will drag the selection. I'm quite surprised it doesn't do something similar for hyperlinks.
I'm not suggesting this behavior (nor approving it), just mentioning it for the sake of ideas discussion; maybe it could even help someone to find an alternate solution.
In Firefox, if I wish to select text inside a link in order to, say, look it up...I can't. This is absurd. Why can't users select text inside links? This bug should not be marked as "enhancement" but as something more serious.
IMO Opera's behaviour is simple and useful. And I don't think it's inconsistent. A text link is also text. Why I can't select it with a simple left click and move? If you do this currently nothing is performed. Something is better than nothing for me :-)

I don't think it's difficult to implement either. If you left-click on a link, Fx should check the text selection on release. If no text is selected, Fx must perform a click on the link. On the contrary it must leave the selection and stop. I checked and this is also Opera's method.
Flags: wanted1.9.1?
Keywords: ue
Whiteboard: [parity-Opera]
Version: unspecified → Trunk
Ah, for dragging, I think it's simple: if the mouse is out of link's area and no link text is selected, a drag must be performed.
I think this method is even better than Opera's one, because you can drag a link on Opera only if you move the cursor quickly, and I don't understand why.

PS: I think also Fx should have a more obvious icon for drag&drop, when dropping will be not performed. Or it seems you are doing a wrong and useless action.
Flags: wanted1.9.1?
Flags: wanted1.9.1-
Flags: blocking1.9.1-
Assignee: selection → nobody
QA Contact: selection
Selecting text is used orders of magnitude more often than dragging links.

I agree that we should do this.
OK, so I may be able to fix this, but...

There's a problem where if we partially select text in a link, we end up activating that link because we mousedown then mouseup on the same link element (thus causing a click event)

I propose we make click events dependent on the distance between the mousedown and mouseup events. e.g. if they are greater than 5px apart, don't send a click event.

Opera does this, however this will in some cases cause an intentional regression of bug 556493. I looked at the DOM3 events spec
http://www.w3.org/TR/2011/WD-DOM-Level-3-Events-20110531/#event-type-click
and there seems to be nothing strictly illegal about this proposal.

Do any events ppl have any thoughts on this?
Attached patch WIP (obsolete) — Splinter Review
This patch implements Opera's (what will no doubt be controversial) method of suppressing a click event if the mouse moved too much of a distance, in this case it's always 5 pixels, because it is an extremely simple check.

Neil, if you agree with this patch, I'll need to fix up quite a few tests and we will no doubt need to document this in the Firefox 7 for Developers wiki page. Otherwise, your suggestions are much appreciated.
Assignee: nobody → ventnor.bugzilla
Attachment #537094 - Flags: feedback?(enndeakin)
If we start selecting, it is, IMO, ok to not fire click.
But if we don't start selecting, click should fire.
Starting selection could be perhaps thought of the default handling of
such mousemove which fires x pixels away from mousedown.

Unfortunately selection handling isn't standardized at all.
Comment on attachment 537094 [details] [diff] [review]
WIP

You seem to be changing the manner in which the drag target is determined for links. I don't see why that's necessary to implement this.

Also, why are you removing the code in nsHTMLAnchorElement?


+    nsRefPtr<nsFrameSelection> frameSel = mCurrentTarget->GetFrameSelection();
+    if (frameSel && frameSel->GetMouseDownState()) {
+      if (isVerticalDragFromLink) {
+        // We're going to drag a link, so stop the selection
+        frameSel->SetMouseDownState(PR_FALSE);
+      }
+      else if (canInitiateDrag || !isGestureFromLink) {
+        StopTrackingDragGesture();
+        return;
+      }
+    }

If I'm reading this right, it seems to imply that a selection will start only if you drag horizontally less than the drag threshold.

I can't comment on the change to nsEventStateManager::SetClickCount.
(In reply to comment #18)
> Comment on attachment 537094 [details] [diff] [review] [review]
> WIP
> 
> You seem to be changing the manner in which the drag target is determined
> for links. I don't see why that's necessary to implement this.

Sometimes, while beginning to make a vertical gesture, you can select one letter or a similar small amount and we'll drag that selection instead of the link like you wanted. In case you're wondering, Opera does this too.

> Also, why are you removing the code in nsHTMLAnchorElement?

Selection is prevented outright if an element is marked as draggable. We want selection to happen in some cases, so I had to remove it.

> 
> +    nsRefPtr<nsFrameSelection> frameSel =
> mCurrentTarget->GetFrameSelection();
> +    if (frameSel && frameSel->GetMouseDownState()) {
> +      if (isVerticalDragFromLink) {
> +        // We're going to drag a link, so stop the selection
> +        frameSel->SetMouseDownState(PR_FALSE);
> +      }
> +      else if (canInitiateDrag || !isGestureFromLink) {
> +        StopTrackingDragGesture();
> +        return;
> +      }
> +    }
> 
> If I'm reading this right, it seems to imply that a selection will start
> only if you drag horizontally less than the drag threshold.

A selection is always started from nsIFrame::HandlePress, and this function in nsEventStateManager is an opportunity to either stop the selection or the drag. Assuming I understand you correctly, then what you said isn't correct and selection will happen as normal provided the drag gesture isn't vertical.

> I can't comment on the change to nsEventStateManager::SetClickCount.

So smaug's comment is the one to heed?
For nsEventStateManager::SetClickCount could we somehow check if there
is selection in-progress, and only then do the "is mouseup too faraway".

Note Bug 655461 will change click handling, in many ways it just cleans it up.
...but no need to wait for Bug 655461, since it may need still some tweaking.
(In reply to comment #19)

> Sometimes, while beginning to make a vertical gesture, you can select one
> letter or a similar small amount and we'll drag that selection instead of
> the link like you wanted. In case you're wondering, Opera does this too.

I'm not convinced but I'll have to think about this further.

4> 
> > Also, why are you removing the code in nsHTMLAnchorElement?
> 
> Selection is prevented outright if an element is marked as draggable. We
> want selection to happen in some cases, so I had to remove it.

Does Opera also do this?

Considering that the draggable attribute test (test_draggableprop.html) now fails with this patch and that this test doesn't test any mouse behaviour, I'd think that this wasn't the right solution.
(In reply to comment #22)
> (In reply to comment #19)
> 
> > Sometimes, while beginning to make a vertical gesture, you can select one
> > letter or a similar small amount and we'll drag that selection instead of
> > the link like you wanted. In case you're wondering, Opera does this too.
> 
> I'm not convinced but I'll have to think about this further.
> 
> 4> 
> > > Also, why are you removing the code in nsHTMLAnchorElement?
> > 
> > Selection is prevented outright if an element is marked as draggable. We
> > want selection to happen in some cases, so I had to remove it.
> 
> Does Opera also do this?
> 
> Considering that the draggable attribute test (test_draggableprop.html) now
> fails with this patch and that this test doesn't test any mouse behaviour,
> I'd think that this wasn't the right solution.

I'm not sure what Opera does regarding the draggable attribute, but I removed it because nsIFrame::HandlePress checks for this and, as I said before, doesn't even start selection if the element is draggable. That's why I moved all handling for link elements to the event state manager.
this is very annoying issue in FX!! Any chances that this bug will be fixed in FX 6 or 7?
Attachment #537094 - Flags: feedback?(enndeakin) → feedback-
Blocks: 407241
Blocks: 782095
Text highlighting is very important and shouldn't be denied by the link dragging feature. I tried Opera and their method works perfectly, it makes sense to drag links by lifting them vertically first. Would love to see this finally implemented.
have you guys (who are against this change) tried holding a modifier and simultaneously doing a drag on touchpad?
this is driving me insane
(In reply to Michael Ventnor from comment #15)
> I propose we make click events dependent on the distance between the
> mousedown and mouseup events. e.g. if they are greater than 5px apart, don't
> send a click event.

The drag code already does this for draggable links, 5 pixel movement from mousedown initiates drag which suppresses click on mouseup. The alt key also suppresses click when held during mouseup. Rather than repeating the drag test in SetClickCount() just change mLClickCount to zero when link selection starts to prevent a click event.

(In reply to Neil Deakin from comment #22)
> Considering that the draggable attribute test (test_draggableprop.html) now
> fails with this patch and that this test doesn't test any mouse behaviour,
> I'd think that this wasn't the right solution.

Agreed.

(In reply to Michael Ventnor from comment #23)
> I removed it because nsIFrame::HandlePress checks for this and, as I said
> before, doesn't even start selection if the element is draggable.

Altering this check in nsIFrame::HandlePress seems to be a better approach, with a similar result to pressing the alt key. Since we want to select draggable link text an exception is needed using IsDraggableLink().
Attached patch bug378775.patch (obsolete) — Splinter Review
I have attached a revised implementation of vertical link dragging which allows draggable link selection. It has a preference named 'ui.linkDragVertical' so it can be disabled if the user chooses. It passes all DOM event and layout generic tests on Windows 7. 

The synthetic mouse movement in test_dragstart.html is diagonal but sufficiently vertical to trigger the drag event. Nevertheless I changed it to make it clear that links should only be tested for vertical drag.

Mousedown on links now clears any existing selection just like mousedown on normal text. Vertical dragging stops selecting and clears any current selection. Opera 12's implementation has similar behavior.
Attachment #8431473 - Flags: review?(enndeakin)
Comment on attachment 8431473 [details] [diff] [review]
bug378775.patch

>+      // Make it easier to select link text by only dragging in the vertical direction
>+      bool isLinkDraggedVertical = false;
>+      bool isDraggableLink = false;
>+      if (Preferences::GetBool("ui.linkDragVertical", true)) {

I don't think a preference is needed for this.

>+        nsCOMPtr<nsIContent> dragLinkNode = eventContent;
>+        while (dragLinkNode) {
>+          if (nsContentUtils::IsDraggableLink(dragLinkNode)) {
>+            isDraggableLink = true;
>+            // Treat as vertical drag when cursor exceeds the top or bottom of the threshold box
>+            isLinkDraggedVertical = DeprecatedAbs(pt.y - mGestureDownPoint.y) > pixelThresholdY;

I know this was just copied from above, but we should probably not add a new usage of a function called DeprecatedAbs. You could use Abs instead, and for extra points, change the others as well.


>+          if (isLinkDraggedVertical) {
>+            // Stop selecting when link dragged vertically
>+            frameSel->SetMouseDownState(PR_FALSE);
>+            // Clear any selection to prevent it being dragged instead of link
>+            frameSel->ClearNormalSelection();

Why do you add a call to ClearNormalSelection? When I apply your patch I don't see the selection being cleared when I drag vertically. 

>+          } else {
>+            StopTrackingDragGesture();
>+            // Don't register click for link selection
>+            if (isDraggableLink)
>+              mLClickCount = 0;

Why do you add this line?


>   // next, dragging links and images
>-  sendMouseEventsForDrag("link");
>+  // only test vertical drag for links
>+  sendMouseEventsForVerticalDrag("link");
>   sendMouseEventsForDrag("image");

There should also add a test to check that horizontal dragging selects instead.
Attached patch bug378775.patch (obsolete) — Splinter Review
Preference removed.

DeprecatedAbs -> Abs.

> Why do you add a call to ClearNormalSelection? When I apply your patch I
> don't see the selection being cleared when I drag vertically. 

Since selection is enabled for draggable links by default, the 5 pixel movement between mousedown and the vertical drag threshold is sometimes enough to select a single letter which results in it being dragged instead of the link. To prevent this the selection needs to be cleared before DetermineDragTarget.

Dragging an existing selection works normally like before, this code only applies when actively making a new selection. If you exceed the horizontal drag threshold then you have committed to making a selection and vertical dragging is no longer possible for the duration of the selection. The intended behavior can be seen in Opera 12.

> >+          } else {
> >+            StopTrackingDragGesture();
> >+            // Don't register click for link selection
> >+            if (isDraggableLink)
> >+              mLClickCount = 0;
> 
> Why do you add this line?

Click dispatch needs to be prevented when selecting link text (mousedown and mouseup on the same target would otherwise click it), but only for draggable links, otherwise test_bug656379-1 fails on the second last test. "Releasing the mouse over the label should have unpressed (and focused) the button." 

Added horizontal link selection test.
Attachment #8431473 - Attachment is obsolete: true
Attachment #8431473 - Flags: review?(enndeakin)
Attachment #8440379 - Flags: review?(enndeakin)
Comment on attachment 8440379 [details] [diff] [review]
bug378775.patch

>   WidgetMouseEvent* mouseEvent = aEvent->AsMouseEvent();
> 
>   if (!mouseEvent->IsAlt()) {
>     for (nsIContent* content = mContent; content;
>-         content = content->GetParent()) {
>+        content = content->GetParent()) {

Add the space at the beginning back in: content should line up with nsIContent.
Attachment #8440379 - Flags: review?(enndeakin) → review+
Attached patch bug378775.patch (obsolete) — Splinter Review
Attachment #8440379 - Attachment is obsolete: true
Attachment #8445094 - Flags: checkin?
Assignee: ventnor.bugzilla → kestrel
Comment on attachment 8445094 [details] [diff] [review]
bug378775.patch

Do you happen to have a Try link handy for this? :)

Also, please just use the checkin-needed bug keyword instead of setting the checkin flag. Thanks!
Attachment #8445094 - Flags: checkin?
Attachment #537094 - Attachment is obsolete: true
Try pushes seem to have problems with chrome://mochitests/content/browser/browser/base/content/test/newtab/browser_newtab_bug735987.js and browser_newtab_drag_drop_ext.js

https://tbpl.mozilla.org/?tree=Try&rev=24b0ba150c49
https://tbpl.mozilla.org/?tree=Try&rev=c8f1db522249

There are other commits in each of those pushes, but the later has only media patches and this patch.  There could be problem with the tests or the patch, but hard to know without investigation.
The failed tests try to do a horizontal link drag which is no longer possible with this patch. I have modified them to do a vertical drag so they work properly.
Attachment #8445094 - Attachment is obsolete: true
Keywords: uecheckin-needed
https://hg.mozilla.org/mozilla-central/rev/a35fd3284074
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
\o/
Maybe we should relnote this. http://weblogs.mozillazine.org/asa/archives/2007/04/selection_in_op.html suggests changing the cursor to the caret when selecting, which seems sensible.
Depends on: 1034787
Is it possible that this bug is responsible for the problem I'm seeing on the last 2 nightlies? (http://forums.mozillazine.org/viewtopic.php?p=13653701#p13653701 - ctrl+clicking a link gives the same result as ctrl+clicking outside the link - selecting a lot of things around).
(In reply to Guilherme Lima from comment #41)
> Is it possible that this bug is responsible for the problem I'm seeing on
> the last 2 nightlies?
> (http://forums.mozillazine.org/viewtopic.php?p=13653701#p13653701 -
> ctrl+clicking a link gives the same result as ctrl+clicking outside the link
> - selecting a lot of things around).

Is there already a bug for this issue? If yes, which bug number? If not, can you please file an bug? It's a really annoying regression, almost every (!) website is affected…
Depends on: 1035036
Bug 1035036 has been filed for the ctrl+clicking regression.
It's weird. IE, Chrome, and any other browser except opera does that, and firefox has been that way for whenever I started using it. Why you do that? Not to say it is extremely inconsistent. 

It's bad to addon. This change break so many drag & drop addons. I don't understand. Please note, limited the starting direction to horizontal will make 50% of dragging movement cripple for 4 direction move and 75% of 8 direction dragging move.(because diagonal is pretty much useless as well)

I can't even remember the last time I try to select the text of a link, but I open 50% of link by dragging them vertical. Maybe it's a useful feature for someone needed, but sorry, I don't think they are majority, it's a bad move for most user's best interest.
I mean, if there are people want it, and Firefox decide to go for it, it's totally fine. There are bugs I filed for feature wishes too.
But, moving to a behavior so different from the old one,  and the new one is not obvious superb to the traditional practice( exactly case like this), then Firefox should provides a pref to toggle it on/off. Or it's just look like some way to drive users off.
LOL, ok that made me confused for a while. So this bug basically "fixes" selecting text inside of a link. Well good stuff but took me all the way here to discover that I now need to click a link and move mouse EXACTLY up/down direction (or around ~30* away from these directions) to put it into other's window tab. Still You need to work out the precission if it stays or add some information icon so user can tell when he's selecting a link or dragging it, because I first tried clicking all alt's, shift's and ctrl's on my keyboard, cause I thought something got stuck... Also I can't now drag and drop tab into other window's tab (it wants to put itself between them as new tab!), but I dunno what bug or "fix" is causing this - it screws up my TileTabbing a bit...
Depends on: 1040004
I think we should back this out because of regressions, and reland once the patch doesn't cause those
issues.
relnote-firefox is enough to get our attention.
Keywords: relnote
Do we really want this behavior in the first place? Opera no longer have this behavior since Presto is dead.
Whiteboard: [parity-Opera]
The motivation for this wasn't parity with Opera; see comment 0 for what it was instead.
Backout. Please resubmit to the release notes when it is going to land.
relnote-firefox: ? → ---
Merge of backout:
https://hg.mozilla.org/mozilla-central/rev/328ca3cea665
Target Milestone: mozilla33 → ---
Will this feature break all click and drag extensions? If yes, that's too bad. :(
If there are lots of people complaining about click and drag extensions, maybe a setting should be added? Because this feature is very nice, I will definitely use it.
(In reply to xunxun from comment #55)
> break all click and drag extensions?

I have not encountered any problems with drag-related addons, so far I have tested QuickDrag, Drag & DropZones, Superdrag and DragIt and they all function as you would expect. 

DragIt (9,410 users) is the only one with link dragging gestures and all you have to do is a small vertical drag before starting the gesture. The gesture movement amount in pixels can be increased in the settings so the initial vertical drag is not confused as a gesture (I found the default of 10 pixels was too small). However it is easier to use a gesture addon that doesn't require link dragging, like the more popular FireGestures (444,987 users) or All-In-One Gestures (129,623 users) that only require starting a gesture over the link.

(In reply to Tom Schuster [:evilpie] from comment #40)
> http://weblogs.mozillazine.org/asa/archives/2007/04/selection_in_op.html
> suggests changing the cursor to the caret when selecting, which seems
> sensible.

> The only change I'd suggest for Opera is that they actually swap out the hand cursor 
> with the caret cursor as soon as that "decision" is made so that it's more obvious that 
> the mode has changed. 

I originally considered this but it conflicts with standard cursor behavior. The cursor icon is expected to change according to underlying content and making a selection is no exception to this. The only time I can see it making sense is BEFORE leaving the decision zone. A new cursor icon would most likely be required to communicate what is happening.

Another option is to use selection highlighting as feedback like we do already. This only requires hiding selection until after leaving the decision zone (might also be necessary for bug 1040004). The downside is that it will not be possible to make selections within the decision zone (5 pixels; single characters) without leaving it first.
Does it even need to work as old opera? It's not like FF is Opera emulator etc. There can be multiple ways to implement it. Adding visual events could even be some small image under cursor that would make person aware that dragging link the way user always did works in a different way now... Look how Chromium shows it when You d&d then link - though it doesn't have selecting text feature on horizontal move.

Said so, I find that feature of very little importance (or even a bit of annoying - consider person arranging links in tabs very fast, he will most likely end up 50% of time selecting text, lol) for me and would really find it more useful when text selection was triggered by some modifier key, like SHIFT, CTRL or 2 mousebuttons etc.
People, please stop arguing about the feature importance. For example, for me it is very important and I don't drag links at all. Everyone has his own preferences, so please don't clutter the technical discussion about what is more important for his own use.
Well You don't need drag&drop, but I do and it really took me a while to get used to it. So at least there should be a preference to disable link text selection. How would that even work when link had text alignment top-bottom or even other various angles through CSS or/and site zoomed out - was that tested?
(In reply to Mr_KrzYch00 from comment #60)
> So at least there should be a preference to disable link text selection.

Mozilla developers don't want a preference (Bug 254707 Comment 7).

Note also that bug 205754 (selection vs drag and drop for selected text) is similar to this bug, i.e. Opera's behavior should also be implemented on selected text. IMHO, links and selected text should be handled in a consistent way.
IMHO, there should be a preference since obviously within comments some are eager to see it implemented while others hate it.
Also I think the preference should be set by default to original behavior to keep compatibility with other browsers, even if personally I just hate how most browsers select text in link.

Moreover, the text selecting experience is very poor and inconsistent for Fx, IE and Chrome,and selecting text in link is only part of whole problem. It will take major change to current engine to get to full solution and it's very unlikly to happen. A preference may make this patch finally reach us without having to wait another 7 years.

Try:
1) open this page, and skip down to bottom.
2) hover cursor at top left side of text "Format For Printing  - XML  - Clone This Bug  - Top of page"
3) drag right down
4) if you didn't put cursor at start position close enough to text or drag at some direction from straight right, a) fx/ie have chance to select from end of text or even text below b) chrome will select text above c) opera 12 selects text just fine.
Other text appear in table/float/absolute/etc positioning, has link or not, suffer from the problem.

Current ALT key solution is basically not discoverable, and unlike standard modifier key behavior: ALT down->mouse down->ALT up->mouse up. If you select text using standard modifier key's way: ALT down->mouse down->mouse up->ALT up, the page loses focus and menu is called up.
New approach delays selection for links until leaving drag threshold which addresses bug 1035036 and bug 1040004 as well as giving better visual feedback.

* Ctrl and Shift modifiers no longer conflict between opening link and selecting text, clicking opens link, dragging selects text.
* Selection highlight only appears when committed to making a selection.
* Selection prevented for links without text.
* Table selection prevented when clicking links in tables.
* Deselection prevented when clicking on selected links.
* Added test file for link selection issues.
Attachment #8450104 - Attachment is obsolete: true
Attachment #8465642 - Flags: review?(enndeakin)
(In reply to Mr_KrzYch00 from comment #60)
> How would that even work when link had text alignment top-bottom
> or even other various angles through CSS or/and site zoomed out

Dragging is independent of text alignment, text angle or page zoom, beyond 45 degrees rotation it is less intuitive but still usable and is an extreme fringe case.
* Fixed selection for links spanning multiple lines (have to use frame associated with gesture down event for getting offsets).
* Made dragging selected text consistent with links.
* Alt key always selects immediately.
* Improved tests.
* Resolved conflicts with latest head.
Attachment #8465642 - Attachment is obsolete: true
Attachment #8465642 - Flags: review?(enndeakin)
Attachment #8470768 - Flags: review?(enndeakin)
Any switch to disable it just in case in about:config? Not that I much care, moved to SeaMonkey, also Mozilla browser, because lately Firefox is not meeting my customization demands and it's worse and worse as time passes, not to mention memory leaks and other bugs that for some reason don't happen in SeaMonkey for me. I just hope it doesn't land in there so easly. :)
(In reply to Mr_KrzYch00 from comment #66)
> Any switch to disable it just in case in about:config?

A possible workaround that doesn't involve introducing a new preference is to alter the existing drag threshold settings. Making the vertical threshold 1 pixel and the horizontal threshold large prevents selection for almost all drag directions. 

ui.dragThresholdX = 100
ui.dragThresholdY = 1

These preferences don't exist by default in about:config and need to be manually added, the browser also needs to be restarted for them to take effect. The small vertical threshold may be less practical for some.
* Allow link selection to be completely disabled with ui.dragThresholdY = 0 and fall back on ui.dragThresholdX for the threshold value. The logic behind this is that with zero vertical threshold, all drags are treated as vertical, making it impossible to initiate selection with horizontal drag. Alternatively it could be done when X >> 9000 or when X >> Y but I thought Y = 0 would be simpler. 
* Missed some brackets in HandleRelease() which was preventing table cell deselection.
Attachment #8470768 - Attachment is obsolete: true
Attachment #8470768 - Flags: review?(enndeakin)
Attachment #8473611 - Flags: review?(enndeakin)
FYI, I've posted a WIP patch in bug 50673 that implements link selection using Shift+press + dragging.
Comment on attachment 8473611 [details] [diff] [review]
bug378775.patch delayed selection disable via threshold

This could have an updated patch, but it would be useful I think to have some ux feedback first.
Attachment #8473611 - Flags: review?(enndeakin)
I never use "drag link" functionality but I copy text in links very often. So why can't I copy text in links just by selecting it without inconvenient holding of Alt key?

At least some "about:config" flag could be made to fix this behavior.
I'm looking at flags like
"layout.word_select.eat_space_to_next_word" or
"browser.urlbar.clickSelectsAll" or
"browser.urlbar.doubleClickSelectsAll" or
"browser.triple_click_selects_paragraph"
and I can't believe there is still no flag to change this "select text in link" behavior.

I hope it will be fixed soon after this new cool look and feel of new Firefox.
(In reply to Evolgr from comment #72)
> I never use "drag link" functionality but I copy text in links very often.
> So why can't I copy text in links just by selecting it without inconvenient
> holding of Alt key?

Ditto.

For me, an option would be satisfactory. It could have 3 choices, describing the behavior when Alt is not used:
1. Like the current behavior ("drag link").
2. Like Opera's behavior.
3. Select text.

I suppose that (3) could be implemented without much effort by someone familiar with the Mozilla code. (2) could be implemented later (but after 11 years, nothing has been done, thus I doubt it will be implemented soon).

FYI, "Select like a Boss" mentioned in Comment 69 does not work under Linux, and its author never replied to my bug report (and there hasn't been any new version since).
For the record, many people do use link dragging, such as those using mouse gestures. There are some add-ons that allow you to select text in a link in various ways, so I would say perhaps this doesn't need to be enabled by default in Firefox?
(In reply to swleefers from comment #74)
> There are some add-ons that allow you to select text in a link in various ways, [...]

Whether such add-ons are working correctly is another matter. AFAIK, only "Select like a Boss" has been suggested, and as I've said in Comment 73, it doesn't work under Linux.
(In reply to Vincent Lefevre from comment #75)
> (In reply to swleefers from comment #74)
> > There are some add-ons that allow you to select text in a link in various ways, [...]
> 
> Whether such add-ons are working correctly is another matter. AFAIK, only
> "Select like a Boss" has been suggested, and as I've said in Comment 73, it
> doesn't work under Linux.

Additionally, such addons rely on JS, which is suboptimal. This is squarely in native territory. I do, however, agree that this should be opt-in so as to not disturb existing UX.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.