Bug 136247
| Summary: | iiimgcf shouldn't send the key release event by off hand | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Akira TAGOH <tagoh> |
| Component: | iiimf | Assignee: | Akira TAGOH <tagoh> |
| Status: | CLOSED UPSTREAM | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | eng-i18n-bugs, fedora-ja-list, wtogami |
| Target Milestone: | --- | Keywords: | i18n |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-10-12 06:17:27 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 125997 | ||
This is definitely a regression of im-sdk, do we have a tracking on when it firstly appeared? in r1347, which gtkimcontextiiim.c has been imported into svn, always not filtering the key release event code was there. I'm not sure which version of im-sdk you says a regression from, when it appeared doesn't matter, I think. presumably the problem doesn't just appear for us until now, as iiimgcf works on gtk2 applications. When do we started to see "unexpected commit string on OOo"? only recently to me. It is when OOo upstream has updated a "fix" on gtk widget module in OOo - that triggler the attention of this code. Comment #3: it's because OOo has supported gtk's immodule recently :) Is "unexpected commit string on OOo" reproduciable on gedit? Not happening in gedit fortunately because of this reason (by mclasen): "gtktextview probably gets around this by delaying the actual ending of the preedit until it actually has to, e.g. before actually inserting some character in the text buffer" But in any event, until we found out actual reason from the implemenation of the current code, ignoring key release seems may not be a best way to do IMHO. let me try to fix this bug. We strive to work with the upstream community of open source projects. This allows us to reduce the likelihood of regressions between releases as well as to benefit from features and fixes as development moves forward. Since this change would require a divergence from the upstream project, please report this issue to IIIMF developers by filing a bug report in the OpenI18N bugzilla located at http://openi18n.org/bugzilla/ in the "IIIMF" component. We urge you to bring the information upstream, so that it can be incorporated in the next release. Once you've filed your bug report to OpenI18N, if you paste the new bug URL here, we will continue to track the issue in the centralized OpenI18N bug tracker, and will review any bug fixes that become available for consideration in future updates. Thanks. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.7.3) Gecko/20041007 Debian/1.7.3-5 Description of problem: when gtk_im_context_filter_keypress (im_context_iiim_filter_keypress) is called, it always returns FALSE for the key release event. it causes the weird behavior, which the applications will gets the key release event only. So if the key press event is filtered by im_context_iiim_filter_keypress, that pair of key release event should be filtered as well. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.look at iiimgcf with debug mode. 2.press End key say in Japanese. 3. Actual Results: key press event is filtered, but the key release event isn't always filtered. Expected Results: if key press event is filtered, the key release event should be filtered as well. Additional info: this causes the unexpected commit string on OOo