Closed Bug 1418747 Opened 2 years ago Closed 2 years ago

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

Categories

(Core :: Widget: Win32, defect)

56 Branch
All
Windows 10
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla59
Tracking Status
firefox-esr52 --- unaffected
firefox57 --- wontfix
firefox58 --- fixed
firefox59 --- fixed

People

(Reporter: taroxd, Assigned: masayuki)

References

Details

(Keywords: inputmethod, regression)

Attachments

(7 files)

Attached file 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.
Same here on, I also reproduce this unstably here on Bugzilla.
Component: Untriaged → Widget: Win32
Product: Firefox → Core
Summary: My Chinese Input Method, Microsoft Pinyin, does not show up on some webpages → Sometimes Microsoft Pinyin does not show up candidate box when the web page is loading
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.
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Ever confirmed: true
OS: Unspecified → Windows 10
Hardware: Unspecified → All
Summary: Sometimes Microsoft Pinyin does not show up candidate box when the web page is loading → [TSF] Sometimes Microsoft Pinyin does not show up candidate box when the web page is loading
Version: 57 Branch → 56 Branch
An uncertain range of regression: about 2017-08-10~11.

Bug 1386556?
Flags: needinfo?(masayuki)
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
Flags: needinfo?(masayuki)
(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.
(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.
(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.
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
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
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.
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.
Flags: needinfo?(taroxd)
Attached file log.txt-main.10100
The log file
Flags: needinfo?(taroxd)
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
Flags: needinfo?(taroxd)
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
It's probably gone. Thanks for all your efforts.
Flags: needinfo?(taroxd)
Thank you very much for your contribution!
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
Attachment #8932069 - Flags: review?(m_kato) → review+
Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/49312413af4e
ContentCacheInParent needs to initialize mPendingCommitLength with 0 when it's created r=m_kato
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.
Attachment #8932069 - Flags: approval-mozilla-beta?
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.
Attachment #8932069 - Flags: approval-mozilla-release?
Blocks: 1376417
Summary: [TSF] Sometimes Microsoft Pinyin does not show up candidate box when the web page is loading → [e10s][TSF] Sometimes Microsoft Pinyin does not show up candidate box when the web page is loading
https://hg.mozilla.org/mozilla-central/rev/49312413af4e
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
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+.
Attachment #8932069 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
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.
Attachment #8932069 - Flags: approval-mozilla-release?
Attached file log1-main.5748
Attached file log2-main.5748
Attached image expected.png
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"
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Please file a new bug. Both your STR and attached log say that it's a different bug.
Status: REOPENED → RESOLVED
Closed: 2 years ago2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.