Last modified: 2008-05-14 16:15:53 UTC
Searching for Korean words with the new Ajax search box causes problems. Steps to reproduce: # Navigate to new page # Try to type "위" using the "default" Korean input method ("dnl" on a qwerty keyboard) # Observe buggy results Bug behaviour: * "ㅇㅟ" is shown as input, as if user had typed "d<space><backspace>nl" Intended results: * "위" should have been shown Workaround: * Disabling Ajax Affects: * All writing systems which use complex input methods?
I've tried to reproduce this bug using Windows XP sp1 and sp2, firefox 2/3b5, ie6, and using both default IME for Korean (which was preinstalled in my XP), and alternative ones like saenaru, but could not reproduce it. It seems this bug is related either to some specific configuration option of Korean IME, or a bug in some specific Korean IME version.
Also seems fine on Vista with IE 7 and Firefox 2. I can reproduce on Mac OS X 10.5 under Safari (Firefox 3 beta seems ok). On the *first* attempt to type, I get the described behavior; this may be due to the initialization of the drop-down somehow interfering with the input method. Once it's been initialized, if I delete the text and start over it works fine.
No problem in Safari 3.1 on Windows Vista, seems Mac-specific. :) Confirmed it also affects the Japanese IME.
Hmmm... I use a Firefox nightly on Windows and I'm afraid I see the bug. My platform is Windows XP SP2, 2600.xpsp_sp2_qfe.070227-2300 My user agent is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008051206 Minefield/3.0pre ID:2008051206 Some other people have tried to reproduce the bug, and some people running Firefox 3.0 beta 5 on Windows XP were affected while some people weren't. I have tried twiddling with the options in the default IME and the Saenaru IME, but it doesn't affect this bug, AFAICT.
The culprit (tested in Safari) appears to be this in os_eventKeydown(): if(os_first_focus){ // firefox bug, focus&defocus to make autocomplete=off valid targ.blur(); targ.focus(); os_first_focus = false; } if removed, behavior seems normal. I don't see anything obviously wrong under Firefox 3.0b5 or 2.0 current when it's removed. Robert, can you clarify what it's supposed to accomplish, and will it work fine called from say the onfocus handler?
Here is the Firefox bug i was referring to in the comment: 1) remove the above code 2) go to a page where the search box is focused when page is loaded (e.g. Special:Search with empty search string), or focus the search box before the whole page is loaded 3) start typing - you should see both browser autocomplete and mwsuggest What seems to happen is that Firefox ignores the new autocomplete=off property until the field is defocused/focused. Since I haven't find a nice cross-browser way to find out which element is focused on initialization, I've put this code on keydown.
Ok, can repro that base problem in FF 3b5/Mac. Fixed, I think, in r34808. Unfortunately there's no good way to check if a field is focused from JavaScript, so we can't just conditionally do the blur/focus. I've changed how Special:Search does its focus() of the input field; now instead of happening in raw immediate JS, it's done as a body onload handler -- this will run *after* mwsuggest.js does its setup, so by the time the field is forced focused, native autosuggest will be disabled. There might conceivably be a race condition if the user manages to manually focus the field while the page is still loading. Not sure what we can do about that. :D (Note it may be a few hours before this goes live on WP.)
