Open Bug 338760 Opened 18 years ago Updated 15 years ago

U+3000 ideographic space not displayed in text fields

Categories

(Core Graveyard :: Widget: Mac, defect)

1.8 Branch
PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

mozilla1.8.1beta1

People

(Reporter: mark, Assigned: mark)

References

()

Details

During some 23rd-hour testing of bug 337199, I found that U+3000, the ideographic space character, is not displayed in text fields.  This isn't really anything that 337199 caused, as the character is entered properly.  (To verify this, type it into a search field such as the one at http://www.google.com/ and note %E3%80%80 in the URL.)  This may have started with bug 332579/bug 326273, although that would be surprising too.  I guess anything is possible.  I haven't tested to find the regression range yet.

Steps to reproduce: visit http://www.google.com/search?q=%E3%80%80%E3%81%82.  Look in the search field.  Expected text is a space before the hiragina.  Actual text is just the hiragina.

Text input is not required to experience this bug, but to test it with text input, set the input method to Hiragina and type <space><a><return> into a text field.

I see this bug on both the trunk and 1.8 branch.  I don't see the bug on win32 or cocoa widgets.
I don't see this bug in the 2a2+337199 test build (bug 337199 comment 25), which seems to rule out bug 326273, bug 332579, bug 337199, and bug 338153.
I tried tinderbox-builds.
There seems to be no problem. 
(Of course, the problem is not in the input of Japanese either. )

Mac OS X 10.3.9
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060521 Minefield/3.0a1
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1a2) Gecko/20060522 BonEcho/2.0a2
I don't see the bug in my own trunk build on my G5 at work, either.  I was working with an x86 Mac at home, I'll take another look tonight.
Product: Core → Core Graveyard
Version: Trunk → 1.8 Branch
You need to log in before you can comment on or make changes to this bug.