Closed Bug 57913 Opened 24 years ago Closed 23 years ago

middle-click pasting into unoccupied area of textarea often misplaces pasted text

Categories

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

Product:
Core
Component:
Layout: Form Controls
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.4

People

(Reporter: anthony, Assigned: dbaron)

References

Details

(Keywords: regression, Whiteboard: [selection][textarea] critical for 0.9.4)

Attachments

(4 files)

test case showing wonky pasting.
(deleted), text/html
Details
a bit of an improvement, without major changes
(deleted), patch
Details | Diff | Splinter Review
a sketch of a better patch (not yet working -- see comments in nsFrame.cpp)
(deleted), patch
Details | Diff | Splinter Review
proposed patch, for review
(deleted), patch
Details | Diff | Splinter Review
If you try to use normal X windows pasting (with the middle mouse button) to cut and paste some words in a textarea, and you try to paste it into a blank line, it will instead paste it into the same horizontal position, but in the line above or below (depending on which one you were slightly closer to when you clicked.) This is counter to NS4 behaviour, and almost every other X application I've ever seen. I'd expect it to paste it at the start of the blank line (as NS4 and all the other X apps I can think to try, do). The only way to get it to paste onto the blank line is to click on the far far left _precisely_ at the right point. This is somewhat tricky. I'll attach a test case that makes it easy to play with.
Attached file test case showing wonky pasting. (deleted) —
*** Bug 57914 has been marked as a duplicate of this bug. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm seeing this behavior on Linux with a current CVS build; confirming this bug. What is going on is wierd, in my experiments. This bug only seems to happen in the case where the mouse cursor is further to the right than the end of the text both above and below the blank line. If the mouse is to the left of a line endpoint, it will paste into the blank line relatively fine. If there is a multi-line blank space, only the first line of the multiline space is affected; other lines are 'normal' and can easily be pasted into.
reassigning
Assignee: rods → beppe
reassign to jfrancis; I think he already has a bug on something like this (and maybe a fix already too!)
Assignee: beppe → jfrancis
Target Milestone: --- → mozilla0.9
Things like this make textareas very difficult to use and have been driving me crazy since around the NOXIF landing, I think. Nominating for dogfood, mozilla0.9, nsbeta1.
Keywords: dogfood, mozilla0.9, nsbeta1
This is a selection issue. Handing off to current selection czarina Anthony Davis.
Assignee: jfrancis → anthonyd
accepting bug...i REALLY need to get redhat 7.0 so i can fix my linux box... anthonyd
Status: NEW → ASSIGNED
QA Contact Update
QA Contact: bsharma → vladimire
moving to mozilla 0.9.1 anthonyd
Target Milestone: mozilla0.9 → mozilla0.9.1
Erm, I'm seeing this with further randomness. If I'm doing quite a long bugzilla comment, and I review the text at the top of the textarea by scrolling up, and have the cursor go down line by line as I read, then get to the bottom, and paste some text from another app, _very_ often it will be pasted in the middle of some text from the top of the textarea. This has p*ssed me off so much that some comments I have had to abort. Several people in #mozilla have seen this too, quite a discussion happening right now in there.
moving to 0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Whiteboard: [select]
Keywords: mozilla0.9, nsbeta1
Whiteboard: [select] → [select][textarea]
ok, got with jag (jaggernaut@netscape.com) and he got middle mouse paste working on windows. I will continue my work on this bug. anthonyd
middlemouse stuff is checked in. moving this 0.9.3. anthonyd
Whiteboard: [select][textarea] → [selection][textarea]
Target Milestone: mozilla0.9.2 → mozilla0.9.3
*** Bug 84416 has been marked as a duplicate of this bug. ***
middle mouse functions are quite common reviewed and approved
Keywords: nsBranch
moving out to 1.0
Keywords: nsBranch
Target Milestone: mozilla0.9.3 → mozilla1.0
See also bug 48786, Middle click pasting in textfield inserts at wrong point within field.
Actually, this and bug 48786 are pretty much duplicates, as far as I can see. They're assigned to different people, and this one seems to have more meaningful keywords &c. Not sure on the bugzilla ettiquette w.r.t. marking one or the other as a dupe. (I just want it fixed :)
gee, I should have seen that they were dupes! -- so I will dupe kin's to yours.
*** Bug 48786 has been marked as a duplicate of this bug. ***
Hacky workaround (probably obvious but I'll post it anyway): Create and save text.html: <html> <head> </head> <body> <textarea cols=150 rows=30> </textarea> </body> Load text.html in a new mozilla window. Paste with middle button. Select all, CTRL+X. Switch to other window. Paste with CTRL+V. This works because you are always middle-button-pasting into an empty textarea, hence pasting cannot be misplaced.
Summary should be changed to something like: "textarea middle-button pasting into unoccupied area is wonky" "Unoccupied area" means an area that doesn't have any text in, not even spaces, e.g.: In this diagram . represents spaces: .............foo ^ Occuppied ^Unoccupied
*** Bug 84217 has been marked as a duplicate of this bug. ***
Summary: textarea pasting into the middle of blank lines is wonky. → middle-click pasting into unoccupied area of textarea often misplaces pasted text
*** Bug 91991 has been marked as a duplicate of this bug. ***
*** Bug 93616 has been marked as a duplicate of this bug. ***
If it helps, I'm having some success with this workaround under Linux (using moz0.9.3): As long as the insert point has at least some text to the right (could be a space " "), middle-click insertion seems to work. If I try to insert at the end of a line (common) or the beginning of a new line (also very common), all sorts of wonky stuff happens.
*** Bug 94525 has been marked as a duplicate of this bug. ***
Marking mostfreq (10 dups).
Keywords: mostfreq
Hehe. I was bitten by this (again) just by trying to paste past EOL. Unless you HIT the spaces, it'll still jump around. Not much of a workaround since you have to have god-like aim in order to paste successfully much.
The only reliable way to do pasting in a textarea is to use the keyboard shortcut (^V for me). Middle click is just too damn hairy.
I have noticed something... If you hit ^V then it gets pasted whatever you selected with the keyboard before... So if you use the keyboard to paste something you copied with the mouse, it will NOT print anything, or it will print something you dont want to... So, 2 clipboards? One for the keyboard and one for the mouse? That's what it is happening. I think a target milestone of 1.0 is too high. Can't we try a 0.9.5?
*** Bug 92622 has been marked as a duplicate of this bug. ***
moving 0.9.4 to get this in. anthonyd
Target Milestone: mozilla1.0 → mozilla0.9.4
Hmm I just had an unfriendly experience of this myself. In a bugzilla comment, I typed a few words, hit return, opened a quote, then right-clicked hovering over the opened quote to past in the text I wanted from further down the page. Instead of filling the quotation, it jumped up one line, moved across to the far right edge of the text, then pasted. I hit ctrl+z and undid it, then looked in the edit menu, and non of the "Cut", "Copy" or "Paste" items were enabled. The cursor remained in the correct place throughout, clearly the paste procedure doesn't care where the cursor happens to be... I had to go back down, repeat the selection, use Edit>Copy, then move the cursor in to the open quotation, and hit ctrl+v to paste in the right place. How very frustrating and time consuming.
This is a serious regression.
Keywords: regression
Whiteboard: [selection][textarea] → [selection][textarea] critical for 0.9.4
*** Bug 95877 has been marked as a duplicate of this bug. ***
*** Bug 96292 has been marked as a duplicate of this bug. ***
I think the problem here is that nsBlockFrame needs to override GetContentAndOffsetsFromPoint so that it searches the lines vertically first, then horizontally.
I suspect what made this worse recently was mjudge's change in revision 3.315 of nsFrame.cpp. (In particular, the commenting out of two lines that made the Y distance a more important criterion.) However, I think the correct fix is probably still to override the method in nsBlockFrame.
My second patch was an attempt also to fix the problems of pasting below what has already been typed into the textarea. It didn't work because I ran into problems relating to anonymous content (see comments in nsFrame.cpp in the patch), and I couldn't understand what the current code at the end of GetContentAndOffsetFromPoint was doing. So does the first patch look good? Or does anyone have any ideas how to improve the second?
I'm going to attach a proposed minimal patch for review. kin suggested on IRC this morning that I might want to uncomment the anonymous content check -- however, that seems to make things a little worse. When I uncomment it, pasting in the area below what is typed doesn't move the caret at all. Actually, with the patch I'm about to attach, pasting in the area below what is typed seems to work as expected.
Attached patch proposed patch, for review (deleted) — — Splinter Review
The patch looks good. Commenting out that Y check was a big mistake, I wish he had talked to me before checking that in! Thanks for catching that! The patch also seems to fix some selection auto-scrolling problems I noticed recently, and also fixes bug 57913. sr=kin@netscape.com On another front, I'll need to investigate the problem you mentioned when turning on the anonymous content code in that same routine. That code is needed to prevent cases where selection spans both content in the tree and anonymous content, which can cause crashes like bug 92481. mjudge said he didn't know why he turned it off.
OK, taking so that I can get this in for 0.9.4.
Assignee: anthonyd → dbaron
Severity: normal → major
Status: ASSIGNED → NEW
Priority: P3 → P1
Status: NEW → ASSIGNED
r=bryner
Got a=chofmann by email. Fix checked in 2001-08-26 11:33:57 PDT. Marking as FIXED. Are there any other bugs that need to be split off of this?
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
If what you mean is that you ask for closely related bugs, see bug 97053 that I have just filed: quadruple click should select all the form. If this is not what you mean, sorry for the spam.
Yeah, baby, yeah! :-) Gerv
linux 2001-08-26-22: Works for me. Can't reproduce any of the bad things from before. thankyouthankyouthankyouthankyou.
FWIW, last night I actually did reproduce one of the bad things I'd seen in the past, and if I see it again and figure out any idea of how to reproduce it, I'll file a bug. What I was seeing was that after pasting about ten snippets of multiline text at the end of a textarea, finally, by the last one, it decided to put the text at some random spot in the middle of a line in the middle of the textarea. I don't know if it was a content targetting problem, an editor problem, or what...
Hm. I've seen that behaviour in the past, but I've not been able to reproduce it by the traditional 'clicking like a crazed ferret' method. From memory, it was more likely to occur if the text insert cursor was somewhere other than where you were pasting. The only problem I'm seeing now is that for some reason my text areas have started coming up in a proportional font - hunting for a bug# for that now :)
I wonder if what dbaron is seeing is related to bug 74383. While debugging 74383, I was seeing wierd placement and characters after several pastes, which was the result of stale frame data used during reflow.
I've seen the paste-somewhere-else behavior Dbaron reports, too. I've noticed it most in the Mail composition window. It's much harder to reproduce consistently. Perhaps this should be reported as a new bug, since it's probably unrelated to the current one. (But if you do, please post the bug number here.)
I have posted bug 97207 on a similar paste position problem.
Verified Build 20010082703 os:winNT,win98
Status: RESOLVED → VERIFIED
*** Bug 80476 has been marked as a duplicate of this bug. ***
*** Bug 102211 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: