Closed Bug 128480 Opened 23 years ago Closed 17 years ago

Copy paste non ascii characters fail

Categories

(Core :: Internationalization, defect)

Product:
Core
Component:
Internationalization
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: fleury, Assigned: smontagu)

References

Details

(Keywords: intl) 

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214
BuildID:    0.9.8

Hi,

As I am French, I am used to look web pages in French and sometime I try to
copy/paste some part of the text.

I noticed that when you do this, all the non ascii characters (which are
properly displayed in the browser) are replaced by '?' characters.

For example:
Deux approches sont aujourd'hui privilégiées.

Give:
Deux approches sont aujourd'huis privil?gi?es.



Reproducible: Always
Steps to Reproduce:
1.select a text with non ascii characters
2.paste it
What are you pasting to?
I just tried this. pasting to "gedit" (which is set up to use Courier New as font)
and all the characters displayed fine. Also pasted fine into OpenOffice (Arial),
and Gnumeric (Adobe Helvetica).
I am pasting to Emacs (20 or 21) or an xterm.
Pasting to xterm display the correct characters here, when used with the default
font "fixed".

"xterm -fn fixed" to test this, in case you currently use another font.
Testing on RH7.1 and a current CVS build of Mozilla.
Ok, so it should be debian unstable/testing related. :-/

What is puzzling me is that Opera is do it right !!!
I'm running Debian/GNU Linux as well, and I am seeing this in some apps. Pasting
"едц" into an xterm works, but it shows up as questionmarks if I paste it into
emacs or gaim. Writing those characters directly into those programs work, and
it also works to copy and paste from other programs into them.

This is with 0.9.9.
->bryner
Assignee: trudelle → bryner
*** Bug 136004 has been marked as a duplicate of this bug. ***
Seeing this too, current trunk cvs on debian testing. Bug 136004 useful
selection content stuff.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Since a while back this is now WFM on Debian unstable with a current branch
build. I have tested pasting non-ascii chars into xterm, gaim, xchat and emacs,
and they all now work for me.

For those who still see this, are you sure that your locale is set correctly to
support your language? On Debian you should have the right lines in
/etc/locale.gen and re-run locale-gen after editing it.
> Since a while back this is now WFM on Debian unstable
> with a current branch build. I have tested pasting
> non-ascii chars into xterm, gaim, xchat and emacs,
> and they all now work for me.

Does it work for you in 0.9.9?  It doesn't for me.

> For those who still see this, are you sure that your locale
> is set correctly to support your language? On Debian you
> should have the right lines in /etc/locale.gen and re-run
> locale-gen after editing it.

I am using a fairly vanilla Red Hat 7.2 + Ximian system with
no particular locale setting, so I assume I am in the "C" locale
or whatever they call that these days.

Netscape 4.x and every other program I use is able to display, copy,
and paste Latin1 characters under these conditions.  If Mozilla cannot,
then Mozilla is buggy.  So I hope you're not saying I should have to
reconfigure my system to make Mozilla work the same way that 4.x
did, because that's just not a good answer.

I see no locale-ish things in my environment.  When I run 
/usr/bin/locale, it prints "POSIX" for all values (including "LANG")

For the record, this still exists in Mozilla 1.2b:
Create an HTML file containing only this:

Foöbar.

Selection contents:

    STRING          Foo"bar.
    TEXT            Fo?bar.
    COMPOUND_TEXT   Fo?bar.
    UTF8_STRING     Fo\303\266bar.
    text/unicode    F\000o\000ö\000b\000a\000r\000.\000
    text/html       \377\376F\000o\000ö\000b\000a\000r\000.\000
QA Contact: sairuh → ruixu
Keywords: intl
QA Contact: ruixu → kasumi
not quite the right place to post this fix, but since this is the most relevant
description of the problem i could find at the moment, i thought this might be
useful to someone stumbling upon this bug report:  here is a hack for GNU emacs
that will make it work for now (this is an extremely annoying problem):

;;-------------------------------------------------------------------------------
;; hack to convert mozilla's selection when pasting in.

(defun user-mouse-yank-at-click (click arg)
  (interactive "e\nP")
  (let ((decoded (decode-coding-string
		  (x-get-selection 'PRIMARY 'UTF8_STRING) 'utf-8)))
    (x-set-selection 'PRIMARY decoded)
    (mouse-yank-at-click click arg)
    ))

(substitute-key-definition
 'mouse-yank-at-click 'user-mouse-yank-at-click
 (current-global-map))

;; (add-to-list 'selection-converter-alist '(UTF8_STRING .
xselect-convert-to-string))
This bug still exists in Mozilla 1.3, of course.

Martin, your workaround doesn't work for me in XEmacs 21.1.14, because
decode-coding-string says "No such coding system: utf-8".

Here's the halfassed workaround I've been using:

(defun x-insert-selection (&optional check-cutbuffer-p move-point-event)
  "Insert the current selection into buffer at point."
  (interactive "P")
  (let* ((unicode-p nil)
         (text (or (condition-case ()
                       (prog1 (x-get-selection nil 'text/unicode)
                         (setq unicode-p t))
                     (error ()))
                  (x-get-selection))))
    (cond (move-point-event
	   (mouse-set-point move-point-event)
	   (push-mark (point)))
	  ((interactive-p)
	   (push-mark (point))))
    (let ((p (point)))
      (insert text)
      (if unicode-p
          ;; When mozilla gives us unicode strings, the Latin1 characters
          ;; are in the top 8 bits of a 16 bit character: the bottom 8 bits
          ;; are null.  Delete them.  This is not even close to being a
          ;; proper Unicode parser, but at least it lets me paste Latin1
          ;; characters from Mozilla 1.1b to XEmacs 21.1.
          (save-excursion
            (while (> (point) p)
              (delete-char -1)
              (forward-char -1))))
      text)))
Well, I've been tempted to open a new bug report about this, but I think this
bug is the proper place. I'm having problems with copy-pasting too, except I
don't get ???s anymore, I get odd \x{..} escape sequences, in xemacs, abiword,
rxvts, etc.

Here is an example... Say I type in a string with latin characters in here:
"C'est une belle journée!". Copied to an rxvt, emacs or abiword gives me: "C'est
une belle journ\x{00E9}e!". Copying to an xterm -fn fixed works though. Setting
xemacs to use the fixed font doesn't work.

So this is a pretty evil bug. I can't copy paste any latin character properly.
This is with the Mozilla-1.3b port running on FreeBSD, altough I think it also
occurs on 1.3b on Debian.

I hope this can be solved before 1.4 gets out. I can help testing patches and
building stuff locally without problems.

Oh, and last note.. The two emacs hack don't work at all here. This is Xemacs 21.4.
Xianglan, do you see the problem?
Component: XP Apps → Internationalization
QA Contact: kasumi → ylong
Unfortunately, the French locale is not installed properly on my RH8.0.
Yuying, could you check this? Thanks.
Copy/paste french high-ascii characters works for me on 04-08 (1.4b) trunk build
/ linux RH8.0 with xterm and emacs when login as French system locale.

The problem that I had was when login as a different locale (e.g. Japanese), and
copy/paste french characters to xterm and emacs even with terminal loale changed
to French.
hi,

i'm using mozilla 1.4 final (de-AT) and used to use mozilla 1.1 (the default
us-version). i'm very happy with this great browser. unfortunately, in both
versions, cut and paste of 'german umlaute' (הצ��) is buggy; the output of
"Lösung Problem" then is "Lo"sung Problem".

i tried different fonts and language codes...

will this prob be solved?

thanks for your great work!

cu
axl
since pasting text works on some apps but not others, shouldn't this be other
application's bug and not a Mozilla bug?
Assignee: bryner → smontagu
it works now for me!
=> WFM per Axl's comment 20
please comment if you still see the problem.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.