JDK-8261231 : Windows IME was disabled after DnD operation
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version:
    8u281,11.0.10,11.0.10-oracle,15.0.2,16,17 8u281,11.0.10,11.0.10-oracle,15.0.2,16,17
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • CPU: x86
  • Submitted: 2021-02-05
  • Updated: 2021-04-05
  • Resolved: 2021-02-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 15 JDK 16 JDK 17 JDK 8 Other
11.0.11Fixed 15.0.4Fixed 16.0.1Fixed 17 b09Fixed 8u301Fixed openjdk8u292Fixed
Related Reports
Relates :  
JDK-8262446 - DragAndDrop hangs on Windows
Relates :  
JDK-8252470 - java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java fails on Windows
Description
When I open a new window after a DnD operation, IME does not work for that window.
I assume this issue is related JDK-8252470.

Please try following operations on Windows which has IME, like Japanese Windows:
1. Compile and run WinDnDTest
2. Press "Create New Window" button twice by mouse
   2 windows are opened, Windows IME should work on these windows
3. Select some strings by mouse on one of window
4. Drag selected strings and drop it into another window
5. Press "Create New Window" button
   Window is opened, but Windows IME does work on this window
Comments
Fix request (15u): bug reproduced in the current state jdk15u-dev (with JDK-8252470) and fix worked there as expected. Applied without changes. Will set labels after the testing completion.
05-04-2021
Approving for 8u292 since JDK-8252470 went into 8u292 as well which caused this issue.
24-02-2021
Fix Request (8u): Backport to 8u292 requested because this patch fixes a user-facing AWT issue (i18n input disabled with no workaround) that was introduced in 8u292 (8u282 was not affected). Patch applies cleanly to 8u-dev after paths changing, exported 8u patch with original attribution: https://cr.openjdk.java.net/~akasko/jdk8u/8261231/8261231_8u.patch Testing: checked that the issue can be reproduced with WinDnDTest.java on current 8u292 and doesn't happen with the patch, ran jck:api/java_awt .
22-02-2021
Ichiroh Takiguchi, thanks! JDK-8252470 , that introduces this issue, went into 8u281-oracle, but not into openjdk8u282. It is included with openjdk8u292 and the issue can be reproduced with 8u292-b03 EA (and current jdk8u-dev tip). openjdk8u292 is close to rampdown ( https://wiki.openjdk.java.net/display/jdk8u/Main#Main-Timelines ), I will propose this fix for openjdk8u292, it is up to maintainers to include it.
22-02-2021
Hello Alex, thank you for your attention. I'm not familiar with 8u. I really appreciate if you handle 8u backport. BTW, I checked OpenJDK jdk8u/jdk8u-dev repositories, next release may be 8u292. But your target is 8u302 ? I checked OpenJDK 8u reference build which is in AdoptOpenJDK site. https://adoptopenjdk.net/upstream.html Current one is OpenJDK 8u282, Early Access is OpenJDK 8u292. I checked OpenJDK 8u282 reference build, I could not recreate this issue by OpenJDK 8u282. Is it possible to apply this issue against 8u292 if it's not frozen ?
20-02-2021
Ichiroh Takiguchi, hi, I've backported JDK-8252470 to 11u and 8u in the past and was looking to backport this issue to 11u and 8u too. Please let me know, if you prefer to backport it to openjdk8u302 yourself. Thanks!
19-02-2021
Fix Request (jdk11u-fix-request) I'd like to request the fix in 11u because it's regression issue for 8252470. The patches could apply cleanly.
19-02-2021
[~dmarkov] If it makes sense, could this fix be back ported to 16u ?
12-02-2021
Fix Request (16u) - Justification: The changes fix the regression introduced by JDK-8252470 - Risk Analysis: Low, small changes in awt_Toolkit.cpp - Testing: The fix may be verified using the test attached to the bug (see steps to reproduce above) The patch from jdk-dev (17) applies cleanly to 16u.
12-02-2021
Changeset: d6d5d9bf Author: Dmitry Markov <dmarkov@openjdk.org> Date: 2021-02-08 17:09:09 +0000 URL: https://git.openjdk.java.net/jdk/commit/d6d5d9bf
08-02-2021
I tested your fix. https://github.com/openjdk/jdk/pull/2448 It's fine.
08-02-2021
The function InvokeInputMethodFunction() is responsible for invocation of IME API. Typically it uses PostMessage() to execute corresponding IME function on the toolkit thread but if DnD operation takes place SendMessage() is used. The state of m_inputMethodWaitEvent event object remains signalled after SendMessage() execution. That causes failure of subsequent IME functions calls via PostMessage(). Fix: SendMessage() and PostMessage() calls inside InvokeInputMethodFunction() should be synchronised. The state of m_inputMethodWaitEvent event object must be reseted right after SendMessage() execution.
05-02-2021
Sorry, I put wrong one. Please use the latest WinDnDTest.java for your testing.
05-02-2021
Dmitry, could you check this issue is related JDK-8252470 or not ?
05-02-2021