tree 048a3ace64cd2909b71ef329d409f74686b84a75
parent d4322185047c83ff4f7f4c994db4c89a401c73ca
author Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> 1560336726 +0200
committer Niraj Modi <niraj.modi@in.ibm.com> 1561619415 -0400

Bug 543747 - [win32] JVM crash after connecting Windows Remote Desktop

Changes
-------
1) ImmAssociateContext(0) replaced with ImmAssociateContext(oldContext)
   This avoids Windows bug in MSCTF.DLL
2) Refactoring: Shell no longer inherits HIMC through
   Control.createHandle() before replacing it with a new HIMC in
   Shell.createHandle().
   This probably didn't cause any problems.
3) Refactoring: Connection between HIMC in Control and Shell is more
   visible now.
4) Added win32 manual tests, similar to GTK.

Internal map is not cleaned properly
------------------------------------
1) 'TextInputFramework!TextInputClient' contains an internal std::map
   This map keeps track (through multiple wrappers) of input contexts.
2) For 'Edit' controls, Windows uses different input context
   'MSCTF!CCompositeContextAdapter' inherits from 'MSCTF!CInputContext'.
   It is a wrapper for two 'MSCTF!CInputContext', where the second one
   is affected by 'ImmAssociateContext' WINAPI.
   I think that this is related to recently added emoji input panel.
3) 'MSCTF!CCompositeContextAdapter' is not removed on focus change
   'MSCTF!CInputContext::IsImmContext' contains some logic.
   'MSCTF!CCompositeContextAdapter::IsImmContext' always returns FALSE.
   This causes 'MSCTF!CInputContextAdapter::OnFocusChange' to skip
   branch that removes it from map when input focus leaves Edit.
   I think that this is a bug of 'IsImmContext' which returns FALSE.
   I imagine that it should return TRUE after 'ImmAssociateContext'.
4) Map is not cleaned when Edit has intermediate parent
   Map is also cleared when window or its parent is destroyed.
   But when Edit has two parents and the outer parent is destroyed,
   this code doesn't recognize the Edit and skips it.
   I think that this is a design flaw.
5) Map item is re-added when Edit is destroyed while having focus
   When Edit has focus while being destroyed, it's re-added to map in
   'SetFocus' handler. 'SetFocus' gets called as part of 'DestroyWindow'
   to pass input focus to some window.
   I think this that is a bug in Windows where it's not properly taken
   into account that Edit is being destroyed and should not be re-added.

'CCompositeContextAdapter' reference counting bug
-------------------------------------------------
1) 'MSCTF!CCompositeContextAdapter' uses 'MSCTF!CInputContext'
   without adding a reference.
   I think that this this is a bug in Windows.
2) Call to 'ImmAssociateContext(hwnd, 0)' fails to forget the dangling
   pointer. It will only forget old pointer if 'ImmAssociateContext' is
   used with some other non-NULL context.
   I think that this is not a problem on its own, but causes crash in
   combination with other bugs.
3) Call to 'ImmDestroyContext' destroys the 'MSCTF!CInputContext'
   This leaves a dangling pointer in 'MSCTF!CCompositeContextAdapter'.

Combined result
---------------
For many reasons, input contexts can stay in map forever.
'ImmDestroyContext' causes map to contain item with dangling pointer.
On certain actions entire map will be iterated.
If map contains items with dangling pointers, it will crash.

Change-Id: I78b7f75d86bb72d0746bc1455db61af9869ab839
Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com>