Switching focus with uncommitted IME text does not commit or send events, and leaves corrupted text state.

RESOLVED FIXED in mozilla19

Status

()

RESOLVED FIXED
8 years ago
6 years ago

People

(Reporter: bugs, Assigned: masayuki)

Tracking

({inputmethod})

Trunk
mozilla19
x86
All
inputmethod
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

If there is uncommitted IME text, when switching focus the browser should either auto-commit the text or at least send an event so that Javascript can force-commit the text.  Today the browser provides neither, and after the user has switched focus weird unstable text gets left in both the elements you switched from, and the element you switched to.

Reproducible: Always

Steps to Reproduce:
1. Using Japanese IME, type some text in a designMode element and do not commit.
2. Using the mouse, switch focus to another element.

Actual Results:  
The text you were typing is not committed.  

No event sent to indicate the typing session lost focus.

The text you were typing gets duplicated into the second element.

The text you were typing is visually still in the first element but when you put focus back in it, the text was not really there.

Expected Results:  
The text you were typing is committed into the first element. 

An event is sent to indicate the typing session lost focus.

The text you were typing does not get duplicated into the second element.
(Reporter)

Comment 1

8 years ago
Created attachment 522615 [details]
Plain demonstration of uncommitted IME focus switching bug.
(Reporter)

Comment 2

8 years ago
Also note this appears to be present in both FF 3.6 and 4.0.
confirmed latest nightly of Win32 and MacOSX
Status: UNCONFIRMED → NEW
Component: General → Editor
Ever confirmed: true
Keywords: inputmethod
Product: Firefox → Core
QA Contact: general → editor
Version: unspecified → Trunk
This should be a DOM event handling issue rather than editor.

If there is a composition, all composition events on same top level window must be dispatched to composing element. But I've had no idea yet, what class should manage the last composition element in every *top level* window? nsIMEStateManager is static, so, it cannot do it. nsFocusManager is a singleton, it's not either.
Component: Editor → DOM: Events
OS: Windows 7 → All
QA Contact: editor → events
Hmm, the approach in my previous comment isn't enough. When the tab is being detached from its window, the composition should be committed (or discarded) *before* the detaching. If we don't do so, wrong transaction might remain on the old window.

Comment 6

8 years ago
Why would we need to keep reference to different composition elements?
I mean one in each top level window?

Couldn't there just be 2 global variables. previousCompositionElement and currentCompositionElement
When focus changes, composition could have already moved to currentCompositionElement, but we'd need to undo/commit the possibly 
uncommitted previousCompositionElement.

Updated

7 years ago
Duplicate of this bug: 681985
Depends on: 705057
Oops, sorry, I haven't realized your comment.

(In reply to Olli Pettay [:smaug] from comment #6)
> Why would we need to keep reference to different composition elements?
> I mean one in each top level window?

We can assume that one composition is available on one native IME context. With IMM on Windows, our process has only one native context. On Linux and Mac, our process has one context per top level window. I think that we need to manage composition transaction per native IME context.

> Couldn't there just be 2 global variables. previousCompositionElement and
> currentCompositionElement
> When focus changes, composition could have already moved to
> currentCompositionElement, but we'd need to undo/commit the possibly 
> uncommitted previousCompositionElement.

Currently, our editor tries to commit composition string forcibly when it loses focus or some methods which will change selection or content are called. The cause of this bug is, the focus change causes different presShell handles the composition events of the committing.

My patch for bug 705057 fixes this bug, please check it.
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
FYI: I'm planning to remove the forcibly commit (I think that it's bad custom of our editor) as far as possible in the future.
Fixed by bug 705057. It contains automated tests for this bug.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
You need to log in before you can comment on or make changes to this bug.