The default bug view has changed. See this FAQ.

For Flash Text Input, previous characters disappear when changing IME input from one type to another

VERIFIED FIXED in mozilla6

Status

()

Core
Widget: Cocoa
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: Clyde Sy, Assigned: masayuki)

Tracking

({inputmethod})

Trunk
mozilla6
x86_64
Mac OS X
inputmethod
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16
Build Identifier: Firefox 4.0.1

When you are inputting Flash Text for Firefox 4. If you change the IME input from one type to the next, the characters entered previously disappeared.





Reproducible: Always

Steps to Reproduce:
1. Open TextArea-3.swf that is simple swf that contains the flash text field on Firefox4 64 bit.
 
2. Focus the text field.
 
3. Select Japanese Hiragana IME.
 
4. Type Japanese Hiragana Characters such as [aaaaa] "あああああ"
 
5. Change the Input Mode to Japanese Katakana IME.
Actual Results:  
The complex input window with typed characters "あああああ" disappears.

Expected Results:  
In general, if it was the same IME, even if the conversion mode ( such as Hiragana to Katakana ) was changed, the complex input window keeps displaying. user can continue inputting characters from IME.

In the Firefox4 code at:
http://hg.mozilla.org/mozilla-central/file/27d6a4a5e20f/widget/src/cocoa/ComplexTextInputPanel.mm

It cancel the IME inputs when input mode was changed in this code :
----------------------------
- (void)keyboardInputSourceChanged:(NSNotification *)notification
 {
   [self cancelComposition];
}
----------------------------

Updated

6 years ago
Component: General → Widget: Cocoa
Keywords: inputmethod
Product: Firefox → Core
QA Contact: general → cocoa
Version: unspecified → Trunk
(Assignee)

Comment 1

6 years ago
Sure.

Steven, Josh:

Why did you write it? Is there a problem?
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

6 years ago
I don't remember why I wrote it that way.
(Assignee)

Comment 3

6 years ago
Okay, I'll write a patch which can switch the behavior by pref. If it doesn't have problem in next a couple of months, we should remove it.
(Assignee)

Comment 4

6 years ago
Created attachment 531257 [details] [diff] [review]
Patch v1.0
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Attachment #531257 - Flags: review?(smichaud)
Comment on attachment 531257 [details] [diff] [review]
Patch v1.0

This looks fine to me.
Attachment #531257 - Flags: review?(smichaud) → review+
(Assignee)

Comment 6

6 years ago
http://hg.mozilla.org/mozilla-central/rev/e50a469db691
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
(Reporter)

Comment 7

6 years ago
I verified that the patch fixes the issue on the nightly build. Thank you for the fix.
(Reporter)

Comment 8

6 years ago
I verified that the patch fixes the issue on the nightly build. Thank you for the fix.

Comment 9

6 years ago
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20100101 Firefox/6.0 - beta 2
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0a1) Gecko/20110720 Firefox/8.0a1

Verified issue using steps from Comment 0, on both 6.0b2 and 8.0a1. Setting status to Verified Fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.