Bug 10169

Summary:

REGRESSION: NativeTextArea: Text dragged from <input type=text> to textarea disappears

Product:

WebKit

Reporter:

jonathanjohnsson

Component:

Forms

Assignee:

Darin Adler <darin>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

adele, darin

Priority:

Keywords:

Regression

Version:

420+

Hardware:

Mac

OS:

OS X 10.4

URL:

http://bugzilla.opendarwin.org/enter_bug.cgi?product=WebKit

Attachments:

Description	Flags
editing cleanup patch that fixes this bug (needs change log, tests)	none
editing cleanup patch that also fixes this bug, including change log and test	justin.garcia: review+

jonathanjohnsson

Reported 2006-07-31 07:58:45 PDT

If you drag text from any <input type="text"> element to a textarea (e.g. from URL: to Description: on the bug report page), the text disappears from the input element, but doesn't enter the textarea. Instead, nothing is added to the textarea, and it becomes "semi-selected" -- it gets the blue square, but not the cursor.

Attachments
editing cleanup patch that fixes this bug (needs change log, tests) (175.82 KB, patch) 2006-08-05 13:00 PDT, Darin Adler	no flags	Details Formatted Diff Diff
editing cleanup patch that also fixes this bug, including change log and test (198.94 KB, patch) 2006-08-23 17:00 PDT, Darin Adler	justin.garcia: review+	Details Formatted Diff Diff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.

Darin Adler

Comment 1 2006-08-04 06:48:05 PDT

The problem here is in WebCore::Frame::appliedEditing. When you drop the text into the <textarea>, the new select is inside the <texarea>. So the appliedEditing function ends up focusing the <texarea> when setSelection is called. But it's only after that when dispatchEditableContentChangedEvent is called. There are other things wrong too, for example, if the selection delegate refuses to change the selection then we won't communicate where the change took place, which is incorrect. Whether the selection moves or not is unimportant. I'll try rearranging code to fix this.

Darin Adler

Comment 2 2006-08-05 13:00:22 PDT

Created attachment 9893 [details] editing cleanup patch that fixes this bug (needs change log, tests)

Darin Adler

Comment 3 2006-08-23 17:00:20 PDT

Created attachment 10186 [details] editing cleanup patch that also fixes this bug, including change log and test

mitz

Comment 4 2006-08-23 22:33:21 PDT

Comment on attachment 10186 [details] editing cleanup patch that also fixes this bug, including change log and test + // FIXME: Ugh, don't want delays in layout tests! + eventSender.leapForward(400); leapForward() works by offsetting the timestamps on subsequent events, so there's no delay.

Justin Garcia

Comment 5 2006-08-23 23:20:30 PDT

Comment on attachment 10186 [details] editing cleanup patch that also fixes this bug, including change log and test r=me

Darin Adler

Comment 6 2006-08-24 09:46:43 PDT

(In reply to comment #4) > (From update of attachment 10186 [details] [edit]) > + // FIXME: Ugh, don't want delays in layout tests! > + eventSender.leapForward(400); > leapForward() works by offsetting the timestamps on subsequent events, so > there's no delay. OK. Great. I'll remove that comment.

Darin Adler

Comment 7 2006-08-24 15:01:54 PDT

Committed revision 16026.

Note You need to log in before you can comment on or make changes to this bug.