1748128 - In the standalone search bar, guess candidates are not displayed in the candidate window of ATOK (Japanese IME).

Status: RESOLVED FIXED

(Firefox :: Search, defect)

Description

[Alice0775 White]

Attachment: `Guess candidates` are displayed in the candidate window as expected, if disable `入力欄の属性を参照する` ATOK property

Steps to reproduce:

1. Prerequisite: install ATOK2021 and Enable standalone Search bar
2. Start Firefox
3. Select the Search bar
4. IME on and Type moji

Actual results:
Guess candidates(推測候補ウィンドウ) are not displayed unless changing ATOK property(入力補助 > 特殊 > uncheck 「入力欄の属性を参照する」).

Expected results:
Guess candidates(推測候補ウィンドウ) should be displayed in the candidate window without changing ATOK property .
See attached screenshot.

Comment 1

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=3424598d23bd0d036282693a3e7af9bec70b127c&tochange=f427e163a30417600d5f9547ac8abc2b7847cc69

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1239319

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jimm, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Stephen A Pohl [:spohl]]

(In reply to Alice0775 White from comment #1)

Regression window:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=3424598d23bd0d036282693a3e7af9bec70b127c&tochange=f427e163a30417600d5f9547ac8abc2b7847cc69

Reassigning to the same component as bug 1239319 and n-i :Gijs.

Comment 5

[:Gijs (he/him)]

We just expose the input type (inputtype=search) on the relevant HTML element, and it's up to widget code to translate that for the relevant IME stuff and interact with the relevant TSF/IME APIs. The change got made for compatibility with Windows' built-in keyboards. I don't know why it breaks with this IME with this option set, not least because I do not speak the language used to define the options so do not understand their relevance... Maybe Daisuke can help, based on bug 1689055?

Comment 6

[Daisuke Akatsuka (:daisuke)]

Thank you very much for the reporting, :alice0775!
(And also thank you very much for letting me know, :Gijs)

Yes, I as well could reproduce this issue on win11 pro as well.
I'll take a look at this.
Thanks!

Comment 7

[Daisuke Akatsuka (:daisuke)]

Attachment: Bug 1748128: Avoid sending 'search' input scope when ATOK is active.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/02ca8709ede0
Avoid sending 'search' input scope when ATOK is active. r=masayuki

Comment 9

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/02ca8709ede0

Comment 10

[Daisuke Akatsuka (:daisuke)]

To apply this fix, need to turn intl.tsf.hack.atok.search_input_scope_disabled on.
However, please note that this change affects touch keyboard on touch screen.

Comment 11

[Brian Birtles (:birtles)]

Masayuki tells me that a new version (v32) of ATOK was released at the end of January 2022 which changes this behavior.

Daisuke-san, are you able to re-check the behavior now with and without the pref in Firefox and in Chrome (using a regular HTML input of type=search)?
(It seems like the only way to get an old version of ATOK is to buy the 一太郎 bundle which includes a specific version but Amazon is out of stock of last year's bundle.)

Masayuki was unsure about turning this pref on by default because it seems like ATOK has deliberately made a choice not to show the window unless a pref is set so we should not forcefully override it. Apparently testing the current version with the default settings, the window doesn't show even in Notepad. Masayuki will ask his contact at ATOK about this.

Depending on the outcome, it might, for example, make sense to turn the pref'ed behavior on only for Chrome documents, or for specific versions of ATOK.

Comment 12

[Daisuke Akatsuka (:daisuke)]

Attachment: atok32.0.2.mp4

Thank you very much, Brian! (I’m sorry for delay)
I have checked the behavior again with env below:

• ATOK for Windows 32.0.2
• Windows 11 Pro 21H2

As the result, it seems that we have still the same problem.
Please see the attached video.
The candidate window is not shown unless turning the pref introduced in this bug on.

Comment 13

[Brian Birtles (:birtles)]

(In reply to Daisuke Akatsuka (:daisuke) from comment #12)

As the result, it seems that we have still the same problem.
Please see the attached video.
The candidate window is not shown unless turning the pref introduced in this bug on.

Thank you! What about Chrome?

Comment 14

[Daisuke Akatsuka (:daisuke)]

Yep, I forgot to check it, sorry!
I checked with Chrome canary 101.0.4903.0, and it also is the same behavior as Firefox.
That means the window is not shown unless unchecking "入力欄の属性を参照する" in ATOK setting.

Comment 15

[Alice0775 White]

Yes, I can reproduce the issue in Chrome98.
testcase data:text/html,<input type="search">

Comment 16

[Brian Birtles (:birtles)]

Thanks Daisuke and Alice!
I think the matches Masayuki's observation and means we should not turn this pref on by default? What do you think?
Or do you think it makes sense to turn on this behavior for chrome content only, for example?

Comment 17

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

(In reply to Brian Birtles (:birtles) from comment #16)

I think the matches Masayuki's observation and means we should not turn this pref on by default? What do you think?

Yes, I do not think that the pref should be enabled by default. Once we ignore other products intention, it may break other features of them too. For example, I requested JustSystems to stop doing any special handling on Gecko because it was impossible to fix some issues on Gecko side due to their hack. So now, this issue is an opposite case of that.

Or do you think it makes sense to turn on this behavior for chrome content only, for example?

From point of view of our UI development, we can remove "search" input scope from our any UI. Therefore, it's okay to make ignore the fact only in chrome context. On the other hand, doing it makes a regression same as bug 1239319 only for ATOK users. Therefore, even if we do it, we should check whether touch keyboard is used or not. If it's used, we should send input scope as-is for keeping "right" behavior for the touch keyboard.