Closed Bug 466408 Opened 14 years ago Closed 14 years ago

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


(Core :: Widget: Cocoa, defect)

Not set





(Reporter: ideal.wood2001, Assigned: masayuki)



(Keywords: fixed1.9.1, intl, regression)


(1 file, 1 obsolete file)

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:
Keywords: intl, regression
I can confirm this (using Apple's default US keyboard:

1) Visit and click in the "search mozilla"

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:


In that range, I suspect it was the patch for bug 462995 that
triggered this bug.
Ever confirmed: true
Assignee: nobody → joshmoz
Component: General → Widget: Cocoa
QA Contact: general → cocoa
Version: unspecified → Trunk
> 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).
Flags: blocking1.9.1?
Whiteboard: [key hell]
blocking1.9.1+, this is a highly visible regression
Flags: blocking1.9.1? → blocking1.9.1+
Attached patch Patch v1.0 (obsolete) — Splinter Review
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.
Assignee: joshmoz → masayuki
Blocks: 462995
Whiteboard: [key hell]
Attached patch Patch v2.0Splinter Review
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.
Attachment #353246 - Attachment is obsolete: true
Attachment #353653 - Flags: review?(smichaud)
Attachment #353653 - Flags: review?(smichaud) → review+
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
> 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.
I tested on both OS X 10.5.6 and 10.4.11.
Attachment #353653 - Flags: superreview?(roc)
The test of comment 1 should be in litmus, I think.
Flags: in-litmus?
Attachment #353653 - Flags: superreview?(roc) → superreview+
pushed to trunk, thank you!
Whiteboard: [c-n: baking for 1.9.1]
Target Milestone: --- → mozilla1.9.2a1
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.