292473 - TSM Inline input misbehaves after window deactivation

Status: VERIFIED FIXED

(Camino Graveyard :: HTML Form Controls, defect)

Description

[Alexey Proskuryakov]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; ru-ru) AppleWebKit/312.1 (KHTML, like Gecko) Safari/312
Build Identifier: 2005042908 (v0.8+)

After a window with unconfirmed inline input is deactivated and re-activated, the contents of the inline 
input area get duplicated.

Reproducible: Always

Steps to Reproduce:
1. Go to www.google.com
2. Type something with Kotoeri or any other input method that uses inline input
3. Open and close About dialog (Camino->About Camino)
4. Continue typing
Actual Results:  
The contents of the inline input area are duplicated

Expected Results:  
The inline input should be confirmed on deactivation (as in Firefox)

This issue is not present in Firefox 1.0.3

Comment 1

[Hiro]

Confirm.

Mac OS X 10.3.9
2005050221 (v0.8+)

>This issue is not present in Firefox 1.0.3
In Firefox, when focus moves to other places in Japanese input, a present input
is compulsorily fixed. 
Therefore, the problem doesn't happen even if it returns and the input is 
continued. 

Comment 2

[Mike Pinkerton (not reading bugmail)]

is this a regression on the trunk from 0.8, or does it not work in 084 either?

Comment 3

[Hiro]

In 0.8.4 release, there was no problem. 

Comment 4

[Mike Pinkerton (not reading bugmail)]

ok, then we should fix this regression for 0.9

Comment 5

[Simon Fraser [no longer active]]

To fix this we need some window-level logic that kicks TSM deactivate when the
window loses focus (since all our focus stuff keys off the first responder now,
and that doesn't change when window layering changes).

Comment 6

[Simon Fraser [no longer active]]

Hmm, neither Firefox nor Safari commit inline input on window deactivation (I
still see the underline), and even if I try (by calling -unmarkText), the
duplication still happens. I think there's something else at work here.

Comment 7

[Alexey Proskuryakov]

For me, the inline input session is confirmed in Firefox when following the steps to reproduce (i.e., 
opening About box). When the window is deactivated in some other way, it's not, see bug 292474. 

I think that the behavior you observe with unmarkText may be normal - to confirm an inline session, one 
needs to call FixTSMDocument() from TextServices.h. The documentation for unmarkText seems a bit 
vague to me.

Comment 8

[Simon Fraser [no longer active]]

Patch in bug 182783 contains the fix for this.

Comment 9

[Simon Fraser [no longer active]]

Fixed by the checkin for bug 182783.

Comment 10

[Alexey Proskuryakov]

Verified with 2005070108 (v0.9a1+). 

The behavior is different from what I expected (inline input is not auto-confirmed, but is correctly 
restored), but it's also fine. However, more care will be needed when text fields learn to accept 
drag&drop - dropping into unconfirmed inline input areas doesn't work correctly with most text 
engines, including NSTextView.

A very similar activation/deactivation problem happens when switching between text controls within a 
page, see bug 299516.