42885 - Paste action fails when the selection was cut|copied from HTML <TEXTAREA>

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P1)

Description

[John Morrison]

While looking at bug #42108, I noticed the following problem. The 
original problem has changed somewhat, so making this a new bug, to 
keep things clear. (This is probably another instance of several 
bugs relating to focus, selection and keybindings).

Overview Description:
  Paste action fails when the selection was cut|copied from HTML <TEXTAREA>

Steps to Reproduce:
1) Copy some text to the clipboard
    a) from another application, or 
    b) from an html <input type='text'> field on a bugzilla bug report

2) set focus in the html:textarea of the bug report, and type Ctrl-V 
   to paste the text. --> This works ** 

3) Now, select some text in the TEXTAREA and do Ctrl-C or Ctrl-X to 
   cut|copy that text

4) Paste (Ctrl-V) into the TEXTAREA --> This FAILS ** 

5) Paste (Ctrl-V) into a <input type='text'> --> This FAILS ** 

Actual Results:
  If the clipboard was loaded by copy|cut from TEXTAREA, the paste
  action fails

Expected Results: y'know ...

Reproducibility: always, cross-platform

Build Date & Platform Bug Found:
  2000061608 win95
  2000061608 linux
  2000061518 mac

Additional Information:

Messages on the windows console (per paste attempt/keystroke):
  nsDataObj::GetData2
  ->>>>>>>>>>>>>> Read Clipboard from memory
  nsDataObj::GetData2
  ->>>>>>>>>>>>>> Read Clipboard from memory
  E_OUTOFMEMORY
  S_OK


Messages on the linux console (per paste attempt/keystroke):
  ->>>>>>>>>>>>>> Read Clipboard from memory
  Transferable didn't support data flavor text/unicode (type = 219)
  ->>>>>>>>>>>>>> Read Clipboard from memory
  Transferable didn't support data flavor text/unicode (type = 320)
  ->>>>>>>>>>>>>> Read Clipboard from memory
  Transferable didn't support data flavor text/unicode (type = 31)
  ->>>>>>>>>>>>>> Read Clipboard from memory
  Transferable didn't support data flavor text/unicode (type = 319)

Comment 1

[John Morrison]

Nom. nsbeta2 : (1) the predecessor to this bug was nsbeta2+, (2) this is 
core functionality (cutting and pasting in HTML forms). 

Comment 2

[Peter Trudelle]

nsbeta2+

Comment 3

[rubydoo123]

setting to m16

Comment 4

[Akkana Peck]

Yes, I see this, too.  Looks like someone broke copying to the clipboard again. 
I'll investigate.

Comment 5

[Mike]

M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 6

[Akkana Peck]

I can't always reproduce this, but it seems to happen much more often when I cut
(^X) than when I copy (^C) and almost never when I just use autocopy.

We never hit the copy methods in editor or pres shell at all (seems like we
should, shouldn't we?)  If I set a breakpoint in
nsXIFFormatConverter::ConvertFromXIFToUnicode, the only time we ever get there
is via nsClipboard::SelectionGetCB, but that only when we're pasting, not when
we're copying, and by the time the paste happens, the original selection is
gone, so the XIF passed in is null and we get the annoying messages about not
supporting the data format (that's a clipboard bug).

The main questions now are:
- Why is SelectionGetCB firing when we paste via ^V?
- Why doesn't ^V call the window controller's paste method, which should route
to the focused widget and eventually call the editor's copy method?

Comment 7

[rubydoo123]

moving over to m17, adjusted priority and severity

Comment 8

[Dave]

pasting fails under 2000062608/Linux with the following messages in the console:


->>>>>>>>>>>>>> Write Clipboard to memory
->>>>>>>>>>>>>> Read Clipboard from memory
Transferable didn't support data flavor text/unicode (type = 300)
->>>>>>>>>>>>>> Read Clipboard from memory
Transferable didn't support data flavor text/unicode (type = 31)


This happened while I was trying to copy text out of a text box such as the one
I'm typing in now (bugzilla bug update) and paste to emacs.


Adding self to cc.

Comment 9

[Akkana Peck]

Saari: do you think this could be one of the symptoms of your bug 42553 ?

Comment 10

[Kathleen :Brade]

this sounds like a duplicate of bug #42625

Comment 11

[Akkana Peck]

It may be, but brade's fix for 42625 doesn't fix this bug, alas.

It may also be related to the linux focus problems discussed in bug 44116.

Comment 12

[Akkana Peck]

Marking dependency -- I think this is strongly related to the focus issues in
42553.

Comment 13

[rubydoo123]

added fix by date in status

Comment 14

[Akkana Peck]

Drat.  I was hoping Blizzard's fixes to gtk focus would fix this bug, but it
doesn't.  Blizzard, do you have any clever ideas what might be happening here?

Comment 15

[Akkana Peck]

It turns out that XBL isn't working right at all.  I grabbed Saari and we spent
quite a while looking at it.  

First, the XBL bindings are all screwed up, and don't include the bindings for
paste.  I have a fix for this and will attach a patch (and will check that part
in asap).

Meanwhile, the key event (whether it's ^X, ^V, alt-X, or alt-V) is okay, and it
gets to lots of different XBL KeyPress handlers, but none of them turn out to
correspond to the currently focused element.  So we see lots of KeyPress calls,
but KeyEventMatched doesn't trigger for any of them, so we don't call the XBL
handler.

But then, sometimes, the right thing happens anyway.  We can't figure out how
that's happening -- there are no cut/paste bindings in XUL, the XBL events
aren't firing, yet if I type ^X, usually the cut works fine (and occasionally it
works for alt-X as well, but almost never for ^V or alt-V).

The mystery continues.  Meanwhile, here's the patch.

Comment 16

[Akkana Peck]

Attachment: Patch for the XBL files

Comment 17

[Christopher Blizzard (:blizzard)]

Ok, should I worry about this or not?

Comment 18

[Akkana Peck]

No (but thanks), looks like it's an XBL keybinding problem, and really on
Saari's and Hyatt's plates.

Comment 19

[Akkana Peck]

Saari agrees that he's probably the best person to own this, and will have to
work with Hyatt to find out what's wrong with the event passing.  I'll stay on
the cc and am available to help with debugging any time.

Comment 20

[Akkana Peck]

Taking this back -- saari and I found a fix for the immediate problem (plus some
other puzzling issues that need to be investigated).

Comment 21

[Akkana Peck]

Progress!  Key bindings are very horked, in lots of different ways, as it turns
out.  For one thing, there are multiple copies of a lot of the relevant key
binding files, and they're all being installed (in different places), and no one
seems to know which one is for what purpose.  For the time being, I've added
cut/copy/paste/undo/redo bindings to ALL of the files I can find, and I think
this will put a band-aid on the symptoms; I have more checkins to do which will
clean this up further, but they affect the installer, so since neither I nor
Chris will be in tomorrow, I'm going to hold off on the checkin until next week.

Comment 22

[rubydoo123]

updating fix by date

Comment 23

[Kathleen :Brade]

I can't reproduce this bug with a mac debug build from today.  I wonder if my fix 
for the double-arrow key events fixed this too (doing a double-cut would probably 
result in an empty clipboard).

Comment 24

[Dave]

copying from the textbox I'm now writing in to emacs now seems to work with
2000062108/Linux whereas it failed with earlier builds... text boxes as a whole
are acting *much* better.

Comment 25

[Akkana Peck]

Finally got all the pieces in so I can mark this fixed.  (There is still a
problem with copying multiple lines from a text control, covered in bug 45996.)

Comment 26

[sujay]

verified in 7/25 build