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

RESOLVED FIXED in mozilla1.9.2a1

Status

()

defect
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: from.bmo.18, Assigned: masayuki)

Tracking

({fixed1.9.1, intl, regression})

Trunk
mozilla1.9.2a1
PowerPC
macOS
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 +
in-litmus ?

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

Reporter

Description

11 years ago
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/

Updated

11 years ago
Keywords: intl, regression
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → joshmoz
Component: General → Widget: Cocoa
QA Contact: general → cocoa
Version: unspecified → Trunk
Reporter

Comment 2

11 years ago
> 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).

Updated

11 years ago
Duplicate of this bug: 468864
Flags: blocking1.9.1?
Whiteboard: [key hell]

Comment 4

11 years ago
blocking1.9.1+, this is a highly visible regression
Flags: blocking1.9.1? → blocking1.9.1+
Posted 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
Status: NEW → ASSIGNED
Blocks: 462995
Whiteboard: [key hell]
Posted 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
patch).
> 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.
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!

http://hg.mozilla.org/mozilla-central/rev/9e31dcb57815
Whiteboard: [c-n: baking for 1.9.1]
Target Milestone: --- → mozilla1.9.2a1
-> FIXED
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.