739071 - Text selection with mouse in input type text impossible if parent node has attribute draggable=true

Status: NEW

(Core :: DOM: Copy & Paste and Drag & Drop, defect, P3)

Description

[Markus]

Attachment: test.htm

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120310010316

Steps to reproduce:

Im a developer. I put a input type text with a prefilled value in a div and made the div draggable=true. I clicked within the text and/or tried to mark the text in the input field.

Test code in attachment.
Reproducable: always.
Test environments:
- Firefox 11.0 on Windows 7 SP1, all updates made
- Firefox 11.0 on Kubuntu 10.11, all updates made


Actual results:

The blinking write cursor stayed at the beginning of the text in the input and i neither was able to select some text with the mouse.


Expected results:

The blinking write cursor should be at the position where i clicked in the text inside the input field and i should be able to select some text in the input field, even if the parent div is draggable.

Comment 1

[Alice0775 White]

There are 2 regression window:
#1 Can select text with mouse dragging, but cannot drag the selected text
#2 Cannot select text with mouse dragging

#1 Can select text with mouse dragging, but cannot drag the selected text
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-08-27+04%3A15%3A00&enddate=2008-08-28+04%3A46%3A00
Triggered by:
Bug 356295 - Drag and Drop (WHATWG)

#2 Cannot select text with mouse dragging
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-09-08+10%3A32%3A00&enddate=2008-09-09+04%3A43%3A00
Triggered by:
ug 452787, change to ignore selection when inside a draggable html element, r=smaug,sr=roc

Comment 2

[bazilio]

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Firefox/26.0

[contenteditable=true] fails too

Comment 3

[Frank Forte]

<div draggable="true">Broken Input Inside Draggable Element<br>
     <textarea>I am broken. Try to place the cursor "here" or select this text. My parent isn't taking good care of me.</textarea>
</div>

Tested on version 35.0 on Windows 7

Comment 5

[Paul Oiegas [:poiegas], PM for (Ecosystem QA, Services QA, WebCompat QA, Ads QA, and Solo QA teams)]

Hi guys,

This issue still reproduces on latest Firefox release (43.0.4) and latest Nightly build (46.0a1-20160113140035). Here is a testcase that you can use to verify it http://jsfiddle.net/k43QZ/1/ .

Considering this I am marking this issue as New.

Thanks,
Paul

Comment 6

[Pavel]

Hi guys, the issue is also reproduced on Mac OS FF v46.0.1

Comment 7

[Andrei Cucea]

Hi guys,

This issue still reproduces on the latest release v50.0 and besides input and textarea, it affects any element with contenteditable="true" attribute inside a parent with draggable="true" attribute.

Thanks

Comment 8

[Anderson Saunders]

Hi everyone,

this still a problem in FF 66.0.1

demo: http://jsfiddle.net/cyus25dj/

in the demo above, notice that in the not-draggable section you can place the cursor wherever you want in the text.
while in the draggable section, the cursor will always go to the beginning.

Comment 9

[Anderson Saunders]

Attachment: html demo of the bug

you can download and open it on firefox to reproduce the bug

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Interesting. The spec does not mention about elements in an element whose draggable is set to true. On the other hand, there is a WPT exactly same as the report:
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/html/editing/dnd/interactiveelements/005.html

So, perhaps, we should fix this.

FYI: On Chrome, the <input> element isn't draggable and can select its text with dragging mouse normally. On Safari, you can put caret at the position, but cannot select the text with dragging mouse.

Perhaps, we should stop climbing up the tree here:
https://searchfox.org/mozilla-central/rev/4f07d49f1c7a823da07e3a231ac87c6435c8fd58/layout/generic/nsIFrame.cpp#4650-4651

Comment 12

[krzysztof.tys]

Hello,

it is still a problem in FF 88.0 (64 bit),

as in comment above, it can be checked in fiddlehttp://jsfiddle.net/cyus25dj/
or
http://jsfiddle.net/k43QZ/1/

Comment 13

[hunter]

Twelve years later, this is still an open issue in FF 116.0.3.