Bug 199551 - replication of text string from preedit buffer in 2nd text box from 1st
replication of text string from preedit buffer in 2nd text box from 1st
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
: i18n
: 203061 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2006-07-20 07:26 EDT by A S Alam
Modified: 2018-04-11 09:58 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-20 11:47:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 345718 None None None Never

  None (edit)
Description A S Alam 2006-07-20 07:26:29 EDT
Description of problem:
when try to type in Adressbar in Pre-edit enabled Langauge (Japanese), if you
move your
cursor to search bar, then try to type agian, then all the character put in
Adresss-bar are automatically put in Serach bar

Version-Release number of selected component (if applicable):

How reproducible:
Everytime during inputing pre-edit enabled langauge

Steps to Reproduce:
1. start Firefox
2. activate input (SCIM- at task-bar)
3. select Japanese (ja_JP-Anthy)
 4. type 'ak' in one text box (addressbox)
5. try to type 'aka' again in 2nd text box (searchbar)

Actual results:
String from 1st box is replicated to 2nd text box

Expected results:
when goto 2nd box, buffer should be clear, and start from new

Additional info:
No effect of MOZ_DISABLE_PANGO=1, string is till replicated
Comment 1 Warren Togami 2006-07-20 11:25:45 EDT
eng-i18n, please review this as it might be a SCIM bug.  Reassign if this this
actually a firefox problem.
Comment 2 Mayank Jain 2006-07-21 06:19:05 EDT
I dont think this is a scim bug.

Afaik, managing the preedit string is responsibility of the application if it
uses custom widgets. Exactly same problem is with evolution calendar (day view)
which uses custom widgets derived from GnomeCanvas.

Have a look at http://bugzilla.gnome.org/show_bug.cgi?id=264485

Comment 3 Akira TAGOH 2006-07-21 06:56:46 EDT
Yes, apparently this is a firefox bug that is caused by sharing the input
context on some widgets without reset the IC when the focus change happened.

The same problem also happens with kinput2 as well. we can help to get this fix
though, I'm not sure if Jens is the proper person ATM. back to caillon once.
Comment 4 Jens Petersen 2006-08-01 04:38:05 EDT
Dairiki you said you filed a bug for this upstream at mozilla.org?
Comment 5 Ryo Dairiki 2006-08-01 08:32:31 EDT
Yes, I did.

Comment 6 Akira TAGOH 2006-08-18 03:29:17 EDT
*** Bug 203061 has been marked as a duplicate of this bug. ***
Comment 7 A S Alam 2006-08-30 08:36:51 EDT
Problem exist for ko_KR locale also.
Comment 8 Jens Petersen 2007-09-03 23:45:40 EDT
Just retested with current F8 devel firefox and the problem still occurs
with both scim and scim-bridge gtkimm's there.

But seems to be fixed with 3.0a7 upstream binary tarball at least.
Comment 9 Matěj Cepl 2007-12-20 11:47:24 EST
We just updated the Firefox version in Fedora/development from 2.0 to a 3.0
pre-release version, which improves performance, memory usage, and fixes many
bugs and crashes.

Closing as CANTFIX since we aren't fixing bugs filed against 2.0 now that 3.0 is
in.  If this bug is still present in rawhide using a Firefox 3.0 version, please
re-open this bug.

Thanks and Happy Holidays
Comment 10 A S Alam 2008-01-31 23:24:08 EST
it is working fine with following version for ja_JP langauge (FYI only)

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