Closed Bug 81360 Opened 24 years ago Closed 23 years ago

Correct behavior of ResetInputState() for gtk/

Categories

(Core :: Internationalization, defect)

All
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: masaki.katakai, Assigned: masaki.katakai)

References

Details

Attachments

(6 files)

ResetInputState() should do the correct behavior, - Reset (Delete) preedit if exists - commit existing preedit if exists - call NS_COMPOSITION_END to close the composition With the fix of bug 81356, bug 53025 should be solved. gtk/ is working mostly, but when the focus is moved to the other window, (not within the same window), the following codes block incorrectly. Those codes should be obsoleted because they were the workaround for when candidate region gets input focus. if (mIMEShellWindow->mIMEIsBeingActivate == PR_TRUE) { return NS_OK; } Also when XmbResetIC() returns nothing, it should delete existing composition, but it doesn't now.
Blocks: 53025
Status: NEW → ASSIGNED
After I investigated, I found the codes around mIMEIsBeingActivate should be there. Some IME on Linux invokes extra window (called candidates window) and it grabs input focus, but composition string shouldn't be committed. The behavior depends on IME. if (mIMEShellWindow->mIMEIsBeingActivate == PR_TRUE) { return NS_OK; } I'll provide patch onlyk for XmbResetIC() problem. But anyway, it's ready for Editor codes (bug 81356) to check in.
Target Milestone: --- → mozilla0.9.2
When I applied the patch of bug 81356, closing window with composed text causes Mozilla dumps core. This hebavior happens on Linux platform only. No problems for Windows and Mac. 1. Start Mozilla 2. Seach > Find in This Page 3. turn IM on 4. type some characters 5. click cancel button This bug blocks bug 81356.
Blocks: 81356
Target Milestone: mozilla0.9.2 → ---
QA Contact: andreasb → ylong
Attached file stack trace with ATOK X Japanese IME (deleted) —
Attached file stack trace with kinput2 (case1) (deleted) —
Attached file stack trace with kinput2 (case2) (deleted) —
Attached file stack trace with kinput2 (case3) (deleted) —
Attached file stack trace with kinput2 (case4) (deleted) —
With the patch of bug 81356, Mozilla becomes very unstable by the operations of my comments on 2001-06-10 05:20.
In widget/src/gtk/nsGtkIMEHelper.cpp nsGtkIMEHelper::MultiByteToUnicode() if (aUniDes) { delete [] aUniDes; } These "aUniDes"s should be "*aUniDes". Probably this is the cause of memory corruption.
Thank you Tabata-san, Yes, the code must cause memory corruption. I'll fix. I finally found bad codes which caused those crashes in nsIMEGtkIC::ResetIC(), - if (uniCharSize) { - aUnichar[uniCharSize] = 0; - } This is bad and causes the crashes. I'll remove the codes, aUnichar[uniCharSize] = 0 is called in ResetInputState(). I'll attach the patch and I did - Correct bad codes in ResetIC() - Change delete [] mStatusText to nsCRT::free(mStatusText) - Change delete [] aUniDes; to delete [] *aUniDes; - Provide ResetDecoder() when input buffer exceeds 128, we need to reset decoder - When nsIMEGtkIC::ResetIC() returns 0, we should remove composed text Some IMEs does not return XmbResetIC() properly, it always returns NULL. We should handle such case blizzard, could you r=/sr= please?
Attached patch patch (deleted) — Splinter Review
There are two places that you call: + nsCRT::free(mStatusText); Shouldn't you set those both to 0 as well?
Thank you very much for revewing, Yes, mStatusText=0 is called after the freeing at one place, http://lxr.mozilla.org/seamonkey/source/widget/src/gtk/nsGtkIMEHelper.cpp#1073 Also setting new value in other place after the freeing, http://lxr.mozilla.org/seamonkey/source/widget/src/gtk/nsGtkIMEHelper.cpp#1353
Comment on attachment 50677 [details] [diff] [review] patch r/sr=blizzard
Attachment #50677 - Flags: superreview+
patch checked in. Thank you very much for reviewing.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Which build did you checked-in? netscape branch or trunk?
I've checked into trunk. Thanks.
Verified works fine on 10-01 trunk build.
Status: RESOLVED → VERIFIED
This checkin seems to have caused bug 103611.
is this what caused bug 102282 too? URL-bar selection is more or less completely broken on Linux when "Enable Location Bar Autocomplete" is enabled in preferences.
Actually on nightly buld, I could reproduce the problem of bug 103611 but could not reproduce bug 102282. Just clicking on URL bar, popup will be invoked but I'm not seeing the behavior of bug 102282. Is the problem still reproducible on the nightly? I have checked in the patch for bug 103611 into Trunk few minuts ago. Is it possible to check the trunk with the patch if the binary is ready? Thank you.
To see the bug you must set prefs to "Autocomplete best match as you type" under prefs/navigator/smart browsing/advanced CVS build including checkins through 16:46 still had bug 102282. Just pulled and built again, with fix for bug 103611: Bug is gone. For those who wish to test, the bug is currently still present in the latest nightly.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: