1253165 - [Win] Should we add a pref to disable sending inputmode attribute of chrome elements to IME?

Status: RESOLVED DUPLICATE of bug 1420215

(Core :: Widget: Win32, defect, P4)

Description

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

STR:

0. Make sure that you don't install nor enable Status-4-Ever.
1. Use MS-IME or Google Japanese Input, and open (turn on) IME in an editor except URL bar.
2. Type Ctrl+L (or Ctrl+T)

Expected Result:

IME should not be closed (not turned off)

Actual Result:

IME is closed (turned off)

This is a decision of each IME. By fixing bug 1240208, we started to send a hint of focused editor's inputmode attribute to IME. Then, MS-IME and Google Japanese Input assume that their users don't want to use IME at inputting URL.

Comment 1

[:Gijs (he/him)]

Prefs are for choices users make. This doesn't feel like a choice as much as something we do wrong.

What do other browsers do on Windows? Can we detect IME or Google's Japanese Input being used and work around this in Firefox instead of using a pref?

Comment 2

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

(In reply to :Gijs Kruitbosch from comment #1)
> What do other browsers do on Windows? Can we detect IME or Google's Japanese
> Input being used and work around this in Firefox instead of using a pref?

IE/Edge does same behavior. However, it's inconvenience for some Japanese users:
http://answers.microsoft.com/ja-jp/ie/forum/ie11-iewindows8_1/internet/536d2280-c919-4206-98b4-ac8361a02be2?auth=1

So, the new behavior muse be complained from some users. However, for some on screen keyboard users, the new behavior must be better, of course.

The problem here are:
1. The "decision" for a hint of input scope "URL" of MS-IME and Google Japanese Input may not be expected behavior for some users.
2. Our URL bar is NOT only for to input URL. Therefore, somebody want to input Japanese text for searching an item in bookmarks or history.

Especially, the #2 is important actually. See this addon:
https://addons.mozilla.org/en-US/firefox/addon/auto-disable-ime/

So, some users already requested to close IME when URL gets focus. I.e., some users have wanted us to change the behavior to current one.

Therefore, even if we restore the original behavior with checking active IME, some users will complain about the original behavior.

So, I guess that adding a pref is better for any users.

Comment 3

[:Gijs (he/him)]

OK, thanks for clarifying. Then yes, it sounds like a pref might be useful for users to control the behaviour here.

Comment 4

[Doug Turner (:dougt)]

confirming / clearing status flags.

Comment 5

[:Gijs (he/him)]

(In reply to :Gijs Kruitbosch from comment #3)
> OK, thanks for clarifying. Then yes, it sounds like a pref might be useful
> for users to control the behaviour here.

Though, re-reading the summary, should this be:
a) only for the URL bar
b) for all chrome inputmode suggestions
c) for all input (type or inputmode) suggestions we make to IME/OS consumers

? The summary suggests (b) but I am not entirely convinced that would provide the right control for users...

Comment 6

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

Yeah, I think (b) is the best for CJK users because they remember the IME open state. Therefore, a lot of users hate that IME open state (or input mode) is changed by application automatically.

Even if we need to change IME open state forcibly, we can use CSS ime-mode too. It's not related to input scope.

Comment 7

[Yohei Yukawa]

(In reply to Masayuki Nakano [:masayuki] (Mozilla Japan) from comment #2)
> 2. Our URL bar is NOT only for to input URL. Therefore, somebody want to
> input Japanese text for searching an item in bookmarks or history.

Just FYI, InputScope API allows you to specify multiple input scopes, e.g. IS_URL, IS_SEARCH and IS_SEARCH_INCREMENTAL.  It probably does not help for this particular case though, because IIRC MS-IME Japanese has checked whether IS_URL is included or not and does not have special rule for IS_URL + IS_SEARCH.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms538181.aspx
https://msdn.microsoft.com/en-us/library/windows/apps/windows.ui.xaml.input.inputscopenamevalue

Comment 8

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

Thank you, Yukawa-san. I understood. However, the purpose of the original change was to improve on screen keyboard users experience of inputting URL. So, even if expanding input scopes, it might disable the original purpose...

Comment 9

[YF (Yang)]

The behavior has affected some users in Simplified Chinese, it automatically turn off the user's IME and don't switch to the original state when focus leave the address bar.

As far as I know, it affects Microsoft Pinyin (Windows built-in), but not all of the input method. IE 11 and Edge toggle the IME when user focus to the address bar, but restore right when focus leave. I don't see the behavior in Chrome 48 for the address bar and Microsoft Pinyin.

Comment 10

[Makoto Kato [:m_kato]]

On Fennec Android, default of awesome screen is search attribute.  If user try to input URL (It means that IsURL is true), its attributes changes to url attribute.

Also, as default of Chrome's omnibox, CJKT is search, not URL.

Comment 12

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

Marking this as INVALID now because this bug is not valid anymore because the fix of bug 1404206 made us stop notifying MS-IME for Japanese and Google Japanese Input of input scope as URL when Awesomebar gets focus.

Comment 13

[YF (Yang)]

This is actually fixed in bug 1420215.