1418747 - [e10s][TSF] Sometimes Microsoft Pinyin does not show up candidate box when the web page is loading

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[taroxd]

Attachment: file.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171112125346

Steps to reproduce:

I opened a webpage. Without waiting for the webpage to finish loading, I typed something into a field of one form. This bug cannot be reproduced every time, but it does occur sometimes.


Actual results:

The IME window did not pop up. See the attached file.


Expected results:

The IME window should have poped up. See the attached file.

Comment 1

[lolipopplus]

Same here on, I also reproduce this unstably here on Bugzilla.

Comment 2

[YF (Yang)]

I can reproduce this issue in Fx56, 57, 58 and Nightly 59 on Win10 RS3, with https://bbs.kafan.cn/forum-215-1.html loading and try enter Chinese to search box on the page. This problem seems to disappear when intl.tsf.enable to false.

Comment 3

[YF (Yang)]

An uncertain range of regression: about 2017-08-10~11.

Bug 1386556?

Comment 4

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

https://bbs.kafan.cn/forum-215-1.html must be a good testcase. However, I cannot reproduce this bug with Firefox 57 nor Nightly on Win10 Fall Creators Update. I guess that we have some bugs in TSFTextStore or IMEContentObserver. Their log can get with |MOZ_LOG=nsTextStoreWidgets:5,IMEContentObserver:5,sync| and specifying the path to log file with |MOZ_LOG_FILE|. However, IMEContentObserver works in content process. So, if you can reproduce this bug even in non-e10s mode, please get a log file with launching firefox with following command, then, just try to input a word in the URL and close the window with clicking the close button.

set MOZ_LOG_FILE=nsTextStoreWidgets:5,IMEContentObserver:5,sync
set MOZ_LOG="c:\log.txt"
firefox --disable-e10s

Comment 5

[taroxd]

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #4)
> https://bbs.kafan.cn/forum-215-1.html must be a good testcase. However, I
> cannot reproduce this bug with Firefox 57 nor Nightly on Win10 Fall Creators
> Update. I guess that we have some bugs in TSFTextStore or
> IMEContentObserver. Their log can get with
> |MOZ_LOG=nsTextStoreWidgets:5,IMEContentObserver:5,sync| and specifying the
> path to log file with |MOZ_LOG_FILE|. However, IMEContentObserver works in
> content process. So, if you can reproduce this bug even in non-e10s mode,
> please get a log file with launching firefox with following command, then,
> just try to input a word in the URL and close the window with clicking the
> close button.
> 
> set MOZ_LOG_FILE=nsTextStoreWidgets:5,IMEContentObserver:5,sync
> set MOZ_LOG="c:\log.txt"
> firefox --disable-e10s

I can reproduce the bug even in non-e10s mode. However, I did not get the log file in c:\log.txt. I tried to swap the two environment variables (set MOZ_LOG_FILE="c:\log.txt" and set MOZ_LOG=nsTextStoreWidgets:5,IMEContentObserver:5,sync), but I still did not see the log file.

Comment 6

[YF (Yang)]

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #4)
> https://bbs.kafan.cn/forum-215-1.html must be a good testcase. However, I
> cannot reproduce this bug with Firefox 57 nor Nightly on Win10 Fall Creators
> Update. I guess that we have some bugs in TSFTextStore or
> IMEContentObserver. Their log can get with
> |MOZ_LOG=nsTextStoreWidgets:5,IMEContentObserver:5,sync| and specifying the
> path to log file with |MOZ_LOG_FILE|. However, IMEContentObserver works in
> content process. So, if you can reproduce this bug even in non-e10s mode,
> please get a log file with launching firefox with following command, then,
> just try to input a word in the URL and close the window with clicking the
> close button.
> 
> set MOZ_LOG_FILE=nsTextStoreWidgets:5,IMEContentObserver:5,sync
> set MOZ_LOG="c:\log.txt"
> firefox --disable-e10s

I have tried these steps but did not see the file being output. The --disable-e10s seem to not work.

In addition, I cannot reproduce it steadily, just luck.

Comment 7

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

(In reply to taroxd from comment #5)
> (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #4)
> > https://bbs.kafan.cn/forum-215-1.html must be a good testcase. However, I
> > cannot reproduce this bug with Firefox 57 nor Nightly on Win10 Fall Creators
> > Update. I guess that we have some bugs in TSFTextStore or
> > IMEContentObserver. Their log can get with
> > |MOZ_LOG=nsTextStoreWidgets:5,IMEContentObserver:5,sync| and specifying the
> > path to log file with |MOZ_LOG_FILE|. However, IMEContentObserver works in
> > content process. So, if you can reproduce this bug even in non-e10s mode,
> > please get a log file with launching firefox with following command, then,
> > just try to input a word in the URL and close the window with clicking the
> > close button.
> > 
> > set MOZ_LOG_FILE=nsTextStoreWidgets:5,IMEContentObserver:5,sync
> > set MOZ_LOG="c:\log.txt"
> > firefox --disable-e10s
> 
> I can reproduce the bug even in non-e10s mode. However, I did not get the
> log file in c:\log.txt. I tried to swap the two environment variables (set
> MOZ_LOG_FILE="c:\log.txt" and set
> MOZ_LOG=nsTextStoreWidgets:5,IMEContentObserver:5,sync),

Oops, that's right.

> but I still did not see the log file.

Oh, really?

(In reply to YF (Yang) from comment #6)
> (In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #4)
> > https://bbs.kafan.cn/forum-215-1.html must be a good testcase. However, I
> > cannot reproduce this bug with Firefox 57 nor Nightly on Win10 Fall Creators
> > Update. I guess that we have some bugs in TSFTextStore or
> > IMEContentObserver. Their log can get with
> > |MOZ_LOG=nsTextStoreWidgets:5,IMEContentObserver:5,sync| and specifying the
> > path to log file with |MOZ_LOG_FILE|. However, IMEContentObserver works in
> > content process. So, if you can reproduce this bug even in non-e10s mode,
> > please get a log file with launching firefox with following command, then,
> > just try to input a word in the URL and close the window with clicking the
> > close button.
> > 
> > set MOZ_LOG_FILE=nsTextStoreWidgets:5,IMEContentObserver:5,sync
> > set MOZ_LOG="c:\log.txt"
> > firefox --disable-e10s
> 
> I have tried these steps but did not see the file being output. The
> --disable-e10s seem to not work.

Hmm, --disable-e10s could be an option only of non-release channel.

Okay, we can still disable e10s with setting browser.tabs.remote.autostart.2 to false in about:config and reboot.

> In addition, I cannot reproduce it steadily, just luck.

It's okay if you reproduce this bug in a couple of times or more. The last composition is the buggy behavior and you don't attach without your daily use log, I'll pick only necessary log up even from long log file.


Okay, both of you cannot get log file with env, then, please use "about:networking" instead. Click "Logging" in the left pane, type file path in "Current Log File:" and click "Set Log File" button. Type "nsTextStoreWidgets:5,IMEContentObserver:5,sync" in "Current Log Modules" and click "Set Log Modules". Then, click "Start Logging" button.  Then, log files will be created with ".<process ID>" post fix.

Comment 8

[taroxd]

I have not encountered with this bug so far after setting browser.tabs.remote.autostart.2 to false.

Log file: https://drive.google.com/open?id=1q7U4ZZtRhFtpr37UbBSGfRN-N4ftRvXq

Comment 9

[taroxd]

Here is a log with browser.tabs.remote.autostart.2 set to true and bug reproduced.

https://drive.google.com/open?id=1f79Gf1MR852nzDP4VmNmFtZWKAGuvF2A


More information:
This bug typically occurs when firefox is launched not long before I type. I can reproduce the bug in https://www.baidu.com with following steps.
1. Set input language to English (My default)
2. Launch Firefox
3. Open https://www.baidu.com
4. When the page is loading, switch to Chinese IME (Microsoft Pinyin)
5. Type

Comment 10

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

Thank you for the log. When you type first character, Pinyin tries to get the character rect, however, according to the log, we return error because it hasn't been handled in the remote process. Perhaps, this is what you cannot reproduce this bug with non-e10s mode and this is a random failure.

So, I guess that you can reproduce only when you type something at end of focused editor.  I.e., when you insert text middle of existing text, perhaps, you can never reproduce this bug.

Perhaps, we need to return fake rect instead of returning error. I try to look for how to compute the fake rect tomorrow.

Comment 11

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

Could you attach new log file with "nsTextStoreWidgets:5,ContentCacheWidgets:5,sync"? (You can use "Attach File" link above instead of using external services.)

I'm trying to understand why the main process doesn't have character rect for the first character, though, looks like that it has enough hack. So, such hacks might not work well.  Therefore, I'd like to check the cache of the content process.

Comment 12

[taroxd]

Attachment: log.txt-main.10100

The log file

Comment 14

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

https://treeherder.mozilla.org/#/jobs?repo=try&revision=15a108881cf18e78667bb6ca4d538a76c5010b0d

Comment 15

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

Hi, sorry for the delay and really thank you for the log. According to the log, we've just forgotten to initialize a variable and that causes failing to return a character rect to MS Pinyin. So, perhaps, this test build fixes this bug. Could you check if it's actually gone? Note that, please test it after completely closing all existing Firefox's windows.
https://queue.taskcluster.net/v1/task/FNXKboxvQT2HQBrDx4N5vg/runs/0/artifacts/public/build/target.zip

Comment 16

[taroxd]

It's probably gone. Thanks for all your efforts.

Comment 17

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

Thank you very much for your contribution!

Comment 18

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

Attachment: Bug 1418747 - ContentCacheInParent needs to initialize mPendingCommitLength with 0 when it's created

ContentCacheInParent::mPendingCommitLength is never initialized until it
receives eCompositionCommit(AsIs) event from widget or receives the latest
content from the remote process when there is a composition.

The bug is, immediately after dispatching eCompositionStart and first
eCompositionChange event, MS Pinyin tries to query the character at caret,
but ContentCacheInParent::HandleQueryContentEvent() tries to resolve
related position of an eQueryTextRect event with the uninitialized
mPendingCommitLength.  Therefore, the query almost always fails and MS Pinyin
gives up to show its candidate window.

This patch just initializes the member with 0.

Review commit: https://reviewboard.mozilla.org/r/203128/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/203128/

Comment 19

[Makoto Kato [:m_kato]]

Comment on attachment 8932069 [details]
Bug 1418747 - ContentCacheInParent needs to initialize mPendingCommitLength with 0 when it's created

https://reviewboard.mozilla.org/r/203128/#review208678

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/49312413af4e
ContentCacheInParent needs to initialize mPendingCommitLength with 0 when it's created r=m_kato

Comment 21

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

Comment on attachment 8932069 [details]
Bug 1418747 - ContentCacheInParent needs to initialize mPendingCommitLength with 0 when it's created

Approval Request Comment
[Feature/Bug causing the regression]:
Probably, regression of bug 1376417.

[User impact if declined]:
Chinese users cannot convert typed characters to Chinese characters smoothly in some cases. Looks like that this is really annoying.

[Is this code covered by automated tests?]:
No.

[Has the fix been verified in Nightly?]:
Not yet, but confirmed with tryserver build by the reporter.

[Needs manual test from QE? If yes, steps to reproduce]:
1. Install MS Pinyin (Simplified Chinese) on Windows 10 and make it active.
2. Open https://www.baidu.com in new tab (new process).
3. Type "nihao" with MS Pinyin.

Then, you should always see candidate window of the word.

[List of other uplifts needed for the feature/fix]:
No.

[Is the change risky?]:
No.

[Why is the change risky/not risky?]:
Because we forgot to initialize a member variable of ContentCacheInParent and it causes querying content outside focused editor. This patch just initializes it in the constructor.

[String changes made/needed]:
No.

Comment 22

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

Comment on attachment 8932069 [details]
Bug 1418747 - ContentCacheInParent needs to initialize mPendingCommitLength with 0 when it's created

Approval Request Comment
See above request for beta for the detail.

Although, this is a regression from 56 but the symptom may make damage with our market share in China since the IME is default IME of Simplified Chinese and the fix is really simple and not risky. So, I recommend to uplift this to release build if we have a change to do it.

Comment 23

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/49312413af4e

Comment 24

[Gerry Chang [:gchang]]

Comment on attachment 8932069 [details]
Bug 1418747 - ContentCacheInParent needs to initialize mPendingCommitLength with 0 when it's created

Fix an annoying IME issue that some Chinese users cannot convert typed characters to Chinese characters smoothly. Beta58+.

Comment 25

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-beta/rev/a9ce90a8eeab

Comment 26

[Gerry Chang [:gchang]]

Comment on attachment 8932069 [details]
Bug 1418747 - ContentCacheInParent needs to initialize mPendingCommitLength with 0 when it's created

As m-r is 58 now, remove approval‑mozilla‑release flag.

Comment 27

[taroxd]

Attachment: snipaste20180125_151109.png

Comment 28

[taroxd]

Attachment: log1-main.5748

Comment 29

[taroxd]

Attachment: log2-main.5748

Comment 30

[taroxd]

Attachment: expected.png

Comment 31

[taroxd]

After updating to Firefox 58, the candidate window may disappear after selecting the first word.

In snipaste20180125_151109.png, the bug is produced by these steps:

1. Type "nihao" in Microsoft Pinyin
2. Select "你" in the candidate window
3. The candidate window disappeared. A candidate window like the one in expected.png is expected.

log1-main.5748 is the log file with "nsTextStoreWidgets:5,ContentCacheWidgets:5,sync", and log2-main.5748 with "nsTextStoreWidgets:5,IMEContentObserver:5,sync"

Comment 32

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

Please file a new bug. Both your STR and attached log say that it's a different bug.