194802 - Cannot drag and drop text from or to textarea or input

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[John Keiser (jkeiser)]

You cannot drag text from a textarea.  This is a regression of bug 185889.  bug
193568 comment 29 has info on this.

Comment 1

[John Keiser (jkeiser)]

This probably should be a blocker; leaving it up to drivers to decide.  Note
that bug 193568 was a very similar blocker.

Comment 2

[Asa Dotzler [:asa]]

agreed.

Comment 3

[Ariel Arjona]

gnbfghf  dfgd fgdf

Comment 4

[José Jeria]

dfafasfasf

Comment 5

[Zook Valem]

If you're going to CC yourself into this bug report.  Just enter your email
address into the CC textbox only.  

There is no need to use the  'Additional Comment'.  Just leave the 'Additional
Comments' blank and there's no need to type in the 'gnbfghf  dfgd fgdf' or
'dfafasfasf' because Bugzilla will automatically CC you to the bug report
without the 'Additional Comments'.  This will prevent Bugzilla from spamming
everyone's email and from overloading the email server with un-necessnary
emails....   Thank you!!

Comment 6

[John Keiser (jkeiser)]

Attachment: Branch Patch

This fixes the problem for 1.3.  I don't think we want the full fix for 1.3
given the near deadline.  The full fix is to set originalTarget itself, but
that breaks ctrl+v paste for some reason; that indicates to .  This fix targets
drag and drop only.  Some other things may be broken still, but at least now we
have a better idea what the set of broken stuff is--setting originalTarget
could create an unknown set of problems.

Comment 7

[Brian Ryner (not reading)]

Comment on attachment 115687 [details] [diff] [review]
Branch Patch

is this missing a file in dom/public/idl ?

Comment 8

[John Keiser (jkeiser)]

Attachment: Branch Patch

Comment 9

[kinmoz]

Comment on attachment 115694 [details] [diff] [review]
Branch Patch

[e-mail]

Comment 10

[Asa Dotzler [:asa]]

Comment on attachment 115694 [details] [diff] [review]
Branch Patch

a=asa (on behalf of drivers) for checkin to 1.3.

Comment 11

[John Keiser (jkeiser)]

Fixed on 1.3.  Not fixed on trunk yet, still trying to resolve the ctrl+v
problem with the .originalTarget patch.  Removing blocking1.3 so that it goes
off of the blockers list.

Comment 12

[John Keiser (jkeiser)]

Putting blocking1.3+ back up at Asa's request.

Comment 13

[Jason Bassford]

Modifying summary for better Bugzilla queries.

Comment 14

[Jason Bassford]

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

Comment 15

[bugzilla.mozilla.org]

so, my bug #197187 has ben marked a duplicate of this one. Sure it is the same
issue?

This here goes about textarea and just one direction: "from". But I reportet
errors with all text edit form elements.

If it's the same then you should remove the "from" from the subject and mention
INPUT elements too. No wonder I could not find this one when searching for
duplicates ...

Comment 16

[John Keiser (jkeiser)]

to works fine.  from is what is broken.  Don't feel bad about filing a
duplicate; we appreciate that people file at all.

Comment 17

[John Keiser (jkeiser)]

hmm, funny, some "to" works and some doesn't.  Dragging the URL by clicking the
little Mozilla next to the URL bar works ... dragging HTML from the page into
the textarea does not.

Comment 18

[John Keiser (jkeiser)]

Dragging text works (try dragging from a text mail message) and HTML does not. 
I am not clear if that is intentional or not.

Comment 19

[Jason Bassford]

Holy Mid-air collisions.   I've been trying to clarify this for a while now. <grin>

It doesn't simply do "nothing", the UI actually draws the circle with the line
through it symbol.

Comment 20

[John Keiser (jkeiser)]

Which indicates that the thing being dragged cannot be dropped onto the
textarea.  It would be best to test that against an older version (1.2) and see
if the same behavior occurs.  I have a sneaking suspicion it does.

Comment 21

[bugzilla.mozilla.org]

I even cannot drag text around within a text area like this one here where I'm
typing the comment. And I did this all the time with builds before 1.4x

Also I know I could select text anywhere on a page and in form fields and drag
it into other form fields. this would copy the text into the second field -
input or textarea

Comment 22

[John Keiser (jkeiser)]

Attachment: Patch

All right, this ports the 1.3 patch to trunk.  I really don't have time to set
originalTarget to this and catch the inevitable regressions until at least 1.5.
 Let's get this working again.

Comment 23

[John Keiser (jkeiser)]

Comment on attachment 119117 [details] [diff] [review]
Patch

Asking for reviews from the people who reviewed the previous patch.

Comment 24

[Johnny Stenback (:jst)]

Ouch! This is pretty nasty, do we really want this on the trunk? How about
waiting for a 1.4 (and 1.4b) branch and landing this there only, and leaving
this bug open while waiting for the real fix?

Comment 25

[John Keiser (jkeiser)]

I'd be fine with that, but I'm not clear that I'll even have time to get this
into 1.5.  There is a good deal of debugging to do (fixing .originalTarget seems
to break control+character keypresses in the url bar, for example) and a good
deal of regressions that will occur.  I have a *lot* of printing work to do
between now and then.

If you like I can remove the word "tmp" from it and land that. 
realOriginalTarget is not a bad solution per se, but I'd prefer to try and fix
it by setting .originalTarget correctly.

Comment 26

[John Keiser (jkeiser)]

Attachment: Patch v1.1

This version adds some comments and a [noscript] suggested by jst.

Comment 27

[Johnny Stenback (:jst)]

Comment on attachment 119140 [details] [diff] [review]
Patch v1.1

sr=jst

Comment 28

[Hermann Schwab]

It is late for asking, I know.
This has been patched in 1.3 branch only, so wouldn´t we get a regression if
this is not patched in Trunk or 1.4b?
Patch with r/sr is available from start of April.

Comment 29

[John Keiser (jkeiser)]

Comment on attachment 119140 [details] [diff] [review]
Patch v1.1

Let's try and check this in before 1.4 branches.

Comment 30

[(not reading, please use [e-mail] instead)]

Comment on attachment 119140 [details] [diff] [review]
Patch v1.1

a=sspitzer, 

fyi, here's something you might want to do, per dmose:

instead of:

+    *aRealEventTarget = mTmpRealOriginalTarget;
+    NS_ADDREF(*aRealEventTarget);

do:

+ NS_ADDREF(*aRealEventTarget = mTmpRealOriginalTarget);

Comment 31

[John Keiser (jkeiser)]

"eww".  I hate when people put assignments inside an expression.

Comment 32

[Asa Dotzler [:asa]]

Did this land? 

Comment 33

[John Keiser (jkeiser)]

Fix checked in.  How should we handle resolution?  RESOLVED / FIXED and open a
new bug?  Remove blocking1.4+?

Comment 34

[Asa Dotzler [:asa]]

Opening a new bug for remaining issues would be ideal. If that's a pain then
don't bother, I'll just flag this one with a status whiteboard marker to pull it
off my radar. 

Comment 35

[John Keiser (jkeiser)]

This bug is indeed fixed.  bug 206904 filed on the other issue.  re-setting
blocking1.4+ for future reporting.

Comment 36

[Patrick]

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