306281 - Some Unicode characters not displayed correctly in certain contexts

Status: RESOLVED DUPLICATE of bug 212745

(Firefox :: General, defect)

Description

[Aaron Madlon-Kay]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050827 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050827 Firefox/1.0+

Some Unicode characters are not displayed correctly in Firefox in certain
contexts.  In the linked URL, the character before the listing for Shift should
be an UPWARDS WHITE ARROW (U+21E7) but instead it is displayed as BOX DRAWINGS
DOWN LIGHT AND HORIZONTAL HEAVY (U+252F).

The behavior with this character is inconsistent.  It shows up INCORRECTLY in
the following places:
* The Firefox built-in search field
* The URL input field
* Every single-line text field on any site I've tried (e.g. the Subject field in
a Slashdot "Post Comment" page, also the Summary line of this very Bugzilla page)
* Some multiline text fields (e.g. the "Quick Reply" field at the site linked to)

It shows up CORRECTLY in
* Some multiline text fields (e.g. this Bugzilla one I'm typing in now, also the
Comment field in a Slashdot "Post Comment" page)

Other characters that behave similarly include
WHITE RIGHT POINTING INDEX (U+261E),
LEFTWARDS WHITE ARROW (U+21E6),
UPWARDS WHITE ARROW (U+21E7),
DOWNWARDS WHITE ARROW (U+21E9),
RIGHTWARDS ARROW OVER LEFTWARDS ARROW (U+21C4),
etc.
They all are shown as characters in the BOX DRAWINGS series (U+2500 to U+257F).

The behavior is consistent whether the character is input by copy-and-paste or
by input from OS X's Character Palette.  The input character, though displayed
incorrectly in Firefox, can be copied and pasted into another application where
it may be displayed correctly.

Reproducible: Always

Steps to Reproduce:
1. Input character listed above, either from OS X's Character Palette, or by
copy-and-paste
2. Note that it is not displayed correctly
3.

Actual Results:  
Character appears as a BOX DRAWING character

Expected Results:  
Character should appear as the character

Comment 1

[Dave Townsend [:mossop]]

Is this to do with bug 282270. I know firefox hides certain unicode characters
in the url bar because they could be used to spoof other websites.

Comment 2

[Aaron Madlon-Kay]

(In reply to comment #1)
> Is this to do with bug 282270. I know firefox hides certain unicode characters
> in the url bar because they could be used to spoof other websites.

I doubt it, since this isn't "hiding," it's "displaying the wrong character,"
and it happens in many places other than the URL bar.  But I'm no expert.

Comment 3

[zug_treno]

Maybe related to Core bug 212985?

Comment 4

[Uri Bernstein]

(In reply to comment #3)
> Maybe related to Core bug 212985?

Or maybe related to bug 212745 (reported for Mac)?

Comment 5

[Brian Ewins]

(In reply to comment #4)
> (In reply to comment #3)
> > Maybe related to Core bug 212985?
> 
> Or maybe related to bug 212745 (reported for Mac)?

Looks to be definitely a dupe of 212745. In that bug it is reported that 
wrapping the characters in <tt> corrects the problem, and you can see exactly
the same thing happening to UPWARDS WHITE ARROW here:
http://ppewww.ph.gla.ac.uk/~flavell/unicode/unidata21.html#x21E7

(in Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1)
Gecko/20050929 Firefox/1.6a1)

NB that row of the table displays correctly in Safari. One variation from the
original report in this build: the character doesn't render as BOX DRAWINGS
DOWN LIGHT AND HORIZONTAL HEAVY when pasted into textboxes, it renders as a tab,
although the real character is submitted by the form.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This is a dupe of bug 212745; the reason it works with monospaced stuff (this comment box, <tt>, etc.) is because we fall back to Japanese fonts for these characters (even when we should be falling back to Symbol or Apple Symbols), and we didn't change the mono.ja font to one of the new Japanese fonts, so all the broken logic still aligns for monospaced.  We use modern Japanese fonts for serif.ja and sans-serif.ja, and the broken code doesn't find the right glyphs in those fonts.

*** This bug has been marked as a duplicate of 212745 ***