Closed jfbastien closed 8 years ago
So I had noooooo idea what the answer was, did some digging, and here's a story of how that went.
As a sanity check, I tested this in JavaScript and "⇒" === "⇏"
returns false
, which is reassuring, if irrelevant (Chrome is written mostly in C++, Objective-C at times, and therein the madness probably lies).
Then I wrote the simplest C++ program, which just did printf("%d\n", strcmp("⇒", "⇏"));
, and that printed 3
(which according to the docs means the two are definitely not equal), so that's still good because that's what we'd expect.
Since I run Chrome on OSX and that find bar native OSX code, I decided to test this in Objective-C because maybe NSStrings are whack (never trust Objective-C). But NSLog([@"⇒" isEqualToString:@"⇏"] ? @"true" : @"false");
printed false
, so that wasn't it either.
Running out of ideas and starting to blame Chrome, I double checked that what you described happens for all "accented" characters (loosely speaking, ⇏
is just ⇒
+ a modifier character; ê
is just e
+ ^
), and it does: in this page, searching for enemies
and êñëmįęš
, leads to the same results. So this must be a thing Chrome is doing!
And, lo and behold, it is: here is the bug tracking that. If you follow along in that thread, it's basically a case-sensitivity problem: E
, e
and è
are all treated the same, and it's not likely to change any time soon -- turning on or off this feature requires some fairly pedantic UI, which the design team is understandably not fond of.
Awesome!
FWIW I'm super happy that ç
and c
are the same, makes it easier to vanity-search for my name.
⇒ and ⇏ are clearly not friends, considering how
Rightwards Double Arrow
is really not cool with the wholeWith Stroke
thing. Imagine my surprise when going to the awesome Wikipedia page on arrows and discovering that using Chrome to search for either⇒
or⇏
turns up both in the search!All the other
With Stroke
arrows from there also search as equivalent. What's up with that? Shouldn'tWith Stroke
make them mortal enemies?