Steps to reproduce: 1) Go to the URL 2) Drag a file to the file upload control, passing over the Description text field on the way over Results: A drag caret appears in the text field when the mouse passes over it, but does not disappear when the mouse exits the field, nor when the file is dropped on the control. The caret should disappear as soon as the mouse exits the field.
This was most likely caused by <http://trac.webkit.org/changeset/45064>.
<rdar://problem/7014793>
Confirmed that reverting r45064 and r45065 fixes the bug.
I found bug 24731 which is unlikely to be related, but reminded me of this bug.
Hum. I'm not sure how the caret is supposed to be set back when the mouse exits. Maybe before the dragging over other random parts of the page always returned "None" I'll have to try this in the debugger.
I owe you a fix for this. I'll look today.
Eric: any update?
Created attachment 34010 [details] An update for smfr --- 6 files changed, 33 insertions(+), 7 deletions(-)
Oh, did this never land?
I think this was the patch I was trying to land when run-webkit-tests started failing with the zsh error for me. Will land now.
Comment on attachment 34010 [details] An update for smfr Clearing review flag on attachment: 34010 Committing to http://svn.webkit.org/repository/webkit/trunk ... M LayoutTests/ChangeLog M LayoutTests/fast/forms/drag-into-textarea.html M LayoutTests/fast/forms/drag-out-of-textarea.html M WebCore/ChangeLog A WebCore/manual-tests/drag-caret.html M WebCore/page/DragController.cpp Committed r46792 M WebCore/ChangeLog M WebCore/page/DragController.cpp A WebCore/manual-tests/drag-caret.html M LayoutTests/ChangeLog M LayoutTests/fast/forms/drag-out-of-textarea.html M LayoutTests/fast/forms/drag-into-textarea.html r46792 = 9d9d45a380de61fd378173cac93fd81b2b9c865f (trunk) No changes between current HEAD and refs/remotes/trunk Resetting to the latest refs/remotes/trunk http://trac.webkit.org/changeset/46792
All reviewed patches have been landed. Closing bug.
This was also causing random crashes at page teardown time (usually in Node::isDescendantOf()).
I'm confused by ap's comment. This was successfully fixed, yes? You were just noting this had other symptoms, no?
Yes.