1502661 - Text Inputting with IME is too slow & delay on macOS

Status: RESOLVED FIXED

(Core :: Widget: Cocoa, defect, P3)

Description

[Tetsuharu OHZEKI [:tetsuharu] (UTC+9)]

## Environment

* Firefox Nightly, 65.0a1, build id 20181027100344
* https://hg.mozilla.org/mozilla-central/rev/7007206a3cd46da7c478e5a9992b608b743a1ff9
* macOS Mojave 10.14（18A391）
* MacBook Pro (15-inch, 2017), CPU 2.8 GHz Intel Core i7, 16 GB 2133 MHz LPDDR3, GPU Intel HD Graphics 630 1536 MB
* Using macOS' default Japanese IME.

## Steps to reproduce

1. Open https://twitter.com/.
2. Focus to their text input area.
3. Input some texts with enabling Japanese IME.


## Actual Result

* Showing a text which I'm inputting is too slow (delay).
* This problem happens with plain <textarea/>. But it's striking with a rich text editor on Web Application, such Google Docs, Gmail's mail editor, https://hangouts.google.com/, or twitter's text form.



## Expected Result


* Not Slow.



## Remarks

* I don't know when this problem has begun... But I seem this problem is striking these days.
* A text input with Japanese IME is actually slow on recently macOS. But it's especially slow on Firefox.
    * I feel this problem is a little relaxed if I disable "ライブ変換 (I don't know this feature's English name)". But it does not improve much.
* I seem this problem happens if I open a many tabs in background. But it sometimes happens if I open a single tab.

Comment 1

[Tetsuharu OHZEKI [:tetsuharu] (UTC+9)]

## Remarks 2


* This is not happens when I input a text directly (without using Japanese IME).
    * This problem is painful for me because I cannot choose to input a long Japanese text on Web Application.

Comment 2

[Makoto Kato [:m_kato]]

saneyuki-san, could you share profiling data via Gecko Profiler?  Document is here. https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler

Comment 3

[Tetsuharu OHZEKI [:tetsuharu] (UTC+9)]

I'm trying to capture the profile, but I have not faced to the similar case yet after upgrading macOS to 10.14.1 and with using newer Firefox Nightly. https://hg.mozilla.org/mozilla-central/rev/be32f4014f92d0ab717621997e0d36c9bc1c479b

I'll continue to try to capture it.

Comment 4

[Makoto Kato [:m_kato]]

If this doesn't occurs when using spellcheck=false for <textarea> element, this might be related to bug 1503491.

Comment 5

[Tetsuharu OHZEKI [:tetsuharu] (UTC+9)]

Attachment: input_on_github_issues_textarea_macos10.14.0_with_enabling_spellcheck.sps.json.gz

The behavior is a bit different, but I faced to a similar problem that Firefox is busy when I typing a text to a textarea of GitHub Issue's comment, and I success to capture the profile. 

In this case, Firefox is busying completely while seconds and it looks Firefox blocked to text inputting.
I capture this profile with the environment:

* macOS Mojave 10.14.0（18A391）
    * I found the machine which has not updated to 10.14.1 yet.
    * MacBook Pro (15-inch, 2017), CPU 2.8 GHz Intel Core i7, 16 GB 2133 MHz LPDDR3, GPU Intel HD Graphics 630 1536 MB
* Firefox Nightly
    * https://hg.mozilla.org/mozilla-central/rev/be32f4014f92d0ab717621997e0d36c9bc1c479b
    * With enabling spellcheck


I continue to try to capture a problem with the situation which I reported originally.

Comment 6

[Makoto Kato [:m_kato]]

[NSView interpretKeyEvents:] spends a lot of time... But I think that if we fix bug 1503491, content process isn't busy, so perfomance will improve.

Comment 7

[Makoto Kato [:m_kato]]

We need fix a11y before fixing this.  a11y watches selection change of spellchecker, but it doesn't wait wheather it is finished. So if we change spellchecker to async, a11y tests will be failed.

a11y should use INLINESPELL_ENDED_TOPIC observer instead.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=49f660871864b027905816f47dec2c2a2dfc7c88
https://treeherder.mozilla.org/#/jobs?repo=try&revision=7125703eaa09388b61f306a0ec0b15d0745caf96

Comment 8

[Makoto Kato [:m_kato]]

Attachment: Bug 1502661 - Part 1. Add API to recognize username field and password field from a field in form. r?MattN

I would like to get username fields etc from form or input element in form.

Since LoginManagerContent._getFormFields has "_" prefix (it means private
member) and LoginManagerCotnent.getFieldContext doesn't return elements,
I would like to add simple API for it.

Also, it doesn't have FormLikes parameter, I cannot write unit test like
getFieldContext.  Unit test will be followed by GeckoView junit.

Comment 9

[Makoto Kato [:m_kato]]

Attachment: Bug 1502661 - Part 2. Don't set inputType to all <input type=text>.

LastPass will fill password to all input elements which InputType is
TYPE_CALSS_TEXT and TYPE_TEXT_VARIATION_WEB_EDIT_TEXT and has no AutofillHint.
And it will fill username when InputType and AutofillHint is nothing in
<input type="text">.

Actually, current implementation of GeckoView sets InputType only for
<input type="text">, so LastPass fills password to all <input type="text">

So as workaround, we should set InputType and AutofillHint when input element
presumes username fields.

Depends on D12627

Comment 10

[Makoto Kato [:m_kato]]

Attachment: Bug 1502661 - Part 3. Add junit test

Depends on D12628

Comment 11

[Makoto Kato [:m_kato]]

Attachment: Bug 1502661 - Part 1. Add async IPC to check word by spellchecker. r?masayuki

Actually we have no async IPC for spellchecker, so I would like to add async
IPC to check word.

When using full check, spellchecker requests a lot of words to check word. New
async IPC should allow multiple words per IPC to reduce IPC call.

Comment 12

[Makoto Kato [:m_kato]]

Attachment: Bug 1502661 - Part 2. Add async method to check word by spellchecker. r?masayuki

For mozInlineSpellChecker, I would like to add promse-based method to check
word. But this method is

- On content process, it works by async.
- On chrome process, it works by sync.

Some reftests with non-e10s don't wait that spellchecker is finished correctly
due to race condition of spellchecker dictionary update.  So it uses sync'd
promise on chrome.

Depends on D14835

Comment 13

[Makoto Kato [:m_kato]]

Attachment: Bug 1502661 - Part 3. Use async API for spell checking. r?masayuki

Previous implementation is

- Use idle runnable for spellchecker
- If spellchecker runnable spends 1ms (with 5 words), spellchecker is suspended,
  then resume it after 1s.
- If misspell is 3/4 of extensions.spellchecker.inline.max-misspellings per
  DoSpellCheck, spellchecker is stopped.

After this change, IPC is async, so we cannot count misspell words without
waiting the result of async call.  So I would like to change to

- Use idle runnable for spellchecker
- If spellchecker runnable spends 1ms (with 5 words), spellchecker is suspended,
  then resume it after 1s.
- If misspell reaches extensions.spellchecker.inline.max-misspellings, stop
  spellcheck.
- spellchecker IPC is called per 25 (INLINESPELL_MINIUM_CHUNKED_WORDS_PER_TASK)
  words.

As long as my MacBook (Core m3), spellchecker can check 100-150 words per 1ms
after this fix.  Should INLINESPELL_MINIUM_CHUNKED_WORDS_PER_TASK be prefs?

Also, this define is less than 5, a lot of a11y tests will be failed.  Because
it uses selection listener to count all misspell words without waiting completion.

Depends on D14836

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/ae2e40fee316
Part 1. Add async IPC to check word by spellchecker. r=masayuki
https://hg.mozilla.org/integration/mozilla-inbound/rev/77ec2b95a664
Part 2. Add async method to check word by spellchecker. r=masayuki
https://hg.mozilla.org/integration/mozilla-inbound/rev/683f9ffb0443
Part 3. Use async API for spell checking. r=masayuki

Comment 15

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/ae2e40fee316
https://hg.mozilla.org/mozilla-central/rev/77ec2b95a664
https://hg.mozilla.org/mozilla-central/rev/683f9ffb0443