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.

jakov@vmlinux.org, 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.

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

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).

Reassigning to Steve.

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!

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.

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.

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.

Putting on PDT+ radar.

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

This looks to be fixed now

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)