Closed Bug 1329474 Opened 7 years ago Closed 7 years ago

Korean is not typed properly at Firefox, MacOS Sierra.

Categories

(Core :: Widget: Cocoa, defect, P3)

Product:
Core
Component:
Widget: Cocoa
Version:
50 Branch
Platform:
x86
macOS
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: deadpanj, Unassigned)

References

Details

(Keywords: inputmethod, Whiteboard: tpi:+)

Attachments

(2 files)

Log file on my environment (typed 테스트 with 3-set 390)
85.96 KB, text/plain
Details
Typed "'테스트" at 3set 390 Korean. The result is "테ㅡㅡ".
93.41 KB, text/plain
Details 
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161208153507

Steps to reproduce:

1. I type any Korean letters at least 2 letters, for instance "테스트(means test)" at Firefox such as the address bar or the search bar.



Actual results:

1. It typed as “테ㅡㅡ” instead of "테스트". In other words, Firefox omits the 2 consonant ("ㅅ"and 2nd "ㅌ"). 

2. Sometimes (1 of 10 times) the word typed properly(and I don’t know why they can). But still at this situation the cursor sticks to the last letter so if I type Korean to search at Firefox, I have to pace bar or enter to end the typing. In other words, if I typed “테스트” at search bar or address bar and hit enter, it only ended my typing and doing nothing so I have to hit enter again so they search something. 


Expected results:

It should be show "테스트" and when I hit enter they search the word or doing something. 

I posted this issue at support forum and somebody said it should be a bug. So I submit it. My question at support forum is https://support.mozilla.org/en-US/questions/1153207
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86
Can you try Firefox Beta or Nightly?
Some fixes are applied there.
Component: Untriaged → Widget: Cocoa
Keywords: inputmethod
Product: Firefox → Core
(In reply to Tooru Fujisawa [:arai] from comment #1)
> Can you try Firefox Beta or Nightly?
> Some fixes are applied there.

I tried beta version (Firefox 51.0b12) and Nightly (firefox-53.0a1.ko.mac) but all the same. I think Firefox's something related to Korean input source is not working properly with macSierra's Korean input source. Thanks for reply.
Which Korean IME are you using? We've fixed such bugs with 2-set Korean or similar IMEs (bug 1317906 comment 3), I'd be surprised if there were still such regressions...

And could you explain how to type "테스트" with ANSI keyboard layout? (I mean I want to know which key sequence can type the word.)
Flags: needinfo?(deadpanj)
And do you reproduce it in every input field? I.e., do you reproduce it in web contents like this page? If it's not so, it might be a bug of add-ons, could you check if it's reproducible with clean profile?
(In reply to Masayuki Nakano [:masayuki] from comment #3)
> Which Korean IME are you using? We've fixed such bugs with 2-set Korean or
> similar IMEs (bug 1317906 comment 3), I'd be surprised if there were still
> such regressions...
> 
> And could you explain how to type "테스트" with ANSI keyboard layout? (I mean I
> want to know which key sequence can type the word.)

(In reply to Masayuki Nakano [:masayuki] from comment #4)
> And do you reproduce it in every input field? I.e., do you reproduce it in
> web contents like this page? If it's not so, it might be a bug of add-ons,
> could you check if it's reproducible with clean profile?


I use macOS default 3-set 390 which is minority layout. And default 2-set also have a same problem. At clean profile the bug is still there. 

And now I uninstalled Firefox completely with AppCleaner and reboot, and reinstalled Firefox and remains everything at first install and not synced yet. At this clean profile at first bug 1.(테ㅡㅡ) again and after a while bug 2.(I think it is identical with bug 1317906). 

I took screenshots here: I typed 4 "테스트" each. 
bug 1. https://www.dropbox.com/s/w04mfk5dxvqvrqk/1_screenshot%202017-01-08%20%EC%98%A4%ED%9B%84%2011.40.38.png?dl=0
bug 2. https://www.dropbox.com/s/ppsa69fzxg9v8l1/2_screenshot%202017-01-08%20%EC%98%A4%ED%9B%84%2011.43.07%283%29.png?dl=0

And does ANSI keyboard layout means QWERTY? If it's correct, you can type "테스트" of 3-set 390 by type "'cng'g", and of 2-set by type "xptmxm". Thank you.
(In reply to Masayuki Nakano [:masayuki] from comment #4)
> And do you reproduce it in every input field? I.e., do you reproduce it in
> web contents like this page? If it's not so, it might be a bug of add-ons,
> could you check if it's reproducible with clean profile?

And I reproduce bug.2 in every input field and also this page.
Thank you for your information and sorry for the delay to reply.

I tested this with Firefox 50.1.0 and Nightly on Sierra 10.12.2 but I cannot reproduce the symptom with 2-set, 3-set nor 3-set 390.

So, I want to see what we receive native IME events on your environment. Could you attach a log file of it? You can log it with following steps:

1. Quit from Firefox
2. Launch Terminal
3. Paste following command (ignore "> " of the head) to the Terminal and press Enter/Return:
> MOZ_LOG=TextInputHandlerWidgets:5,sync MOZ_LOG_FILE=~/fx.log /Applications/Firefox.app/Contents/MacOS/firefox
4. Set focus to the search bar by mouse or trackpad
5. Type "테스트" with Korean 3-set 390.
6. Quit Firefox from menu (please do not use Cmd+Q)
7. Attach "fx.log" from "Add an attachment" link of this page (see above)

Note that the log file contains all text which you input during launching firefox. So, please do not type any text of your privacy like passwords.
(In reply to deadpanj from comment #9)
> Created attachment 8826507 [details]
> Typed "'테스트" at 3set 390 Korean. The result is "테ㅡㅡ".

Attached. If you need anything more, let me know. Thank you.
Attachment #8826507 - Attachment mime type: text/x-log → text/plain
Okay, the big difference between my environment and deadpanj's environment is, whether Korean IME (or Cocoa?) uses marked text (my environment) or not (deadpanj's environment).

The latter case is, we actually changed the behavior for emulating Chromium's behavior. Then, we changed using composition events to keypress event to insert committed string. Then, there is a different behavior than our old behavior. That is, InsertText() doesn't adjust selected range at inserting committed text with a keypress event. I'm thinking that this difference is the cause.

However, keypress events *may* be consumed by web contents.  Therefore, we need to *forget* selection cache in IMEInputHandler but we don't have any way to do that for now.
deadpanj:

Could you check whether disabling multiprocess mode *hides* this bug on your environment? I guess, it's so.

You can disable multiprocess mode from General pain of Preferences.
(In reply to Masayuki Nakano [:masayuki] from comment #12)
> deadpanj:
> 
> Could you check whether disabling multiprocess mode *hides* this bug on your
> environment? I guess, it's so.
> 
> You can disable multiprocess mode from General pain of Preferences.

Oops, sorry, please ignore this comment. I'm wrong because you reproduced this bug in search bar which is in the main process.
(In reply to Masayuki Nakano [:masayuki] from comment #15)
> deadpanj:
> 
> Could you check if this test build fixes the bug?
> https://archive.mozilla.org/pub/firefox/try-builds/masayuki@d-toybox.com-
> 06727bc0f8c3d14f59f486951bf77744822af1a3/try-macosx64/firefox-53.0a1.en-US.
> mac.dmg

Hi, the attached version cannot work. It said that '“Nightly.app” is damaged and can’t be opened. You should move it to the Trash.' 

I downloaded Nightly at mozilla.org. At the recent version, I can type "테스트" instead of "테ㅡㅡ"(both of 3-set 390 and 2-set), but the cursor is still stuck at the last letter "트" so after another typing which is not Korean(for example spacebar, right arrow, enter) the typing ends.
Ah, Sierra doesn't allow to run downloaded application in default settings, see this document for allowing to run the test build:
http://osxdaily.com/2016/09/27/allow-apps-from-anywhere-macos-gatekeeper/
Flags: needinfo?(deadpanj)
(In reply to Masayuki Nakano [:masayuki] from comment #17)
> Ah, Sierra doesn't allow to run downloaded application in default settings,
> see this document for allowing to run the test build:
> http://osxdaily.com/2016/09/27/allow-apps-from-anywhere-macos-gatekeeper/

I checked your version, but it works as same as the recent version of Nightly. No "테ㅡㅡ", but the cursor is stuck. I'm sorry to say that.
Thank you. I'll look for other cause from the log.
Priority: -- → P3
Whiteboard: tpi:+
Sorry for the delay due to working on a lot of crash bugs and a security bug.

I'm still investigating this issue from the log, though,

> [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 TextInputHandler::HandleKeyDownEvent, calling interpretKeyEvents
> [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::SelectedRange, Destroyed()=FALSE, mSelectedRange={ location=1, length=0 }
> [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::SelectedRange, Destroyed()=FALSE, mSelectedRange={ location=1, length=0 }
> [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::GetAttributedSubstringFromRange, aRange={ location=0, length=1 }, aActualRange=7fff542771c8, Destroyed()=FALSE
> [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::GetAttributedSubstringFromRange, textContent={ mSucceeded=TRUE, mReply={ mString="테", mOffset=140733193388032 } }
> [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::GetAttributedSubstringFromRange, aRange={ location=0, length=1 }, aActualRange=7fff54275e58, Destroyed()=FALSE
> [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::GetAttributedSubstringFromRange, textContent={ mSucceeded=TRUE, mReply={ mString="테", mOffset=140733193388032 } }
> [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::GetAttributedSubstringFromRange, aRange={ location=0, length=1 }, aActualRange=7fff54274c78, Destroyed()=FALSE
> [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::GetAttributedSubstringFromRange, textContent={ mSucceeded=TRUE, mReply={ mString="테", mOffset=140733193388032 } }

Looks like that we return odd range to GetAttributedSubstringFromRange() when you type 2nd character. I don't find the reason why this offset is broken yet.
(In reply to Masayuki Nakano [:masayuki] from comment #20)
> Sorry for the delay due to working on a lot of crash bugs and a security bug.
> 
> I'm still investigating this issue from the log, though,
> 
> > [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 TextInputHandler::HandleKeyDownEvent, calling interpretKeyEvents
> > [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::SelectedRange, Destroyed()=FALSE, mSelectedRange={ location=1, length=0 }
> > [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::SelectedRange, Destroyed()=FALSE, mSelectedRange={ location=1, length=0 }
> > [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::GetAttributedSubstringFromRange, aRange={ location=0, length=1 }, aActualRange=7fff542771c8, Destroyed()=FALSE
> > [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::GetAttributedSubstringFromRange, textContent={ mSucceeded=TRUE, mReply={ mString="테", mOffset=140733193388032 } }
> > [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::GetAttributedSubstringFromRange, aRange={ location=0, length=1 }, aActualRange=7fff54275e58, Destroyed()=FALSE
> > [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::GetAttributedSubstringFromRange, textContent={ mSucceeded=TRUE, mReply={ mString="테", mOffset=140733193388032 } }
> > [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::GetAttributedSubstringFromRange, aRange={ location=0, length=1 }, aActualRange=7fff54274c78, Destroyed()=FALSE
> > [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::GetAttributedSubstringFromRange, textContent={ mSucceeded=TRUE, mReply={ mString="테", mOffset=140733193388032 } }
> 
> Looks like that we return odd range to GetAttributedSubstringFromRange()
> when you type 2nd character. I don't find the reason why this offset is
> broken yet.

It's okay. Thank you for your work.
(In reply to Masayuki Nakano [:masayuki] from comment #20)
> > [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 TextInputHandler::HandleKeyDownEvent, calling interpretKeyEvents
> > [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::SelectedRange, Destroyed()=FALSE, mSelectedRange={ location=1, length=0 }
> > [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::SelectedRange, Destroyed()=FALSE, mSelectedRange={ location=1, length=0 }
> > [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::GetAttributedSubstringFromRange, aRange={ location=0, length=1 }, aActualRange=7fff542771c8, Destroyed()=FALSE
> > [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::GetAttributedSubstringFromRange, textContent={ mSucceeded=TRUE, mReply={ mString="테", mOffset=140733193388032 } }
> > [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::GetAttributedSubstringFromRange, aRange={ location=0, length=1 }, aActualRange=7fff54275e58, Destroyed()=FALSE
> > [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::GetAttributedSubstringFromRange, textContent={ mSucceeded=TRUE, mReply={ mString="테", mOffset=140733193388032 } }
> > [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::GetAttributedSubstringFromRange, aRange={ location=0, length=1 }, aActualRange=7fff54274c78, Destroyed()=FALSE
> > [Main Thread]: I/TextInputHandlerWidgets 7fdd47d777e0 IMEInputHandler::GetAttributedSubstringFromRange, textContent={ mSucceeded=TRUE, mReply={ mString="테", mOffset=140733193388032 } }
> 
> Looks like that we return odd range to GetAttributedSubstringFromRange()
> when you type 2nd character. I don't find the reason why this offset is
> broken yet.

Hmm, 140733193388032 is 0x0FFF00000000, so, it's over uint32_t. I don't understand why this prints so because its specifier is %u (32bit on macOS)
https://dxr.mozilla.org/mozilla-central/rev/1cc159c7a0445ec51e335c8a1a1cceea7bbf8380/widget/cocoa/TextInputHandler.mm#3339
and the type of offset of reply of the query event is uint32_t...
https://dxr.mozilla.org/mozilla-central/rev/1cc159c7a0445ec51e335c8a1a1cceea7bbf8380/widget/TextEvents.h#778
> 140733193388032 is 0x0FFF00000000

Oops, 0x7FFF00000000
(In reply to Masayuki Nakano [:masayuki] from comment #27)
> I created test builds with 2 approaches. Could you test them on your
> environment?
> 
> Approach 1:
> https://archive.mozilla.org/pub/firefox/try-builds/masayuki@d-toybox.com-
> 9d66cd893e8314718103346e5581dbb25c97dac9/try-macosx64/firefox-54.0a1.en-US.
> mac.dmg
> 
> Approach 2:
> https://archive.mozilla.org/pub/firefox/try-builds/masayuki@d-toybox.com-
> d12c169e3be95a0e8633240c75466858a0824a36/try-macosx64/firefox-54.0a1.en-US.
> mac.dmg
> 
> Approach 1+2:
> https://archive.mozilla.org/pub/firefox/try-builds/masayuki@d-toybox.com-
> f0165eea40406ed2b24825f4e6f17b100e153b9d/try-macosx64/firefox-54.0a1.en-US.
> mac.dmg
> 
> Please be careful and ensure that you quit from previous Nightly instance
> before launching new one. I hope that #2 fixes the bug. If so, we can uplift
> the patch safely.

All of them can type Korean well but still the cursor is stuck. I think it gets better of Korean typing than the previous version, but I don't know what is wrong with the cursor after typing Korean. I guess when I type Korean(ie. "테스트") Firefox assumes that typing is in progress before I type something is not Korean(ie. spacebar, enter, right arrow, numbers, English). 

Compared to Chrome, when I type Korean in Chrome's search bar, it searches something right after I stopped typing and the cursor is at the last words like this screenshot. https://www.dropbox.com/s/y1do4km6hn6pq3p/Chrome%20right%20after%20typed.png?dl=0 
In Firefox, it waits and searches something after I type which is not Korean. 
Here's 1. search bar right after typed https://www.dropbox.com/s/v6xvodtc2cy3tob/Nightly%20right%20after%20typed.png?dl=0 
and 2. search bar after hit right arrow. https://www.dropbox.com/s/elqd3ap1rrmznos/Nightly%20hit%20right%20arrow%20after%20typed.png?dl=0 

Thank you for your support.
(In reply to deadpanj from comment #28)
> (In reply to Masayuki Nakano [:masayuki] from comment #27)
> > I created test builds with 2 approaches. Could you test them on your
> > environment?
> > 
> > Approach 1:
> > https://archive.mozilla.org/pub/firefox/try-builds/masayuki@d-toybox.com-
> > 9d66cd893e8314718103346e5581dbb25c97dac9/try-macosx64/firefox-54.0a1.en-US.
> > mac.dmg
> > 
> > Approach 2:
> > https://archive.mozilla.org/pub/firefox/try-builds/masayuki@d-toybox.com-
> > d12c169e3be95a0e8633240c75466858a0824a36/try-macosx64/firefox-54.0a1.en-US.
> > mac.dmg
> > 
> > Approach 1+2:
> > https://archive.mozilla.org/pub/firefox/try-builds/masayuki@d-toybox.com-
> > f0165eea40406ed2b24825f4e6f17b100e153b9d/try-macosx64/firefox-54.0a1.en-US.
> > mac.dmg
> > 
> > Please be careful and ensure that you quit from previous Nightly instance
> > before launching new one. I hope that #2 fixes the bug. If so, we can uplift
> > the patch safely.
> 
> All of them can type Korean well but still the cursor is stuck.

Wow, really? I'm surprised at that because those two approaches are fixing different bugs...

> I think it
> gets better of Korean typing than the previous version, but I don't know
> what is wrong with the cursor after typing Korean. I guess when I type
> Korean(ie. "테스트") Firefox assumes that typing is in progress before I type
> something is not Korean(ie. spacebar, enter, right arrow, numbers, English). 
> 
> Compared to Chrome, when I type Korean in Chrome's search bar, it searches
> something right after I stopped typing and the cursor is at the last words
> like this screenshot. 
> https://www.dropbox.com/s/y1do4km6hn6pq3p/Chrome%20right%20after%20typed.
> png?dl=0 
> In Firefox, it waits and searches something after I type which is not
> Korean. 
> Here's 1. search bar right after typed
> https://www.dropbox.com/s/v6xvodtc2cy3tob/Nightly%20right%20after%20typed.
> png?dl=0 
> and 2. search bar after hit right arrow.
> https://www.dropbox.com/s/elqd3ap1rrmznos/
> Nightly%20hit%20right%20arrow%20after%20typed.png?dl=0 

Sounds odd. Basically, when there is underlined text (called "marked text" in Cocoa, "composition string" in general IME terms), we do not open suggest window because it may conflict with some IME specific window and it makes some IME users inconvenience. See this screenshot: attachment 173449 [details].

However, according to your log, Korean IME doesn't use marked text while when you type Hangul characters. So, do you see marked text for now? If so, something in your environment has changed and it makes your Korean IME start to work same as in my environment.  If so, your test result might be wrong. Actually, I see underline under the last Hangul character in https://www.dropbox.com/s/v6xvodtc2cy3tob/Nightly%20right%20after%20typed.png?dl=0 

Do you still reproduce this bug on released Firefox or normal Nightly build? If not, how about after restarting your macOS? (I still don't understand why your environment works so differently compared with mine.) If you see underline only on above patched builds or after testing with the patched builds, I'm fine to land the patches to next (or later) our release build, though.  Otherwise, I'm not sure if we should land  them and uplift for quicker release because there is no victims anymore...
Hi, I can see marked text everytime I type something in Firefox(51.0.1), FirefoxNightly(54.0a1), and your build of Nightly. 
The screenshot of Chrome and 1st one of Firefox also have marked text, and 2nd one has no marked text because I type the right arrow so Firefox change IME which is not Korean, I think(or as far as I know).

I'm not sure the previous version of Firefox have marked text or not, but now it has. And now typing Korean is very well, no "테ㅡㅡ".

And I understand not opening suggest window while marked text is under the last Hangul character is not a bug, as you said. I'm used to Safari and Chrome and their Korean IME work differently from Firefox so I thought it is a bug. I think the last patches fix the bug, if I understand correctly. Thank you.
(In reply to deadpanj from comment #31)
> Hi, I can see marked text everytime I type something in Firefox(51.0.1),
> FirefoxNightly(54.0a1), and your build of Nightly. 
> The screenshot of Chrome and 1st one of Firefox also have marked text, and
> 2nd one has no marked text because I type the right arrow so Firefox change
> IME which is not Korean, I think(or as far as I know).

Oh, okay. But the log you attached told me that IME on your environment doesn't use marked text, oddly.

> I'm not sure the previous version of Firefox have marked text or not, but
> now it has. And now typing Korean is very well, no "테ㅡㅡ".

Do you mean that you can type Korean even in current release build?

> And I understand not opening suggest window while marked text is under the
> last Hangul character is not a bug, as you said. I'm used to Safari and
> Chrome and their Korean IME work differently from Firefox so I thought it is
> a bug. I think the last patches fix the bug, if I understand correctly.

No problem. If we can assume that any Korean IME never shows any window, we can allow to show suggest window when user uses Korean IME. But I don't know it's safe to assume so.
Flags: needinfo?(deadpanj)
(In reply to Masayuki Nakano [:masayuki] from comment #32)
> (In reply to deadpanj from comment #31)
> > Hi, I can see marked text everytime I type something in Firefox(51.0.1),
> > FirefoxNightly(54.0a1), and your build of Nightly. 
> > The screenshot of Chrome and 1st one of Firefox also have marked text, and
> > 2nd one has no marked text because I type the right arrow so Firefox change
> > IME which is not Korean, I think(or as far as I know).
> 
> Oh, okay. But the log you attached told me that IME on your environment
> doesn't use marked text, oddly.
> 
> > I'm not sure the previous version of Firefox have marked text or not, but
> > now it has. And now typing Korean is very well, no "테ㅡㅡ".
> 
> Do you mean that you can type Korean even in current release build?
> 
> > And I understand not opening suggest window while marked text is under the
> > last Hangul character is not a bug, as you said. I'm used to Safari and
> > Chrome and their Korean IME work differently from Firefox so I thought it is
> > a bug. I think the last patches fix the bug, if I understand correctly.
> 
> No problem. If we can assume that any Korean IME never shows any window, we
> can allow to show suggest window when user uses Korean IME. But I don't know
> it's safe to assume so.

Yes. If the 2nd result at my first post isn't a bug, the bug(1st result) is fixed at 1.17 version(53.0a1).(and I think something in Korean IME is better at the last version, but I can't figure out what exactly it is.) Now I'm typing in Firefox current release build and Hangul typing is good. But I'm not sure when it was fixed and whether it is affected by installing current build of Nightly or your build of Nightly or not. If you need to, I could delete all Firefox builds and reinstall and test, but I assume the result may the same.
Thanks. Although, I have no idea what happened in IME or IME module of macOS, I know it's not so stable. When I work on bug 1312649, I could reproduce the bug only when immediately after rebooting macOS. However, if I use Chrome or something which makes Vietnamese IME use marked text, I became not to be able to reproduce it on Firefox anymore. And the bug depended on which version of SDK is used to build. Therefore, I tried to contact Apple, but I couldn't get enough information from them.

Anyway, according to your current state, I mark this as WORKSFORME because nobody cannot reproduce this bug now. You don't need to uninstall the apps unless you don't need.

However, I found two bugs which can fix easy. I'll file bugs for them and fix them soon.

Thank you for your report and feedback!
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: