Open Bug 620210 Opened 15 years ago Updated 3 years ago

Incorrect or invisible characters in textareas

Categories

(Core :: Layout: Text and Fonts, defect)

Product:
Core
Component:
Layout: Text and Fonts
Version:
2.0 Branch
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: abbobx39, Unassigned)

References

(
URL
)

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 (.NET CLR 3.5.30729) Firefox displays characters such as ~ or A instead of what is typed. After 3 chars, everything that was typed, plus everything that is typed from then on is invisible even though the cursor keeps on moving. The input is actually correct, except that it's not visible. This bug does not occur with Opera or Chrome on the very same pages. Most of these forms were comments on WordPress based sites. Reproducible: Always Steps to Reproduce: 1. Type anything in the textarea 2. 3. Actual Results: Incorrect or invisible characters Expected Results: Correct characters I'm using a fr-CH keyboard layout.
Even more serious on this page http://www.simplehelp.net/2007/07/08/10-alternatives-to-itunes-for-managing-your-ipod Here, the textarea bugs as described above, but some comments by other users show squares with 4 numbers inside, instead of characters: 说iTunes的服务，从一个评判商店的角度来观察，还是非常不错。从管理iPod和播放器软件的角度，用户还是有很多其它的选择，这就不是一篇文章能写清楚的了。不过做为中国用户，由于服务器的位置，得忍受非常慢的联接速度
Does the issue still occur if you start Firefox in Safe Mode? http://support.mozilla.com/en-US/kb/Safe+Mode How about with a new, empty profile? http://support.mozilla.com/en-US/kb/Basic+Troubleshooting#Make_a_new_profile
I tried something even more radical: I downloaded a copy of Portable Firefox with no profile, no history, no add-ons,... Same problem. I wouldn't be surprised the problem comes from fonts. I've been developing a website recently using cufon embedded fonts. I also occasionnally have problems with arial, helvetica font-family if helvetica comes before arial in the css of a website. Maybe because the helvetica .ttf files I have on my comp might not contain certain special characters. I've extracted the "System Information report" from my comp, if you are interested in having a look, let me know
Can you attach a screenshot highlighting the issue?
If you go to View -> Character Encoding which is checked?
Unicode (UTF-8)
As a follow up: I confirm that the issue occurs on websites where Helvetica comes before Arial in the css. Which might mean that my local Helvetica .ttf file probably misses some special characters. I would then recommend that FF uses Arial even when Helvetica comes first in the stylesheet.
Does this occur using Firefox 4 beta 8 / the latest nightly? http://nightly.mozilla.org/
Component: General → Layout: Text
Product: Firefox → Core
QA Contact: general → layout.fonts-and-text
Problem solved with Minefield 4.0b9pre ! Except for post "WebLog: Xiao.L..." on http://www.simplehelp.net/2007/07/08/10-alternatives-to-itunes-for-managing-your-ipod but I guess this might come from the fact that I don't have East Asian characters installed on my machine. IMPORTANT NOTE: to test http://nightly.mozilla.org/, I did not install any of my add-ons, because most of them were not compatible with Firefox 4 yet. So, I can't guarantee that the issue will still be solved when FF4 will be released for as stable. I can provide you with a list of my add-ons if you want.
John -> Did the issue get resolved with FF 4 Final?
Version: unspecified → 2.0 Branch
Most of the issues, but on the famous page http://www.simplehelp.net/2007/07/08/10-alternatives-to-itunes-for-managing-your-ipod The first two comments still cause problems http://www.referencement-suisse-romande.ch/images/ff/1new.png (does not occur with other browsers => Firefox specific) http://www.referencement-suisse-romande.ch/images/ff/2new.png (occurs with other browers too => system specific) Cheers! John
I do see it too in those 2 comments: Tutorials are included for every program, and theyre all either free or Open Source. If youve been wondering why Ive been writing so many How to use XYZ to manage your iPod tutorials latel It looks like an encoding issue, but I'm not finding an encoding that works.
(In reply to comment #12) > http://www.referencement-suisse-romande.ch/images/ff/1new.png (does not occur > with other browsers => Firefox specific) How does it appear in other browsers? Do you see apostrophes and quotation marks where Firefox shows the boxes with 0092, 0093, 0094, or blank spaces? FWIW, the content of the website is invalid here: it looks as if has used a ISO-8859-1 -> UTF-8 converter to convert text that was actually in Windows-1252. > http://www.referencement-suisse-romande.ch/images/ff/2new.png (occurs with > other browers too => system specific) As you suspected in comment 10, this one displays fine with East Asian fonts installed.
Funny thing is that, by doublechecking, I realize that none of the two other browsers is able to handle these apostrophes either, BUT they display the "problem" in a much more discrete way: Opera displays empty rectangles and Chrome just skips them http://www.referencement-suisse-romande.ch/images/ff/opera.png http://www.referencement-suisse-romande.ch/images/ff/chrome.png Maybe a good idea for FF...
It might be worth thinking about adding codepoints in the range 0x80-0x9F to the default ignorable list, or special casing them in some other way in the missing glyph handling.
Possibly, though I'm not entirely convinced that hiding errors is a good thing. If a web site is serving "junk" codepoints mixed in with its text, then you're going to see junk on the screen. Making the invalid codepoints invisible isn't going to help users who try to search for text on such a page, for example, or copy-and-paste it and wonder why it shows up differently (depending how the destination program handles it). (By the way, we saw a similar error recently in the file description of the Windows Live Photo Gallery plug-in; see bug 607121.)
0x80-0x9F (except 0x85) were default ignorable until Unicode 5.0.0. I think Chrome and Internet Explorer use an older UCD (or deliberately ignore the UCD).
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.