User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en; rv:126.96.36.199pre) 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:188.8.131.52pre) 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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression, regressionwindow-wanted
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?
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.)
Created attachment 367181 [details] 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
* I did a test with Seamonkey nightly , 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'.  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090312 SeaMonkey/2.0b1pre
(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.
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
Assignee: nobody → joshmoz
Component: General → Widget: Cocoa
Product: Camino → Core
QA Contact: general → cocoa
Summary: We cannot use IME on FAYT of Camino/2.0b3pre → Composed characters and IME don't work with FAYT or autostart
I don't suppose some of this will be fixed on trunk by Neil's focus patch?
(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.
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.
Component: Widget: Cocoa → Find Toolbar
OS: Mac OS X → All
Product: Core → Toolkit
QA Contact: cocoa → fast.find
Hardware: x86 → All
Version: unspecified → Trunk
>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.
Created attachment 494377 [details] [diff] [review] Patch v1.0 I'll request review after bug 610821 is finished.
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
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.
Assignee: masayuki → nobody
Status: ASSIGNED → NEW
Component: Find Toolbar → General
No longer depends on: 610821
OS: All → Mac OS X
Product: Toolkit → Camino
QA Contact: fast.find → general
Hardware: All → PowerPC
Version: Trunk → unspecified
Attachment #494377 - Attachment is obsolete: true
Summary: Composed characters and IME don't work with FAYT or autostart → [FAYT] Composed characters and IME don't work with FAYT or autostart
You need to log in before you can comment on or make changes to this bug.