WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
10169
REGRESSION: NativeTextArea: Text dragged from <input type=text> to textarea disappears
https://bugs.webkit.org/show_bug.cgi?id=10169
Summary
REGRESSION: NativeTextArea: Text dragged from <input type=text> to textarea d...
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.
Top of Page
Format For Printing
XML
Clone This Bug