Closed Bug 45996 Opened 24 years ago Closed 24 years ago

can't paste multiple lines from a text control

Categories

(Core :: DOM: Selection, defect, P3)

Product:
Core
Component:
DOM: Selection
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: spam, Assigned: mjudge)

Details

(Keywords: regression, Whiteboard: [nsbeta2+][dogfood-] [FIX IN HAND]) 

Test this:

in a bug-form's comment field:
-type something - a few lines
-select it
-copy it
-try to paste it into the same form again

Result: you can't - nor can it be pasted into anything else i've found.

getting heaps of "
Transferable didn't support data flavor text/unicode (type = 220)
Transferable didn't support data flavor text/unicode (type = 476)
Transferable didn't support data flavor text/unicodode (type = 475)

Test 2:
Select text from a webpage in browser
Place cursor at end of some text in a comment-form like this
Paste

This "kind" of text will paste OK, but the insertion point you had selected with
cursor will NOT be the one used - the pasted text lands somewhere else.

FWIW: I also get quite a lot of crashes these days while writing in bug-forms,
Not 100% reproducable, but when it crashes, it's using the backspace that
triggers it. Mentioning this since it CAN be related to the insertion point
being messed up.
reassigning as per request
Assignee: mjudge → akkana
Summary: selection and insert points in forms confused → selection and insert-points when pasting in forms is confused
Accepting.  Anyone know when this regressed?
Status: NEW → ASSIGNED
And additional observation regarding the text copied from forms:
It won't paste into composer either, but when attempting that, instead of the
"untransferrable" error, i get this funny output in console:

->>>>>>>>>>>>>> Read Clipboard from memory
->>>>>>>>>>>>>> Write Clipboard to memory

A paste should hardly WRITE to memory??
--

Additional observations - perhaps worth a new bug..i'm an ugly expert at
bug-morphing...

There are yet two anomalies in the forms:

1: They seem to honor two different font-sizes (??) - the indication:
When i type in something and then click arrow down and then back again, the
corsor will appear in a higher position on the line than what it was before.
An additional arrow back will "lower" the cursor again, to be lined up with the
text.

2: When i navigate with cursors in a form, it also skips one line if i navigate
up/down with arrows, and it skips one character if i navigate back/forward on
the line. (in middle of some text.) Makes it a little quirky to delete a
character etc. because it will delete the "wrong" character first - i end up
*having* to delete more than intended, thus also having to rewrite more than
intended. No BIG deal but very "buggy".
Summary: selection and insert-points when pasting in forms is confused → selection and insert points in forms confused
i think it appeared around 3 days ago, but not certain.
Currently using linux 2000-071910
Wait, too many bugs in one report!  I'm taking the first one, that if you copy
from a text control, you can't paste back into it, or into anything else.

The second one, that the insert point gets confused, is a separate bug: if this
is a middle-mouse paste, I can look at it, if this is a menu or key-binding
paste, then it sounds like an edit rules problem, so try filing a bug to jfrancis.

Arrow keys going twice as far as they should is bug 45390.  I wasn't seeing it
at all until today, and now I'm seeing it sporadically, and if someone could
find a way to reproduce it reliably on today's build, it would be MUCH
appreciated by everyone concerned.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Summary: selection and insert points in forms confused → can't paste from a text control back into same text control
I have no idea how this got marked resolved/fixed -- I marked it accepted.  I'm
having a LOT of problems using mozilla to do bugzilla stuff today. :-(

Aha.  The problem happens when the selection includes the end of a line.  That
narrows the problem considerably.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: can't paste from a text control back into same text control → can't paste EOL from a text control
This is major dogfood.  I just spent way too long retyping a bugzilla summary
from another bug because I couldn't copy it out of the textarea.  You have to be
able to copy from textareas.
Status: REOPENED → ASSIGNED
Keywords: dogfood, regression
"confused insertion point" happen on middle-button pastes.

As for wrong resolution on the bug: I may have caused that. According to
bugzilla i "crashed" your first comment here (accepting). Had already written so
much, so without being able to copy it i took my chances.
I thought it went OK since i actually could see your comment. I didn't check if
the crash had performed other mishaps - lesson learned.
Putting on [dogfood-] radar.  Not critical to everyday use.  Also, adding 
"nsbeta3" keyword for fix consideration in PR3. Is this a dup of other bugs?  
PDT thinks this has been a problem for a while. Does cut and paste not work in 
other areas?  Would you pull pr2 off the wire for this.
Keywords: nsbeta3
Whiteboard: [dogfood-]
Yes, I would pull it off the wire for this.  Being able to copy multiple lines
is fundamental to using bugzilla, webmail or any other service that uses
textareas.  Requesting reconsideration.
Severity: normal → critical
Summary: can't paste EOL from a text control → can't paste multiple lines from a text control
Whiteboard: [dogfood-]
Turns out this is a selection regression.  If I break in clipboard code and look
at the XIF, it tells the story.  When only part of a line is selected, the XIF
looks like this (I've added newlines after the \n for easier reading, wish I
could make this textarea not wrap):

<?xml version=\"1.0\"?>\n<!DOCTYPE xif>\n
<encode selection=\"1\"/>\n
<section>\n<section_head>\n<document_info charset=\"ISO-8859-1\"
uri=\"http://bugzilla.mozilla.org/show_bug.cgi?id=45996\"/>\n</section_head>\n
<section_body>\n
<markup_declaration><content>DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2
Final//EN\"</content>\n
</markup_declaration>\n
<content>;jf kls</content>\n
</section_body>\n
</section>\n

When it's a multi-line, the XIF looks like this:
<?xml version=\"1.0\"?>\n<!DOCTYPE xif>\n
<encode selection=\"1\"/>\n
<section>\n<section_head>\n
<document_info charset=\"ISO-8859-1\"
uri=\"http://bugzilla.mozilla.org/show_bug.cgi?id=45996\"/>\n
</section_head>\n
<section_body>\n
<markup_declaration><content>DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2
Final//EN\"</content>\n
</markup_declaration>\n
<container isa=\"textarea\"><attr name=\"wrap\" value=\"HARD\"/>\n
<attr name=\"name\" value=\"comment\"/>\n
<attr name=\"rows\" value=\"5\"/>\n
<attr name=\"cols\" value=\"80\"/>\n
</container><!--textarea-->\n
</section_body>\n</section>\n

In other words, a selection spanning multiple lines inside a textarea expands to
contain the text area itself, but none of its contents.

Calling Mike in on the action to see if knows what might have changed.
Mike found a fix.  This was an ender lite problem in the document's output to
XIF: there was an optimization in place for a selection within the same text
node, but when a selection spanned different text nodes across a br, the
optimization didn't kick in and the root element was wrong.  The fix is to to
check whether the parents of the nodes are equal if the nodes themselves aren't
equal.
Assignee: akkana → mjudge
Status: ASSIGNED → NEW
Keywords: nsbeta3 → nsbeta2
Whiteboard: [FIX IN HAND]
Target Milestone: --- → M17
Putting on [nsbeta2+][dogfood-] radar.  Does not need a fix ASAP for daily work, 
but we should fix this for beta2. For fix in hand.
Whiteboard: [FIX IN HAND] → [nsbeta2+][dogfood-] [FIX IN HAND]
it was checked in. gracias
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Hour Ifnye n stilleprode thisproble ease open itit yourcomnts.
Hmurg
f nyoecn sil eprouethisroblem, ease ropeni ithyourcmmts.Thsloos
od on aHour Ifnye n stilleprode thisproble ease open itit
yourcomnts. Hmurg
f nyoecn sil eprouethisroblem, ease ropeni ithyourcmmts.Thsloos
od on a
(not sure if last comment was a ViaVoice or Mozilla bug --- works fine pasting
text from SimpleText)

---

This looks good using today's builds on all platforms using original steps to
reproduce.

If anyone can still reproduce a problem here, please re-open. Thanks!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.