Last modified: 2008-05-14 16:15:53 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T16082, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 14082 - Ajax search bug with complex IMEs in Safari/Mac
Ajax search bug with complex IMEs in Safari/Mac
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Search (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-11 02:22 UTC by Kyungjoon Lee
Modified: 2008-05-14 16:15 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Kyungjoon Lee 2008-05-11 02:22:07 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?
Comment 1 Robert Stojnic 2008-05-13 16:47:03 UTC
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. 
Comment 2 Brion Vibber 2008-05-13 17:23:11 UTC
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.
Comment 3 Brion Vibber 2008-05-13 22:33:48 UTC
No problem in Safari 3.1 on Windows Vista, seems Mac-specific. :)

Confirmed it also affects the Japanese IME.
Comment 4 Kyungjoon Lee 2008-05-13 23:40:53 UTC
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.
Comment 5 Brion Vibber 2008-05-13 23:47:20 UTC
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?
Comment 6 Robert Stojnic 2008-05-14 08:31:22 UTC
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. 

Comment 7 Brion Vibber 2008-05-14 16:15:53 UTC
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.)

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


Navigation
Links