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.