Closed Bug 1153733 Opened 9 years ago Closed 9 years ago

[e10s] Candidate window isn't located on correct position on 10.10 with Apple input method

Categories

(Core :: Widget: Cocoa, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla42
Tracking Status
e10s m8+ ---
firefox40 --- affected

People

(Reporter: m_kato, Assigned: m_kato)

References

Details

      No description provided.
When this occurs, FirstRectForCharacterRange will return empty rect.  Maybe this issue occurs when length parameter is 0.
Blocks: e10s-ime
Please give STR for this bug, and possibly also a screenshot.

I'll be able to read the STR if you make it use Japanese or Chinese.
Flags: needinfo?(m_kato)
OS: Windows 8.1 → Mac OS X
> OS: Windows 8.1 → Mac OS X

By the way, I assume you saw this on OS X (or you wouldn't have categorized this bug as Widget : Cocoa).  But did you?
Root cause is comment #1.  Since we don't cache requested caret position (ex. position: 0, length: 0) on chrome process, FirstRectForCharacterRange will return empty rect.  So this issue occurs.

- Env
OSX 10.10 Yosemite with Apple Japanese Input method (until 10.9, it was Kotoeri)

- Step
1. Restart as e10s mode
2. Focus editbox on web content
3. Input 'あああ' and hit space as convertion

- Result
candidate window isn't located on under editbox.  It will be left-bottom on screen.
Flags: needinfo?(m_kato)
I must reconsider caret rect cache strategy for this issue or use TEXT_RECT for fallback.
Thanks!

In step 3 I had to press the space key twice to make the candidate window appear.  I tested with today's m-c nightly in a clean profile on OS X 10.10.2, 10.9.5 and 10.9.5.  I only see this bug on OS X 10.10.2 -- on that OS the candidate window appears in the lowest left part of the screen (which isn't correct).  On OS X 10.9.5 and 10.8.5 the candidate window appears in an appropriate location.

I just wanted to have STR for this on record.

I'm happy to leave this bug in your hands :-)
Depends on: 1120851
caret cache on chrome process will be updated by 1120851.  But we need more hacks for this.  I's still investigating...
Depends on: 1168005
Depends on: 1167105
All patches are landed.

When I and Yoshinaga-san test e10s IME on textbox, textarea and contenteditable using Yosemite + Apple IME, it works fine.  I resolve this as FIXED.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
You need to log in before you can comment on or make changes to this bug.