395888 - After drag-dropping text to other textarea, the dragged textarea has no caret

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect)

Description

[Martijn Wargers (dead)]

Attachment: testcase

See testcase, to reproduce the bug:
- Drag some text from textarea1 to textarea2 with the mouse
- Now click on textarea1 again

Expected result:
- Caret appears and blinks like it normally does

Actual result:
- No caret appearing

This seems to have regressed between 2006-04-17 and 2006-04-18, so apparently a regression from bug 287813.

Note that ideally textarea2 should get the focus after the drag-dropping operation, that's bug 280635 (if you could fix that, that would be even better!).

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

I have a partial patch that might fix this bug (I haven't even compiled it yet). My initial suspicion is that this might be fallout from bug 390228.

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Proposed fix

I'd worried about this earlier -- apparently the order of the dragexit/dragdrops is not necessarily backwards from the order of the dragenters (seems obvious now). This patch makes the presshell remember its caret so the editor can just tell it that it's done with the drag indicator, thereby removing ordering problems.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 281012 [details] [diff] [review]
Proposed fix

great!

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: What was checked in

I realized that I'd forgotten to bump nsIPresShell's uuid.

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

Fixed on trunk.

Comment 7

[Martijn Wargers (dead)]

Verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007092305 Minefield/3.0a9pre

But with slightly different steps, I can still reproduce a similar bug, I filed bug 397283 for it.