Text Inputting with IME is too slow & delay on macOS

RESOLVED FIXED in Firefox 66

Status

()

P3
normal
RESOLVED FIXED
5 months ago
2 months ago

People

(Reporter: tetsuharu, Assigned: m_kato)

Tracking

Trunk
mozilla66
Desktop
macOS
Points:
---

Firefox Tracking Flags

(firefox65 wontfix, firefox66 fixed)

Details

Attachments

(4 attachments, 3 obsolete attachments)

## 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.
## 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.
(Assignee)

Comment 2

5 months ago
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
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. https://hg.mozilla.org/mozilla-central/rev/be32f4014f92d0ab717621997e0d36c9bc1c479b

I'll continue to try to capture it.
Flags: needinfo?(saneyuki.snyk)
(Reporter)

Updated

5 months ago
Flags: needinfo?(saneyuki.snyk)
(Assignee)

Comment 4

5 months ago
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
    * 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.
Flags: needinfo?(saneyuki.snyk)
(Assignee)

Comment 6

5 months ago
[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
(Assignee)

Comment 7

5 months ago
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
(Assignee)

Comment 8

4 months ago
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.
(Assignee)

Comment 9

4 months ago
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
(Assignee)

Comment 10

4 months ago
Depends on D12628
Attachment #9026888 - Attachment is obsolete: true
Attachment #9026889 - Attachment is obsolete: true
Attachment #9026890 - Attachment is obsolete: true
(Assignee)

Comment 11

3 months ago
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.
(Assignee)

Comment 12

3 months ago
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
(Assignee)

Comment 13

3 months ago
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
(Assignee)

Updated

3 months ago
Assignee: nobody → m_kato

Comment 14

2 months ago
Pushed by m_kato@ga2.so-net.ne.jp:
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

2 months ago
bugherder
Status: NEW → RESOLVED
Last Resolved: 2 months ago
status-firefox66: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla66
status-firefox65: affected → wontfix
(Assignee)

Updated

2 months ago
Duplicate of this bug: 1303749
You need to log in before you can comment on or make changes to this bug.