This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 136247 - iiimgcf shouldn't send the key release event by off hand
iiimgcf shouldn't send the key release event by off hand
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: iiimf (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Akira TAGOH
: i18n
Depends On:
Blocks: IIIMF
  Show dependency treegraph
 
Reported: 2004-10-18 16:46 EDT by Akira TAGOH
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-12 02:17:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Akira TAGOH 2004-10-18 16:46:24 EDT
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
Comment 1 Yu Shao 2004-10-19 00:48:04 EDT
This is definitely a regression of im-sdk, do we have a tracking on
when it firstly appeared?
Comment 2 Akira TAGOH 2004-10-19 01:24:54 EDT
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.
Comment 3 Yu Shao 2004-10-19 01:26:58 EDT
When do we started to see "unexpected commit string on OOo"? only
recently to me.
Comment 4 Leon Ho 2004-10-19 01:59:35 EDT
It is when OOo upstream has updated a "fix" on gtk widget module in
OOo - that triggler the attention of this code.
Comment 5 Akira TAGOH 2004-10-19 02:09:40 EDT
Comment #3:
it's because OOo has supported gtk's immodule recently :)
Comment 6 Yu Shao 2004-10-19 02:16:38 EDT
Is "unexpected commit string on OOo" reproduciable on gedit? 
Comment 7 Leon Ho 2004-10-19 02:56:29 EDT
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.
Comment 8 Akira TAGOH 2004-10-19 03:00:20 EDT
let me try to fix this bug.
Comment 10 Lawrence Lim 2005-10-12 02:17:27 EDT
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. 

Note You need to log in before you can comment on or make changes to this bug.