483122 - [FAYT] Composed characters and IME don't work with FAYT or autostart

Status: RESOLVED WONTFIX

(Camino Graveyard :: General, defect)

Description

[Eiichi]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en; rv:1.9.0.8pre) Gecko/2009031200 Camino/2.0b3pre (like Firefox/3.0.8pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en; rv:1.9.0.8pre) Gecko/2009031200 Camino/2.0b3pre (like Firefox/3.0.8pre)

We cannot use IME on FAYT of Camino/2.0b3pre (Trunk Only). 

Reproducible: Always

Steps to Reproduce:
1. Open http://www.google.com/search?q=Camino&hl=ja&ie=UTF-8&oe=UTF-8&num=100
2. Set IME on.
3. Start FAYT and type "KAMI-NO (カミーノ)".
Actual Results:  
We cannot use IME on FAYT.

Expected Results:  
We can use IME on FAYT.

We can use IME on FAYT on Camino 1.6.*, so this is regression.

Comment 1

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

C'est la même chose avec les accents français :(

Can we get a regression-range here?  I'm not hopeful this can be fixed, but if we don't know what broke it, there's no chance at all.

Comment 2

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

Er, maybe these are two different bugs, because I can't figure out how to make the steps in comment 0 work in 1.6.x, either :(  How are you starting FAYT with IME on?

Comment 3

[philippe (part-time)]

Both IME (japanese input) and Roman composite characters
regression: fails
Version 2.0a1pre (1.9b5pre 2008031301)

works
Version 2.0a1pre (1.9b5pre 2008031200)

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-03-12+00%3A00%3A00&maxdate=2008-03-13+01%3A00%3A00&cvsroot=%2Fcvsroot

Maybe:
fix scrolling with the space bar when using Japanese IME. Patch my Masayuki Nakano. b=420699 r=josh sr=roc 

(In reply to comment #2)
> Er, maybe these are two different bugs, because I can't figure out how to make
> the steps in comment 0 work in 1.6.x, either :(  How are you starting FAYT with
> IME on?

Try autostarting :-)
or: roman input '/' and switch to IME (Cmd-space loops trough available input methods). 
(it is easy on those Japanese keyboards, with their special keys.)

(for Japanese I usually use cmd-F, from long time ago.)

Comment 4

[philippe (part-time)]

Attachment: test case to play with

For Japanese type 're' (the last character in the first block should be selected)
For French ré or à.

Any composite character fails in French/Spanish/German

Comment 5

[philippe (part-time)]

* I did a test with Seamonkey nightly [1], comm-central build. I get the exact same behaviour as with Camino trunk: only roman (ascii) characters are registered.

* Testing this with Minefield latest and Fx 3.07:
    - triggering FAYT with '/' works - probably (almost certainly) because the find-bar is opened. Camino also works fine with the find-bar.
    - FAYT set to autostart: kinda fails for Japanese: the first keystroke opens the find-bar, but is registered as a roman character (the 'r' in the test in comment 4). Composite roman characters (à) fail, the find-bar opens with 'a'.


[1] Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090312 SeaMonkey/2.0b1pre

Comment 6

[Eiichi]

(In reply to comment #3)
> Maybe:
> fix scrolling with the space bar when using Japanese IME. Patch my Masayuki
> Nakano. b=420699 r=josh sr=roc 

Thanks, philippe.

1) I back out an attachment (id=307420) of Bug 420699 as below and make a test build.
/mozilla/widget/src/cocoa/nsChildView.mm : line 5160
- if (!isKeyEquiv &&
      (nsTSMManager::IsIMEEnabled() || nsTSMManager::IsRomanKeyboardsOnly()))
+ if (!isKeyEquiv)

2) I can use IME on FAYT.

3) So this bug seems to be caused by fixing Bug 420699.

Comment 7

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

So this sounds like it's broken across products and branches, with the caveat that in Firefox, you must use autostart:

1) Composite Roman characters fail (only the base letter appears)
2) Japanese IME doesn't work at all (or with autostart in Firefox, the first character is registered in Roman)

Have I got that right?

Further, changing the placement of 
if (!isKeyEquiv)
fixes this bug?  Does it do so without regressing 420699?

--> Widget:Cocoa

Comment 8

[Samuel Sidler (old account; do not CC)]

I don't suppose some of this will be fixed on trunk by Neil's focus patch?

Comment 9

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

(In reply to comment #7)
> Further, changing the placement of 
> if (!isKeyEquiv)
> fixes this bug?  Does it do so without regressing 420699?

You cannot fix this issue without the regression. I believe that auto-start feature is a bad UI design for IME users. On Win and Linux, IME events are never fired when IME is disabled by us. On Mac, we emulate the behavior by the patch of bug 420699 and something. In other words, on Gecko1.9.x, internal IME events of Gecko are fired only when an editor has focus.

I don't know the FAYT implementation of Camino. If Camino doesn't set focus to an editor during FAYT, it is invalid UI design on Gecko1.9.x.

Comment 10

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

If bug 610821 is fixed by the posted patch's approach, the native keydown event will be sent to IME when our keydown event handler move focus to editor. So, the fix will make a possible way to fix this bug.

However, there is a serious problem about the FAYT spec. That is, even if auto-start is enabled, / or ' causes manual-start. Unfortunately, it cannot be checked in keydown event handler because we cannot know whether the pressed key has the characters in its shifted position. And also it means IME users cannot start by some characters which are assigned to same key as / or '.

So, to fix this bug, we need to find a new better behavior for i18n.

I think that we should kill the manual-start at auto-start mode for / and '. If so, we can provide same behavior to all keyboard layout users. However, it means that user cannot choose text-search-mode or link-only-mode if auto-start mode is enabled. This is bad.

Furthermore, there is another i18n problem, that is, some keyboard layout may need Shift key or Option key (on Mac) for inputting / or '. So, the shortcut key design is very bad for i18n.

Therefore, I think that we should define new shortcut keys for the manual-start. E.g., Function keys which don't depend on keyboard layout are better than / or '. But I'm not sure what keys are the best for them.

Comment 11

[Alex Faaborg [:faaborg] (Firefox UX)]

>Therefore, I think that we should define new shortcut keys for the
>manual-start. E.g., Function keys which don't depend on keyboard layout are
>better than / or '. But I'm not sure what keys are the best for them.

Let's go with accel-/ and accel-' for now.

Comment 12

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

Attachment: Patch v1.0

I'll request review after bug 610821 is finished.

Comment 13

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

I'm very sorry. The original reported issue isn't same as what I'm working. I filed bug 615879. And I'm resetting this bug to *Camino*. I'm not sure this bug is still on latest Camino. However, I can say that this isn't a bug of core widget. This is UI design issue.

Comment 14

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

Camino has gone. So, we don't need to work on this bug.