We cannot use IME on FAYT of SeaMonkey(Win32 Only). This is a regression of bug 55751 and bug 113187.
Maybe, many people have some questions:
1. Why we cannot use IME on FAYT of SeaMonkey?
Now, when non-Editor widgets(e.g., document.content, texts and links.) are having focus, we are disabling IME. So, FAYT of SeaMonkey needs IME enabling on non-Editor widgets.
2. Why we needed the changing to disable IME on non-Editor widget?
On Windows, normal applications don't enable IME on non-Editor widgets. But on Gecko, it was not so. By this cause, we had many serious bugs for usability of IME users.
3. Why we don't enable IME when the user begin to input for FAYT?
I and roc discussed to it. Of course, we can implement so with quirks code for ESM. But it's not clever way. We should limit that IME is enabled only on editor.
4. Why Firefox doen't have this problem?
FAYT of Firefox are using the editor of Find Toolbar for input handling. Because IME is enabled when FAYT is stated.
For fix this bug, we need to change FAYT interface like Firefox. On SeaMonkey, we are having a enhancement for port Find Toolbar from Firefox(bug 97023). Therefore, I changed the severity "enhancement" to "normal". We should fix bug 97023 for i18n inputtable FAYT. If we can fix it, we may fix bug 194380 and bug 257489. And we can display the found link's URI on status bar.
From how you describe it, this being an extra bug report is more or less useless, as from how you're talking of it, this is just another symptom of bug 97023 (or another reason why that one should get fixed)...
Of course, there is better idea for fix this without Find Toolbar, this bug and bug 97023 is not dup.
Well, two other ideas come to mind:
1. Reuse the URLbar - when FAYT activates, the URLbar takes focus.
(Which reminds me: how do you lose focus from the Firefox find bar?)
2. Make the find dialog find as you type, rather than waiting for an OK.
Make the Ctrl+G (F3 on Windows) key(s) work there, too.
CC'ing jag as I'm sure he's got a better idea.
Hmm, reusing URLbar / navigation toolbar in some way sounds interesting... We just need some way for the user to freely switch the bar between "web navigation" and "find in page" mode and make those modes visible.
I still think it's best to discuss that stuff over in bug 97023, as from the way we currently look at that stuff, we slove both issues at one time with the solutions we're thinking of...
> 1. Reuse the URLbar - when FAYT activates, the URLbar takes focus.
This is good idea for Navigator. But Source Viewer and Help Contents are not having URL bar. We cannot use this idea...
> how do you lose focus from the Firefox find bar?
I cannot understand this, what you mean?
> Make the find dialog find as you type, rather than waiting for an OK.
I don't like this way. Because sometimes, the found content may be overlapped by the dialog.
(In reply to comment #5)
>>1. Reuse the URLbar - when FAYT activates, the URLbar takes focus.
>This is good idea for Navigator. But Source Viewer and Help Contents are not
>having URL bar. We cannot use this idea...
And there's also the message windows (messageWindow.xul et al). Sigh...
>>how do you lose focus from the Firefox find bar?
>I cannot understand this, what you mean?
Well, supposing you've used FAYT to find a link called Prefs. Using Suite's FAYT you just press Enter and it follows the link.
(In reply to comment #6)
> (In reply to comment #5)
> >>1. Reuse the URLbar - when FAYT activates, the URLbar takes focus.
> >This is good idea for Navigator. But Source Viewer and Help Contents are not
> >having URL bar. We cannot use this idea...
> And there's also the message windows (messageWindow.xul et al). Sigh...
Oh, I didn't know we can use FAYT on message window...
> >>how do you lose focus from the Firefox find bar?
> >I cannot understand this, what you mean?
> Well, supposing you've used FAYT to find a link called Prefs. Using Suite's
> FAYT you just press Enter and it follows the link.
We are using "pseudo-focus mechanism" on FAYT of Firefox.
If FAYT find a link, we draw focus rect by using CSS outline property.
And if a link is found and the user press Enter or Tab key in the editor, we re-fire same event on the link element.
So, actural focus always is set to editor.
In short, I need a Editor for FAYT input handling.
Can we embed the editor element in status bar?
If we can do so, can we fix this bug without Find Toolbar?
But this idea has a issue. If status bar is hidden by user, should we show the status bar, and hide it after FAYT?
I strongly object to any visible find/FAYT UI at the bottom of the window, as I said before.
(In reply to comment #9)
> I strongly object to any visible find/FAYT UI at the bottom of the window, as I
> said before.
Do you have another idea?
why can't we restore the old behaviour, e.g. enable IME when / or ' is pressed? IMO, the firefox find bar is among the worst UI in that product, and I'd really prefer if we didn't copy it.
> why can't we restore the old behaviour, e.g. enable IME when / or ' is pressed?
See bug 55751 comment 62 to bug 55751 comment 65.
Why we need to change core event handling for an only featur that is a bad designed UI? (if we fixed bug 55751 before FAYT implementation, we may never use IME on FAYT of SeaMonkey.) I only normalized the changing IME state on the application. FAYT of SeaMonkey is very abnormal structure for IME users.
# if we change so, we need to refact nsTypeAheadFind.*, current code is nonsense for handling inputting transactions.
And, current FAYT of SeaMonkey IME handling is nonsense. It has many bugs but these bugs are not reported. E.g., return values of compostion events are not correct. the composition string are not rendered correctly...
I disagree that this feature is badly designed, I do like it the way it is...
For IME users, the non-editable widgets are handling the input events is very abnormal. Because we need the feedback of compostion string, candidate list and some tooltips or floating toolbars on caret position. Current design is not i18nable design. So, I cannot say this is good design.
ok, I guess. it's very convenient for people who don't need IMEs though...
Yes. that's right.
When IME users are inputting the text, there is a status that is "inputting".
If without IME, we are not having this status. Because a character is determined after key typing immediately. So there is a only status "inputted".
IME users types some keys for some character. This provisional text is called composition string(this is a term of Win32SDK). This text expresses pronunciation if the IME is for Japanese. IME users convert from composition string to another text. In this time, we must choose the text from candidate list that is listing the texts from composition string. We choosed the wanted text from the candidate list, in this time, we get "inputted" status.
But current UI(in status bar) cannot process these inputting status perfectly. E.g., the composition string is separated some clauses by grammar. but status bar cannot render each clauses. It's rendering as inputted text. We cannot confirm the IME is separating clauses suitable. And candidate list is positioned random position. Because status bar doesn't have caret. We cannot position the candidate list on correct position.
I'm resetting bugs which are assigned to me but I'm not working on them and I don't have plan for fixing them in near future.
Could someone with an IME please test in a nightly from July 25, 2010, or later?
Great!!! fixed by bug 97023, thanks a lot!