64892 2011-07-20 13:51:19 -0700 Find in page with a Korean string fails 2011-08-05 13:06:37 -0700 1 1 1 Unclassified WebKit Text 528+ (Nightly build) Unspecified Unspecified NEW http://ko.wikipedia.org/wiki/%ED%95%9C%EA%B8%80 P2 Normal --- 1 jshin webkit-unassigned ap oldest_to_newest 439993 0 jshin 2011-07-20 13:51:19 -0700 Follow-up to bug 62913 ICU 4.6 has a new collator for Korean search. It's not just in Korean locale but also in root (so regardless of the search locale, this issue will show up). It's supposed to be used for search (as in Find-in-page). So, in bug 62913, ap landed a patch to use a search collator in ICU if available. With that patch in, Find-in-page in Chrome is broken. Reproduction steps: 1. Go to the page in the URL 2. Install a Korean 2-set kbd on Mac 3. Fire up FiP box (command-F) 4. Select Korean 2-set layout 5. Type gksrmf in QWERTY kbd (which corresponds to '한글') Expected: a number of matches Actual (in Chrome) : no match Even though the CLDR change (that was imported to ICU) for Korean search has some issues (it's my fault not to catch it), this breakage should not happen. If this cannot be reproduced with Safari on Mac OS Lion (with ICU 4.6), there might be some Chrome-specific issues. It's reported as a Chrome bug (http://crbug.com/88434 ) 440068 1 jshin 2011-07-20 15:48:58 -0700 Probably, it's a Chrome-only issue. I forgot to apply one of Apple's ICU patches (post-4.6-release) to Chrome's copy of ICU. It's likely that Mac OS Lion does include that patch. Once confirmed, I'll close this bug. 440070 2 ap 2011-07-20 15:49:48 -0700 I get "over 100 matches" in Safari on Lion (with ToT WebKit - the change to use search collator is not in Safari 5.1). Tested with each of primary Korean, Russian, and Korean languages. 440470 3 ap 2011-07-21 10:19:13 -0700 > Korean, Russian, and Korean Korean, Russian, and English. 447379 4 ap 2011-08-05 13:06:37 -0700 Can this bug be closed now?