Closed Bug 1502661 Opened 2 years ago Closed 2 years ago

Text Inputting with IME is too slow & delay on macOS


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




Tracking Status
firefox65 --- wontfix
firefox66 --- fixed


(Reporter: tetsuharu, Assigned: m_kato)




(4 files, 3 obsolete files)

## Environment

* Firefox Nightly, 65.0a1, build id 20181027100344
* 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
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,, 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.
## 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.
saneyuki-san, could you share profiling data via Gecko Profiler?  Document is here.
Flags: needinfo?(saneyuki.snyk)
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.

I'll continue to try to capture it.
Flags: needinfo?(saneyuki.snyk)
Flags: needinfo?(saneyuki.snyk)
If this doesn't occurs when using spellcheck=false for <textarea> element, this might be related to bug 1503491.
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
    * With enabling spellcheck

I continue to try to capture a problem with the situation which I reported originally.
Flags: needinfo?(saneyuki.snyk)
[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.
Component: Editor → Widget: Cocoa
Depends on: 1503491
Priority: -- → P3
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.
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.
LastPass will fill password to all input elements which InputType is
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
Attached file Bug 1502661 - Part 3. Add junit test (obsolete) —
Depends on D12628
Attachment #9026888 - Attachment is obsolete: true
Attachment #9026889 - Attachment is obsolete: true
Attachment #9026890 - Attachment is obsolete: true
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.
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
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
- spellchecker IPC is called per 25 (INLINESPELL_MINIUM_CHUNKED_WORDS_PER_TASK)

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
Assignee: nobody → m_kato
Pushed by
Part 1. Add async IPC to check word by spellchecker. r=masayuki
Part 2. Add async method to check word by spellchecker. r=masayuki
Part 3. Use async API for spell checking. r=masayuki
Duplicate of this bug: 1303749
Regressions: 1524443
You need to log in before you can comment on or make changes to this bug.