4.00 KB, text/html
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
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.
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.
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.