Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
Adobe Flex SDK Previous
-
None
-
None
-
Affected OS(s): Windows
Affected OS(s): Windows
Language Found: English
Description
Note: Reproducing this bug requires the in-line IME. So, the app must be run in a 10.1 Player.
Steps to reproduce:
1. Build and run an app with a RichEditableText tall enough to clearly see a line of Japanese text with its IME composition underlines. Like this:
<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
xmlns:s="library://ns.adobe.com/flex/spark"
xmlns:mx="library://ns.adobe.com/flex/mx" minWidth="955" minHeight="600">
<s:RichEditableText x="10" y="10" width="200" height="200"/>
</s:Application>
2. Make sure you have another program running besides the browser containing the app (ie: run Notepad).
3. Put focus into the RichEditableText and change input modes to Japanese/Hiragana.
4. Press the 'a' key several times, but do not press enter to commit.
5. Click on the other program's window, then click back on the browser containing the app. Note that the text still has its underline indicating that it hasn't been committed.
6. Press 'a' once. Note that the old underlined text disappears.
7. Press 'a' again. Note that the old underlined text comes back.
8. Press enter to try to commit the text.
Actual Results:
Text that was typed before clicking away from the browser and clicking back cannot be committed. It is stuck with the IME decorations. Exporting and inspecting the RichEditableText's content reveals some IME-related span attributes that shouldn't be there.
Expected Results:
IME text should not be left stuck in a non-committable state.
Workaround (if any):