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.
673 bytes, text/html
Details
a bit of an improvement, without major changes
1.81 KB, patch
Details | Diff | Splinter Review
a sketch of a better patch (not yet working -- see comments in nsFrame.cpp)
14.28 KB, patch
Details | Diff | Splinter Review
proposed patch, for review
1.77 KB, 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.

    
    

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

    
    

    
  
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: