Closed Bug 1422230 Opened 2 years ago Closed 2 years ago

[TSF] MS Quick Input may not show candidate window for related words of committed string

Categories

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

All
Windows
defect

Tracking

()

RESOLVED FIXED
mozilla59
Tracking Status
firefox59 --- fixed

People

(Reporter: pa12345u, Assigned: masayuki)

References

Details

(Keywords: inputmethod)

Attachments

(7 files)

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

Steps to reproduce:

I am using windows 10.
After i updated my firefox to version 57 (64 bit). 
When I type in traditional chinese using 'Quick input method' '速成輸入法'. 
The problem only occured in firefox 57. No same problem occured in IE, other applications and previous firefox versions.


Actual results:

It is normal when I type each single traditional chinese words. But the 'related words' list cannot show up and disabled.


Expected results:

Normally, when I type a single traditional chinese word, the 'related words' list will show up and I can select the related word with press down shift and number key.
Please help to fix it.
Component: Untriaged → Widget: Win32
Keywords: inputmethod
Product: Firefox → Core
Looks like same bug as bug 1418747 and it's already been fixed on Beta. Do you still reproduce it with the latest Beta build?
Flags: needinfo?(pa12345u)
Is it the latest Beta build 58.0b8?
I have still encountered the same problem with that.
Flags: needinfo?(pa12345u)
(In reply to pa12345u from comment #2)
> Is it the latest Beta build 58.0b8?
> I have still encountered the same problem with that.

Yes, it is. Hmm, okay, I will investigate it. Could you tell me more detail of steps to reproduce it? Please explain what keys should be typed and when the "related words" should be shown. Perhaps, writing it as list with number must be easier to understand.  E.g.,

> 1. Press left shift key to make input mode Chinese.
> 2. Type 'a'
> 3. Type 'b'
> 4. Type space
> 
> At #2, related words including '大' should be shown.
Flags: needinfo?(pa12345u)
And if you reproduce this bug only in some specific websites, let me know.
Ok, I use my attached screen cap as a example.
In the screen cap I have attached, you can see that a have already typed a chinese word '你' in the google search bar.
And the 'related words' are that:
'1.們
2.我
3.老
4.等
5.死我活
6.推我讓'

So, the steps to reproduce it are shown below:
1.Add the Tranditional Chinese (Whatever Taiwan or Hong Kong it are equal)
2.Add the Microsoft Quick as a input method, if it shown the chinese input method name, it should be'微軟速成'
3.Switch to the Tranditional Chinese and choose the Microsoft Quick as the input method
4.Press left shift key to make input mode Chinese
5.Type 'o'
6.Type 'f'
(At this time, a box will be shown like:
'1.伙
2.你
3.係
4.偽
5.氮
6.焦
7.無
8.絛
9.僚'
And it is a box shown that what words you can choose)
7.Type '2'
8.The Chinese works '你' will be typed.
(At this time, the 'related words' box should be shown automatically if its work normally.
The 'related words' box should be as shown below:
'1.們
2.我
3.老
4.等
5.死我活
6.推我讓'

and you can type the word/s shown in 'related words' box by the following step:
1.Press left shift key with a number key e.g.:number key'1'
2.the word '們'will be typed behind the word '你'. Two Chinese words '你們' will be typed on the Google search bar like the screen cap.)

But the bug occued and the 'related words' box didnt be shown and work automatically in firefox 57.
So you can try the same steps on IE to repreduce how the 'related words' box works normally.
The 'related words' box maybe work sometime properly, but the most time dosen't.


Thank you so much and tell me if any information you want.
Flags: needinfo?(pa12345u)
Not only in some specific websites, this bug occured in all websites.
However, there is no same bug when I type in a flash player.
Priority: -- → P2
Sorry for the log delay and thank you for the detail of STR.

However, I cannot reproduce this bug even with Nightly, Firefox 57 on Win10, on any page (including google.com where you used to get a screenshot). There must be other condition(s) to reproduce this bug.

pa12345u:

If you don't mind, could you attach a log file to this bug? You can get a log file with setting following environment variables:

MOZ_LOG=nsTextStoreWidgets:5,ContentCacheWidgets:5,sync
MOZ_LOG_FILE=c:\Users\<user name>\fx.log

Then, launch Firefox, and do:

1. Load a page from bookmark or something which can reproduce this bug (please don't type anything from keyboard).
2. Set focus by mouse to an editor.
3. Type left Shift key if IME is closed.
4. Type 'o' and 'f', then, type '2' to choose '你'
5. (Then, you must reproduce this bug.)
6. Close Firefox with mouse.
7. Attach the log file created in your home folder from the link above this page (labelled as "Attach File")

Note that don't type anything your privacy like passwords because the log file includes any characters coming via IME.
Flags: needinfo?(pa12345u)
Attached file Attach File
Flags: needinfo?(pa12345u)
Attached the log file, please find it.
Attachment #8939133 - Attachment mime type: text/x-log → text/plain
Thank you for the log file!

According to the log file, your Firefox instance returns TS_E_NOLAYOUT when MS Quick Input queries character rect of committed '你' for deciding next candidate window position. We have a lot of hacks for this issue during composition. However, in your case, MS Quick Input queries the commit string ('你') before child process handles it.
Assignee: nobody → masayuki
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
OS: Unspecified → Windows
Hardware: Unspecified → All
Summary: Traditional Chinese typing Not Work normally in Firefox 57 → [TSF] MS Quick Input may not show candidate window for related words of committed string
Version: 57 Branch → Trunk
Could you test this bug with this patched build?
https://queue.taskcluster.net/v1/task/PzWeoC4nT0eDjIhKaYVy5A/runs/0/artifacts/public/build/target.zip

If you still see this bug even with this build, could you attach new log file of this build?
Flags: needinfo?(pa12345u)
The candidate window shows normally this time.
Flags: needinfo?(pa12345u)
See Also: → 1428667
Comment on attachment 8942074 [details]
Bug 1422230 - part 1: TextEventDispatcher should manage if dispatched composition events have been handled by remote content and TSFTextStore refer the state

https://reviewboard.mozilla.org/r/212294/#review218432
Attachment #8942074 - Flags: review?(m_kato) → review+
Comment on attachment 8942075 [details]
Bug 1422230 - part 2: ContentCacheInParent should allow to query content relative to composition string even after sending eCompositionCommit(AsIs) event but not yet handled in the remote process

https://reviewboard.mozilla.org/r/212296/#review218450
Attachment #8942075 - Flags: review?(m_kato) → review+
Comment on attachment 8942076 [details]
Bug 1422230 - part 3: TSFTextStore should store composition string information until both TSF/TIP and our content finish handling composition

https://reviewboard.mozilla.org/r/212298/#review218452
Attachment #8942076 - Flags: review?(m_kato) → review+
Comment on attachment 8942077 [details]
Bug 1422230 - part 4: TSFTextStore::GetTextExt() should refer composition string in content

https://reviewboard.mozilla.org/r/212300/#review218454
Attachment #8942077 - Flags: review?(m_kato) → review+
Pushed by masayuki@d-toybox.com:
https://hg.mozilla.org/integration/autoland/rev/7eb571ca5f14
part 1: TextEventDispatcher should manage if dispatched composition events have been handled by remote content and TSFTextStore refer the state r=m_kato
https://hg.mozilla.org/integration/autoland/rev/9aa31af5773b
part 2: ContentCacheInParent should allow to query content relative to composition string even after sending eCompositionCommit(AsIs) event but not yet handled in the remote process r=m_kato
https://hg.mozilla.org/integration/autoland/rev/d02c066d501b
part 3: TSFTextStore should store composition string information until both TSF/TIP and our content finish handling composition r=m_kato
https://hg.mozilla.org/integration/autoland/rev/3700de32eedb
part 4: TSFTextStore::GetTextExt() should refer composition string in content r=m_kato
Duplicate of this bug: 1428667
Duplicate of this bug: 1433085
You need to log in before you can comment on or make changes to this bug.