Closed
Bug 81360
Opened 24 years ago
Closed 23 years ago
Correct behavior of ResetInputState() for gtk/
Categories
(Core :: Internationalization, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: masaki.katakai, Assigned: masaki.katakai)
References
Details
Attachments
(6 files)
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
text/plain
|
Details | |
(deleted),
patch
|
blizzard
:
superreview+
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 1•24 years ago
|
||
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.
Assignee | ||
Updated•24 years ago
|
Target Milestone: --- → mozilla0.9.2
Assignee | ||
Comment 2•24 years ago
|
||
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.
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.2 → ---
Updated•23 years ago
|
QA Contact: andreasb → ylong
Assignee | ||
Comment 3•23 years ago
|
||
Assignee | ||
Comment 4•23 years ago
|
||
Assignee | ||
Comment 5•23 years ago
|
||
Assignee | ||
Comment 6•23 years ago
|
||
Assignee | ||
Comment 7•23 years ago
|
||
Assignee | ||
Comment 8•23 years ago
|
||
With the patch of bug 81356, Mozilla becomes very unstable by the
operations of my comments on 2001-06-10 05:20.
Comment 9•23 years ago
|
||
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.
Assignee | ||
Comment 10•23 years ago
|
||
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?
Assignee | ||
Comment 11•23 years ago
|
||
Comment 12•23 years ago
|
||
There are two places that you call:
+ nsCRT::free(mStatusText);
Shouldn't you set those both to 0 as well?
Assignee | ||
Comment 13•23 years ago
|
||
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 14•23 years ago
|
||
Comment on attachment 50677 [details] [diff] [review]
patch
r/sr=blizzard
Attachment #50677 -
Flags: superreview+
Assignee | ||
Comment 15•23 years ago
|
||
patch checked in. Thank you very much for reviewing.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 16•23 years ago
|
||
Which build did you checked-in? netscape branch or trunk?
Assignee | ||
Comment 17•23 years ago
|
||
I've checked into trunk. Thanks.
Comment 19•23 years ago
|
||
This checkin seems to have caused bug 103611.
Comment 20•23 years ago
|
||
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.
Assignee | ||
Comment 21•23 years ago
|
||
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.
Comment 22•23 years ago
|
||
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.
Description
•