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

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

agreed.

gnbfghf dfgd fgdf

dfafasfasf

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!!

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 on attachment 115687 [details] [diff] [review] Branch Patch is this missing a file in dom/public/idl ?

Comment on attachment 115694 [details] [diff] [review] Branch Patch kin@netscape.com

Comment on attachment 115694 [details] [diff] [review] Branch Patch a=asa (on behalf of drivers) for checkin to 1.3.

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.

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

Modifying summary for better Bugzilla queries.

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

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 ...

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

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.

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

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.

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.

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

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 on attachment 119117 [details] [diff] [review] Patch Asking for reviews from the people who reviewed the previous patch.

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?

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.

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

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

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 on attachment 119140 [details] [diff] [review] Patch v1.1 Let's try and check this in before 1.4 branches.

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);

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

Did this land?

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

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.

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

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