205754 - Need preference to disable drag/drop of selected text.

Status: VERIFIED WONTFIX

(Core :: DOM: Copy & Paste and Drag & Drop, enhancement, P5)

Description

[Robert La Ferla]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030514
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030514

When you are composing/editing a message, you can inadvertently move text with
the mouse unintentionally.  It is most annoying.  Need option to "Disable
drag/drop of text" in Preferences->Composer.


Reproducible: Always

Steps to Reproduce:
1.  Compose a new message.
2.  Type a few sentences.
3.  Select one of the sentences.
4.  Click and hold mouse button and drag text around.

NOTE:  The problem is that while you are editing you may do this unintentionally...



Actual Results:  
Text is moved.

Expected Results:  
It did what it should BUT there should be an option to disable this
functionality in the Preferences->Composer menu.

Comment 1

[Kathleen :Brade]

future, helpwanted

Robert La Ferla--you can always do "undo" to get back to previous state when you
accidentally move or drop data in wrong location.

Comment 2

[Robert La Ferla]

I am fully aware of "undo".  That's not my point.  If you look at Microsoft
Office, for example, they have this same drag/drop text feature as an option. 
This is because some people like it and others do not.  I personally do not like
it and it just gets in my way.  Too often, I go to select some text and
accidently move it.  I would like to disable this feature.  However, I can see
why some other people may want to use it so I think it's best left as an option.

Comment 3

[ben]

please add this feature!!  

the current drag/drop settings prevent me from selecting text inside of an
existing selection, which i have a habit of doing frequently!  i personally
prefer that my computer not inhibit my style of text editing...

Comment 4

[Bob Firth]

--> severity: enhancement

Comment 5

[Wayne Mery (:wsmwk)]

the option to disable selected D&D would likely have to apply to the entire product (which I can't imagine happening), composer is html editor, so -> General

Andrew? would involve core (editor)?

Comment 6

[Andrew Schultz]

how different is this from bug 152080?

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to comment #6)
> how different is this from bug 152080?

tempting dupe - it would probably resolve his issue. But I think bug 152080 is more far reaching.  

IMO the bug should not have been confirmed.   no dupes, no cc, no votes.

Comment 8

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 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.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 9/19-9/27)]

I don't think we should add a pref to disable DnD of selected text. So, I think this should be marked as WONTFIX.

On the other hand, if this is reasonable for some people using a11y features, I think it's worthwhile to implement. Jamie, do you have any ideas about that?

Comment 10

[James Teh [:Jamie]]

I can't really think of any reason that this disproportionately impacts folks with accessibility needs. I asked Anna Yeddi on my team for her thoughts as well. Here's what she said (edited slightly by me):

As someone pointed out 17 years ago, there has been no dupes, CCers, or upvotes. In 22 years since the bug was created, there were just the reporter and another user, both 22 years ago.  A few points:

1. General technology change: While the technology did not change since back then, I assume user may be now more aware of drag’n’drop functionality and also users probably do not try to select text inside of the selection because it never works (cannot think of any app/tool/software where it would work in 2025).
2. It’s easily reversible by commonly used means: In both cases, easy to avoid by an undo command or a shortcut and by clicking elsewhere to remove the selection or moving the focus away
3. Pointer cancelation (extension to the point above): While it would not apply to users who are not aware of the dragging action starting, it is still possible to cancel the action by pressing Esc key
4. OS-level solutions are available: Users of laptops are probably more aware of this dragging problem with their touchpads, but this could and probably is resolved on the OS level by disabling or lowering the sensitivity of the touchpad. One would assume that this behavior would be affecting all apps, thus a need for a special case for a browser is questionable.

I think, while it may affect someone who relies on keyboard alone and shares their machine with a mouse user or has a laptop with enabled and probably sensitive touchpad, there are ways to work around it and this would probably affecting not only text editing in Firefox, but an entire user’s environment on their machine.

Let's wontfix this. Worst case scenario, someone would reopen it or file a new bug and we could review the modern use case for it again.

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 9/19-9/27)]

Thank you for the deep analysis!