331700 - autocomplete in urlbar or html forms grabs keyboard input and won't release it

Status: RESOLVED DUPLICATE of bug 317944

(Firefox :: Address Bar, defect)

Description

[Kevin Wilson]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060124 Firefox/1.5.0.1

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.

Comment 1

[Kevin Wilson]

Typo: of course 1.5.1 should be 1.5.0.1

Comment 2

[Philip Withnall (unavailable)]

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)

Comment 3

[Kevin Wilson]

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.

Comment 4

[Kevin Wilson]

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.

Comment 5

[Kevin Wilson]

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.

Comment 6

[Kevin Wilson]

s/INPUT/IM

Comment 7

[Philip Withnall (unavailable)]

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.)

Comment 8

[Kevin Wilson]

(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.

Comment 9

[Philip Withnall (unavailable)]

*** This bug has been marked as a duplicate of 317944 ***