Hah, you are of course correct. I can never keep the order of OSX cats straight, so I had to look up which one 10.6.x was. But then I typed it out wrong even after doing so!
Edit: I've narrowed it down to the following byte sequence. I can't seem to remove any of the characters without it no longer crashing:
00000000 d9 88 d2 88 cd a5 cd a8 cd aa cd af 20 d2 88 d2 |............ ...|
00000010 88 d2 88 |...|
00000013
Hixie's unicode decoder says this is:
U+0648 ARABIC LETTER WAW character (و)
U+0488 COMBINING CYRILLIC HUNDRED THOUSANDS SIGN character (҈)
U+0365 COMBINING LATIN SMALL LETTER I character (ͥ)
U+0368 COMBINING LATIN SMALL LETTER C character (ͨ)
U+036A COMBINING LATIN SMALL LETTER H character (ͪ)
U+036F COMBINING LATIN SMALL LETTER X character (ͯ)
U+0020 SPACE character
U+0488 COMBINING CYRILLIC HUNDRED THOUSANDS SIGN character (҈)
U+0488 COMBINING CYRILLIC HUNDRED THOUSANDS SIGN character (҈)
U+0488 COMBINING CYRILLIC HUNDRED THOUSANDS SIGN character (҈)
Chrome uses OS X's CoreText for rendering the tab titles, but uses its own text rendering engine for the site body. CoreText is the one that crashes on that unicode.
And apparently Twitter puts the content of a tweet in the <title> tag if you are on the page for a single tweet. Surprised that doesn't cause more problems.
> And apparently Twitter puts the content of a tweet in the <title> tag if you are on the page for a single tweet.
Nope, Twitter uses a shortened, ellipsized version of the tweet as <title> ... </title>. Still, if there's Unicode in the shortened version, it might have the same outcome.
After reducing the html-code in the site, it seems to me that it is not the title that causes the crash, but the p-tag with the specific css-style applied.
Meanwhile on Chromium 26.0.1384.0 (build 176849) on OS X Lion everything is fine for me. The titlebar is (appropriately for the typography) messed up, but there are no tab loading issues, cpu/memory spikes, or screen corruption. The closest thing to an issue I see is that it makes using Witch's window switch dialogue a bit ugly. Contrary to the thread on jwz's journal YoruFukurou 2.77 doesn't crash or misbehave for me viewing that tweet, but behind the scenes fontd uses up a decent chunk of cpu for several seconds. Perhaps Mountain Lion has more severe bugs in CoreText?
Rendering any typeable character(s) should never crash any engine... ever. That said, unicode seems to be the last frontier for the non-viral spread of glitches.
If it's a CoreText bug, which is sounds like it is, it's going to impact any iOS or OS X app that uses Core Text for rendering. That's pretty much everyone.
60 comments
[ 3.4 ms ] story [ 117 ms ] threadIt's a little laggy, but it's rendering okay. Might be an OSX-localised issue.
Though it should be noted that there is no other version that starts with 'S' ...
So I retweeted it.
Can someone explain what is happening and why the tweet is affecting the tab and this post does not?
In the end both just render unicode characters. And it looks like only Firefox is able to display it correctly on OSX 10.8.
Nope, Twitter uses a shortened, ellipsized version of the tweet as <title> ... </title>. Still, if there's Unicode in the shortened version, it might have the same outcome.
Interesting bug.
OS X 10.8.2 (12C60)
Nah, just kidding.
Cool.
.
.
Edit: Apparently it is only the unicode
>ه҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈ͫͬͩͮͨͪͯͥͥͫͪͧͣͯͪͨͣͥͬͪ ҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈ͪͥͨͪͫͬͭͮͯͥͤͣͥͨͪͧͣͯͬͪ ҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈ͪͨͪͫͬͩͮͯͥͨͣͥͫͪͧͣͯͥͬͪ>ه҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈ͫͬͩͮͨͪͯͥͥͫͪͧͣͯͪͨͣͥͬͪ ҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈ͪͥͨͪͫͬͭͮͯͥͤͣͥͨͪͧͣͯͬͪ ҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈ͪͨͪͫͬͩͮͯͥͨͣͥͫͪͧͣͯͥͬͪ>ه҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈ͫͬͩͮͨͪͯͥͥͫͪͧͣͯͪͨͣͥͬͪ ҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈ͪͥͨͪͫͬͭͮͯͥͤͣͥͨͪͧͣͯͬͪ ҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈҈ͪͨͪͫͬͩͮͯͥͨͣͥͫͪͧͣͯͥͬͪ
.
.
.
How is this possible?
http://s20.postimage.org/6athqkm3h/image.jpg
http://en.wikipedia.org/wiki/Script_(Unicode)
Edit: It is slightly different looking on Win7.
I'm somewhat reminded of this : http://stackoverflow.com/a/1732454