60739 - Won't copy/paste past "'" character

Status: VERIFIED FIXED

(Core :: XUL, defect, P2)

Description

[Allen Barnett]

The third paragraph of the URL above starts out with: "We really started to see
signs that we weren't dealing with the same Intel..." If I try to highlight this
text with the mouse (i.e., copy the text to primary X selection) and then paste
this selection into EMACS (or even this very textfield here), I only get:

We really started to see signs that we weren

Whatever character the "'" is in the HTML, it is preventing the text from being
copied completely into the X selection.

Comment 1

[R.K.Aa.]

Which build ID are you using?

Comment 2

[Allen Barnett]

Build ID: 2000100722 - M18
(Thought it picked this up automatically, sorry.)

Comment 3

[Boris Zbarsky [:bzbarsky]]

I see this with linux build 2000-11-19-21.

Pasting into a Mozilla textarea or an xterm works just fine.  Pasting into emacs
pastes up to the quote and sets the mark; pasting into the gimp (into the "add
some text" tool) pastes up to the quote.

So this seems to be a problem with the applications receiving the paste, not
Mozilla.

Comment 4

[Doron Rosenberg (IBM)]

setting back target milestone, this is for developers only.

could someone create a test case for this?

Comment 5

[Allen Barnett]

Attachment: Example of quotes which won't copy into EMACS and other GTK applications

Comment 6

[Doron Rosenberg (IBM)]

--> xpt copy/paste issue

Comment 7

[Luis Villa]

*** Bug 61280 has been marked as a duplicate of this bug. ***

Comment 8

[Peter Trudelle]

->pinkerton/p2/moz0.9, cc pav, confirming and bumping severity to major due to
data loss.

Comment 9

[Mike Pinkerton (not reading bugmail)]

must be a parser/content problem.

Comment 10

[Stuart Parmenter]

doesn't happen with xemacs... i'm prolly chopping off something i shouldn't be.
(or emacs is broken)..

Comment 11

[Stuart Parmenter]

this looks like a charset converter problem...

see widget/src/gtk/nsClipboard.cpp:920

after the data comes out of the converter, it no longer has anything past the
point where the weird character was...

cc'ing the i18n folks

Comment 12

[nhottanscp]

I don't think the converter fails to convert a single quote.
Does the converter returns any error when the truncation happens?

Comment 13

[nhottanscp]

Okay, it is a smart quote (0x92) in windows-1252. The character is not mapped in
ISO-8859-1, so it is expected that the converter to fail.
Transliteration may be used here (nsISaveAsCharset), so the smart quote to be
mapped to a single quote (0x27). See nsPrimitiveHelpers.cpp#178.

http://lxr.mozilla.org/seamonkey/source/widget/src/xpwidgets/nsPrimitiveHelpers.cpp#178

Comment 14

[Stuart Parmenter]

ok, but why is it cutting off the characters following the quote?

Comment 15

[nhottanscp]

Convert returns an error and stop when it encounters a character which cannot be
mapped to a destination character set.
To change the default behavior, SetOutputErrorBehavior() can be called then
convertor will process the entire input.

http://lxr.mozilla.org/seamonkey/source/intl/uconv/public/nsIUnicodeEncoder.h#164

Comment 16

[Stuart Parmenter]

I can fix this real quick.

Comment 17

[Gagan]

then please do!

Comment 18

[Stuart Parmenter]

fixed

Comment 19

[Stuart Parmenter]

er, not fixed.. will be in a sec

Comment 20

[Stuart Parmenter]

Attachment: patch to fix problem

Comment 21

[Mike Shaver (:shaver emeritus)]

God, the hated '?' returns.  sr=shaver, because it's better than what we've got now.

Comment 22

[Stuart Parmenter]

r=blizzard   will check in when tree is green

Comment 23

[Stuart Parmenter]

fix checked in

Comment 24

[Ben Bucksch (:BenB)]

Do you use "?" as replacement char? This is supposed to go away / be
configurable (don't have bug-number handy). Please don't hardcode it.

Comment 25

[Terri Preston]

Verified fixed linux build 2001102910