466408 - [OSX] First use of dead keys always shows incorrect behavior

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Daniel Luz]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081123 Minefield/3.1b2pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081113 Minefield/3.1b2pre

The first time I use a dead key on a browser session always fails: for example, the browser emits "caf'e" rather than "café" (even though the visual hint of a dead key appears as expected). After that first time, any dead key works fine.

Reproducible: Always




The 2008-10-09 build worked fine, the 2008-11-13 is already buggy.

For the record, I'm using the "U.S. — International" keyboard layout, available here:
http://www.brockerhoff.net/usi/

Comment 1

[Steven Michaud [:smichaud] (Retired)]

I can confirm this (using Apple's default US keyboard:

1) Visit http://www.mozilla.org/ and click in the "search mozilla"
   box.

2) Press opt-u, then press u.

   On pressing u, you should see a single 'ü' in the box (a lowercase
   u with an umlaut).

   But where this problem exists, you see an umlaut character (¨)
   followed by a u.

   Subsequent attempts to do this in the same text box work correctly.
   But the problem will recur if you reload the page.

I've also found a narrower regression range:

2008-11-11-02-mozilla-central
2008-11-12-02-mozilla-central

http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-11-11+00%3A00%3A00&enddate=2008-11-12+05%3A31%3A00

In that range, I suspect it was the patch for bug 462995 that
triggered this bug.

Comment 2

[Daniel Luz]

> But the problem will recur if you reload the page.

Indeed, I just came here to say that. Turns out it appears to fail once for each document. I originally found it on the browser's search box, so I wouldn't see it again until a new window was opened (which only normally happens when restarting).

Comment 4

[Josh Aas]

blocking1.9.1+, this is a highly visible regression

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch v1.0

Sorry for the delay and this regression.

This is a regression of bug 462995. The Mac's dead key inputting uses IME. But the initializing timing must be before interpretKeyEvents of first dead key event in US keyboard layout. I'll test with more IMEs before review.

Comment 6

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch v2.0

This is better. The actual cause is a hack for ATOK which is Japanese 3rd party's IME. The hack should not be run with other IMEs (including deadkey inputting). However, we cannot know which IME is used. Instead of it, we can know which language keyboard layout is used. Therefore, this is safest, the hack is used only for Japanese IME.

Unfortunately, on 10.4, we cannot use [[NSInputManager currentInputManager] language] instead of TIS API. It always returns null pointer. Therefore, I use GetScriptManagerVariable which is legacy API and convert to the result string myself.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 353653 [details] [diff] [review]
Patch v2.0

This looks fine to me.  Both it and the original hack that it brackets
are pretty ugly ... but sometimes that's the best you can do.

I tested with my STR from comment #1 and found that it no longer
happens (I tested with the US, US-extended and German keyboards).

I also found that this patch seems to have no bad effect on dead-key
processing in the Romaji IME.  This doesn't work entirely properly
even in Safari -- when you press opt-u nothing happens, but then when
you press u you get a 'ü' (lowercase u with an umlaut).  But it
continues to work this way after the patch (as it did before the
patch).

Comment 8

[Steven Michaud [:smichaud] (Retired)]

> I also found that this patch seems to have no bad effect on dead-key
> processing in the Romaji IME.

I'm referring to normal, or "half-width" Romaji.  Dead-key processing
doesn't work at all in "Full-width Romaji", even in Safari.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

I tested on both OS X 10.5.6 and 10.4.11.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

The test of comment 1 should be in litmus, I think.

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

pushed to trunk, thank you!

http://hg.mozilla.org/mozilla-central/rev/9e31dcb57815

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

-> FIXED

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

pushed to 1.9.1
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b97b7d5cd067