18222 - [DOGFOOD] Paste into form pastes to wrong place

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P3)

Description

[jakov]

I copied a text into the X11 clipboard, with the intent to paste it into a
form in Mozilla M10.
So I pasted it into the text form. (Actually the form was a bugzilla report.)
The pasted text messed up the text already in the form!
It ended up anywhere in the form.

Using linux 2.2.13, debian 2.1, fvwm1.

Comment 1

[Sean Richardson]

[e-mail], which of these (if one of these it is) do you mean?
(Guessing that more than one may apply)

1. Pasting into a single-line <input> text box like "Summary", the text ends up
   in other <input>s (as well)?
2. Pasting into the <textarea> "Description" text box, the text ends up
   both there and in other <inputs>?
3. Pasting into the <textarea> "Description" text box, the text ends up
   interleaved with with the existing text, rather than all being pasted
   in at the insertion point (caret).
4. The text ends up here, there, aned everywhere, even outside the
   Form Controls.

This looks like it could be a "Form control" component bug, possibly PP
- athough I get a crash on WinNT when I try the same thing, which may have
the same underlying cause.

Tested with: 1999-11-11-08-M12 nightly binary on WinNT.

Comment 2

[Sean Richardson]

The reporter responded by email with the following comment:
>I meant 3.
Based on that, changing component to "Form Controls."

Comment 3

[locka]

I don't know how I got assigned to this since I'm doing the Win32 ActiveX
control, so I've reassigned the bug (hopefully to the HTML form control owner).

Comment 4

[karnaze (gone)]

Reassigning to Steve.

Comment 5

[buster]

assigned to akkana.  sounds like a linux-specific bug, and I'll bet it is/was
just a rendering bug, not a data corruption as the description sort of implies.
could you verify that this worksforme now?  cpratt, it'd be great if you got to
this before akkana!

Comment 6

[Akkana Peck]

Nope, not a repaint problem.  Here's what's happening:

Middle-mouse paste (which I assume is what jakov is using) does a
GetRangeParent() and GetRangeOffset() on the nsIDOMNSUIEvent to figure out where
to do the paste.  This works in the editor (both html and plaintext), but in
form controls, these methods always set their return argument to zero, even
though they return a success code.

I can't test whether this is XP or Linux only, because middle-mouse paste seems
broken on today's Windows build (it used to work).

This is bad -- dogfood candidate.  Middle-mouse paste is how most Unix users
paste (as shown by the fact that the submitter didn't bother to mention it,
since most people on Unix don't paste any other way).  I think this is also a
regression; I'm fairly sure this used to work correctly.

Comment 7

[Akkana Peck]

Here's a little more information:
nsDOMEvent::GetRangeParent calls GetEventTarget on the event state manager. But
GetEventTarget only works if mCurrentTargetContent has already been set, and in
this case, it hasn't been: mCurrentTarget and mCurrentTargetContent are both
null.

mCurrentTargetContent was presumably expected to get set either in
nsEventStateManager::GenerateMouseEnterExit or
nsEventStateManager::SendFocusBlur, but apparently that isn't happening.

Comment 8

[Akkana Peck]

Saari and I went through the event state manager to figure out why
mCurrentTarget was getting nulled.  He came up with a patch that fixes the
immediate problem, though it probably introduces a leak and also requires a
change in the editor:

Index: nsEventStateManager.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/events/src/nsEventStateManager.cpp,v
retrieving revision 1.88
diff -r1.88 nsEventStateManager.cpp
265,267c265,267
<                 nsCOMPtr<nsIContent> newFoo;
<                 mCurrentTarget->GetContent(getter_AddRefs(newFoo));
<                 mLastFocusedContent = newFoo;
---
>                 // nsCOMPtr<nsIContent> newFoo;
>                 mCurrentTarget->GetContent(&mCurrentFocus);
>                 mLastFocusedContent = mCurrentFocus;
269c269
<                 mCurrentTarget = nsnull;
---
>                 // mCurrentTarget = nsnull;

The change in the editor is that the paste handler has to be moved from
MouseDown to MouseUp on the middle button.  Now, this is something that should
probably happen anyway (no particular reason it should be on MouseDown) and I'll
probably do that, but I'm concerned that this means it would be impossible to
get the target for a MouseDown event.  I don't understand why this is the case
since the patch changes PreHandleEvent, so it should be happening before the
MouseDown as well as before the MouseUp ... not sure what's going wrong here.

Comment 9

[leger]

Putting on PDT+ radar.

Comment 10

[Kathleen :Brade]

I tried the patch above and found I wasn't able to make/see a selection.  :-(

Comment 11

[saari (gone)]

This looks to be fixed now

Comment 12

[ckritzer (gone)]

Marking VERIFIED FIXED on Linux6 1999121308 mozilla.

Also tested paste on:
	- MacOS86 1999121308 commercial - behaves correctly
	- Win98 1999121308 mozilla - behaves correctly

Additional note:  Middle Mouse Button n/a on Mac & Win...tested Edit menu-based
paste and Key combo-based pasted (CTRL+V for Win, CMD-V for Mac)