Description of problem: As Firefox runs, its text entries becomes more and more sluggish: after about a day of use they cannot keep up with the keyboard auto-repeat rate even on my Core 2 Quad system, and there is much CPU consumption by firefox and scim-bridge when typing. Restarting Firefox makes it responsive again. The problem still exists in safe mode. Stracing the scim-bridge process, I see a long-running Firefox instance issue an ever increasing number of handle_key_event messages per keypress; a freshly started Firefox may issue 3-4 messages per keypress, but this number gradually increases to hundreds when I visit websites with text areas, at which time text input becomes sluggish. I don't know much about the internals of SCIM, but this looks like a leak of event listeners, text entries or IM contexts to me. Since other applications (e.g. gnome-terminal) do not have the excessive number of handle_key_event messages, I don't think SCIM is the culprit. Version-Release number of selected component (if applicable): firefox-3.5.6-1.fc12.x86_64 scim-bridge-gtk-0.4.16-2.fc12.x86_64 scim-bridge-0.4.16-2.fc12.x86_64 scim-1.4.9-4.fc12.x86_64 imsettings-0.107.4-5.fc12.x86_64 Environment variables: LANG=zh_CN.UTF-8 IMSETTINGS_INTEGRATE_DESKTOP=yes IMSETTINGS_MODULE=SCIM XMODIFIERS=@im=SCIM How reproducible: Always on my system Steps to Reproduce: 1. Set up scim and scim-bridge 2. Start firefox with scim-bridge enabled, preferrably in safe mode and also using imsettings as shown in the environment variables above. 3. Load a web page with text areas 4. Run the following command in the background: strace -tt -p `pgrep scim-bridge` -s 128 -e trace=recvfrom 2>&1 | grep "handle_key" 5. Type in the text area and observe the number of handle_key messages generated per keypress. 6. Now reload the web page, type again, and repeat for a few times. An ever-increasing number of handle_key messages per keypress should be observed. Actual results: An ever-increasing number of handle_key messages are observed, eventually causing text input to become sluggish. Expected results: The number of handle_key messages per keypress should stay at a reasonable level. Additional info:
The web page can be just "<html><head></head><body><form><input></form></html>". Reloading with the reload button is not very effective at reproducing this bug. Pressing enter in the address bar is.
You may want to try ibus which is now the default IME system in fedora.
I found the cause of the bug by running firefox with SCIM_BRIDGE_DEBUG_LEVEL=5. Firefox seems to be trying to call scim_bridge_client_imcontext_focus_in () multiple times on the same IM context, which results in key_snooper being installed multiple times. The bug appears to be resolved if gtk_key_snooper_install() is only called when key_snooper_used is not already TRUE.
Created attachment 386096 [details] Patch to scim-bridge-0.4.16/client-gtk/scim-bridge-client-imcontext-gtk.c
Thank you for the patch - I think it would also be good if you submit it to the scim-devel mailing-list.
Checked code in file gtkimcontextscim.cpp of scim. Similar code is found: 689 // Only use key snooper when use_key_snooper option is enabled and a gtk main loop is running. 690 if (_use_key_snooper && !_snooper_installed && gtk_main_level () > 0) { 691 SCIM_DEBUG_FRONTEND(2) << "Install key snooper.\n"; 692 _snooper_id = gtk_key_snooper_install ((GtkKeySnoopFunc)gtk_scim_key_snooper, NULL); 693 _snooper_installed = true; 694 } Thanks for the fix.
Include the patch scim-bridge-0.4.16-fix-gtk-key-snooper.patch in scim-bridge, will be released with Fedora 13. Close the bug as NextRelease. Thanks for the report and patch.