Currently, both the mozilla and PPEmbed does not support "Reconversion" in the japaense IME. Reproduce procdure 1. open File:New:Blank page to edit 2. switch to Japanese input method 3. type "nihongo" , hit space- now the IME will underline the peredit text and in conversion mode. 4. hit return to commit the text 5. select the commited text 6. hit control + 1 (or select the last item in the pencel menu "Reconversion ^1") expect result: the ime will go back to conversion mode like step 3 and keep hitting space can let the user reconvert, candidte widnow may popup actual result: nothing happen. The reason that we don't reconvert is we have not implement the kGetSelectedText AppleEvent . This Apple event is documented in develop issue 29 http://developer.apple.com/dev/techsupport/develop/issue29/griffith.html Table 1. Definition of the Get Text event Event class kTextServiceClass Event ID kGetText (= 'gtxt') Requested action Returns the current selection as the return parameter (Keyword / Descriptor type : Data) Required parameters : keyDocumentRefcon / typeLongInteger : Standard refCon parameter keyAEServerInstance / typeComponentInstance : Standard component instance parameter Optional parameters: keyAEBufferSize (= 'buff') / typeLongInteger : Maximum number of bytes the input method can receive Return parameters: keyAETheData / typeText : The text specified by the current selection. The maximum byte length is specified by the keyAEBufferSize parameter. Any portion of the text that exceeds the buffer length shouldn't be returned. according to http://developer.apple.com/techpubs/macos8/pdf/SupportingUnicodeInput.pdf (page 21) The Get Selected Text Event Your applicatoin's Apple event handler for the kGetSelectedTextApple Event must return the current text selection as Unicode text. ... Supporting this event is optional, but recommended.
look at how window implement reconversion at /widget/src/windows/nsWindow.cpp, line 5828 - send a NS_RECONVERSION_QUERY message : 5823 nsReconversionEvent event; 5824 nsPoint point; 5825 5826 point.x = 0; 5827 point.y = 0; 5828 InitEvent(event, NS_RECONVERSION_QUERY, &point); 5829 event.theReply.mReconversionString = NULL; 5830 DispatchWindowEvent(&event); 5831 5832 mIMEReconvertUnicode = event.theReply.mReconversionString; 5833 NS_RELEASE(event.widget);
Created attachment 80503 [details] [diff] [review] patch v1.0
Attachment #79408 - Attachment is obsolete: true
yokoyama, can you r= this one. Low priority for now. Not for nsbeta1
Status: NEW → ASSIGNED
OS: Mac System 9.x → MacOS X
Priority: -- → P3
Target Milestone: --- → mozilla1.1alpha
kathy brade: can you review this for me.
Target Milestone: mozilla1.1alpha → mozilla1.2alpha
Comment on attachment 80503 [details] [diff] [review] patch v1.0 r=brade note for this block (@@ -2442,5 +2469,5 @@) in nsMacEventHandler.cpp there appears to be a tab or spaces added after the "}" which should be removed
Attachment #80503 - Flags: review+
Comments: + returnSize = outString.Length()*2; outString.Length() * sizeof(PRUnichar) would be more meaningful. + if((maxReturnSize >0) && (returnSize > maxReturnSize)) Fix spacing to be consistent with the rest of the file (space after 'if'). + returnSize = maxReturnSize & ~1L; Add a comment saying what this does, so I don't have to think about it. // Round down would be fine. + err = AEPutParamPtr(reply, keyAETheData, typeUnicodeText, outString.get(), outString.Length()*sizeof(PRUnichar)); Don't you want to use 'returnSize' here, not outString.Length()*sizeof(PRUnichar)?
Perhaps I'm wrong but if sizeof(PRUnichar) == 2, doesn't this mean that it holds one UCS-2 or UTF-16 codepoint? Since surrogate charcters can require two codepoints, won't this calculation fail in the case of the string containing characters which map to the surrogate area? Or is this known to be impossible?
>Perhaps I'm wrong but if sizeof(PRUnichar) == 2, doesn't this mean that it >holds one UCS-2 or UTF-16 codepoint? >Since surrogate charcters can require two codepoints, won't this calculation >fail in the case of the string containing characters which map to the surrogate >area? Or is this known to be impossible? no, this is a correct cacluation about the size.
Comment on attachment 94106 [details] [diff] [review] v1.1 address sfraser's comment carry last r=
Attachment #94106 - Flags: review+
Comment on attachment 94106 [details] [diff] [review] v1.1 address sfraser's comment sr=sfraser
Attachment #94106 - Flags: superreview+
fixed and check in .
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Verified fixed with trunk 2002-08-15-08.
Status: RESOLVED → VERIFIED
batch: adding topembed per Gecko2 document http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
The reconversion with "Control+1" is not resolved, at least not completed resolved: 11-11 trunk build / Mac 10.2.1: When I highlighted a commited kannji character "Japan"(nihonn), then select the "reconversion" under Japanese IME pencel menu, I'll get hiragana "nihonn" which I think it's correct brhavior. However, when I use "Control+1" to do the same thing, I don't get the "nihonn" hiragana but a wrong kanji character with un-commit mode (red underline), and if I press space to bring the candidate window, it will bring up a wrong candidate window. 11-11 trunk build / Mac 10.1.5: Similar result as in 10.2.1, but instead of give me a wrong un-commint kanji character, it will show the original kanji (not hiragana) character, the candidate window only can see that kanji character by pressing space key. Re-open this bug for this "Control+1" doesn't work properly, although the reconversion by select under IME pancel menu works fine. Change QA contact to myself.
Status: VERIFIED → REOPENED
QA Contact: ruixu → ylong
Resolution: FIXED → ---
There are some differences between MacOS 10.1 and MacOS 10.2 for "Reconversion" in Japanese IME pencel menu and short-cut keys, e.g. the correct short-cut for JA "Reconversion" on MacOS 10.2 should be "Control + 2", but not "Control + 1" on MacOS 10.1. "Control + 1" on MacOS 10.2 is assigned to a different function other than "Reconversion". It might be better to have a system app (e.g. TextEdit) as a reference of the correct behavior. Kepping as Fixed.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → FIXED
Thanks. Mark as verified based on the same behave as in TextEditor.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.