Closed Bug 18222 Opened 20 years ago Closed 20 years ago

[DOGFOOD] Paste into form pastes to wrong place

Categories

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

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: jakov, Assigned: saari)

References

Details

(Whiteboard: [PDT+] 12/9 Needs more work)

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.
Component: ActiveX Wrapper → Selection
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."
Component: Selection → HTML Form Controls
Blocks: 19423
Assignee: locka → karnaze
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).
Assignee: karnaze → buster
Reassigning to Steve.
Assignee: buster → akkana
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!
Status: NEW → ASSIGNED
Summary: Paste into html text form messes up! → [DOGFOOD] Paste into form pastes to wrong place
Target Milestone: M12
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.
Assignee: akkana → saari
Status: ASSIGNED → NEW
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.
QA Contact: cpratt → gerardok
Whiteboard: [PDT+]
Putting on PDT+ radar.
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] 12/3
QA Contact: gerardok → ckritzer
I tried the patch above and found I wasn't able to make/see a selection.  :-(
Whiteboard: [PDT+] 12/3 → [PDT+] 12/9 Needs more work
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
This looks to be fixed now
Blocks: 21564
Status: RESOLVED → VERIFIED
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)
No longer blocks: 21564
You need to log in before you can comment on or make changes to this bug.