User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/20060124 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20060124 Firefox/126.96.36.199 If I type characters into the urlbar (or any form with saved data) that have a match in the autocomplete history, the autocomplete textbox steals focus and won't let go. It pops up and stays there until I click something. If I continue typing, the autocomplete textbox flashes, but it doesn't disappear and the form in which I'm typing doesn't receive any input. Reproducible: Always Steps to Reproduce: 1.Type something into the urlbar. Say, http://google.com 2.Press enter. 3.Type the same thing into the urlbar (again, http://google.com). 4.Watch in unimaginable horror as the autocomplete box steals your keystokes and devours them alive! Actual Results: My poor keystrokes disappeared to the land of autocompleted agony. -The autocomplete box flashes and no text appears in the input area (urlbar, html forms) although I continue typing -The autocomplete box will not disappear until I click somewhere, either inside the autocomplete box or somewhere else -If I hold down a key, the autocomplete box will disappear after a moment and the input box will accept a keystroke. If that keystroke would make another autocomplete match, however, the problem repeats itself. Expected Results: The keystrokes that I type will make it into the input area. Autocomplete will leave them alone, except to do its job and make matches. I noticed this bug in beta 1. I tried again with beta 2, 1.5.0, and now 1.5.1. The only solution I've found is to disable autocomplete through chrome, but that was enough to make me go back to 1.0.x for a while. I'm running gentoo linux, but the problem is unrelated to gentoo's packages, as I've tried official binaries for all of the versions listed above. 1.0.x does not have this problem.
Typo: of course 1.5.1 should be 188.8.131.52
Version: unspecified → 1.5.0.x Branch
Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8) Gecko/20051111 Firefox/1.5 - Build ID: 2005111116 Works for me. Can you reproduce this when running Firefox in safe mode? (http://kb.mozillazine.org/Safe_Mode)
Yes.(In reply to comment #2) > Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8) Gecko/20051111 Firefox/1.5 - > Build ID: 2005111116 > Works for me. > Can you reproduce this when running Firefox in safe mode? > (http://kb.mozillazine.org/Safe_Mode) > Yes. Running in safe mode doesn't solve the problem.
Each time I test things, I'm doing it from a clean profile (I remove ./mozilla/firefox and allow firefox to create a new one). I decided to test it while playing with my locale settings. The results were strange: #works fine in Japanese rm -rf ~/.mozilla/firefox; LANG="ja_JP.UTF-8" ~/firefox/firefox #breaks when set to English rm -rf ~/.mozilla/firefox; LANG="en_US.UTF-8" ~/firefox/firefox #works in Chinese, too rm -rf ~/.mozilla/firefox; LANG="zn_CH.UTF-8" ~/firefox/firefox I'm beginning to wonder if the problem is related to something in my environment, but I wouldn't know what. Any suggestions? I'm going to lower the severity because it seems to be fairly specific.
Severity: major → normal
I've pinpointed the problem. I'm reluctant to call it a bug in Firefox at this point, but I don't know enough about the subject to dismiss it. The problem only occurs when uim is turned on, and some environment variables weren't being set for some reason when I switched the locale to Japanese. Japanese input, therefore, was broken -- but firefox worked! All of the Western-language locales that I checked had working Japanese input and a broken Firefox. The pattern, then: if Japanese (and presumably, Chinese, or any other language that requires an input manager) input works in Firefox, autocomplete breaks. I tested my theory by hunting down the reason Japanese input wasn't working and fixing it (GTK_INPUT_MODULE variable wasn't set). Firefox broke with Japanese locale and working Japanese input. Perhaps the above will make the problem a bit easier to confirm. I may install scim and test Firefox with it instead of uim to see if the problem persists.
Does this look related to: bug #317944, bug #327116 or bug #261194? (Looks like a dupe of #317944 now that you've found out it's UIM/SCIM.)
(In reply to comment #7) > Does this look related to: bug #317944, bug #327116 or bug #261194? > (Looks like a dupe of #317944 now that you've found out it's UIM/SCIM.) > It does indeed look identical to bug #317944.
*** This bug has been marked as a duplicate of 317944 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.