Do Not Type "File:///" in OS X | Hacker News Reader

" in OS X

openradar.appspot.com

469 points67726e187 comments

Hilariously, this bug seems to also crash the Mac error reporter, maybe because it has the evil string in it. I did manage to copy and paste a crash dump before the crash reporter crashed: http://pastebin.com/UkhERvaA

The underlying reported error is * Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'condition "wrong extraction: File:///"'

Interesting that it's an asynchronous crash. What part of MacOS is paying such close attention to typed URLs?

From the openradar bug, it is obvious that the bug is inside the "Data Detectors" thing. Looks like it triggers on anything starting with file:// (+/) case-insensitive, but then something later in the data extraction makes the incorrect assumption that the string should start with file:// (+/) lowercase, and throws an assert.

It's really quite bad that a bug inside the data detectors can bring down a whole app.

Edit: some interesting links:

http://support.apple.com/kb/PH4519 ("This feature is called “data detectors.”")

https://developer.apple.com/library/mac/#documentation/Found...

checkDataDetectors will extract 'File://a/' - or any other 'complete' file URL - which at a minimum is a schema (file://) and a path '/' - as a valid data URL and then pass it to DDResultCopyExtractURL, which does some additional sanity checking.

There it validates it by asserting that the URL begins with 'file://', which it doesn't. It then converts to an NSInternalInconsistencyException which is what crashes the application, since it isn't caught.

The timing differences that people are seeing is because the NSSpellCheckerCheckString process checks the spelling only after your key entry has been idle for a short period.

checkDataDetectors will also run if you simply open a file or application with this text inside it in a text control. When declaring your text control class you can disable the automated spell checking and data extraction (which will run even if you have spell checking disabled).

There really is no need for this thread to be filling up with 'it works on x, doesn't work on y', since we know what causes this (any NSTextField on Mountain Lion).

If you want to have a look at it and can't read the crash report, attach to TextEdit with gdb

    $ gdb /Applications/TextEdit.app/Contents/MacOS/TextEdit
    (gdb) r
    <switch to textmate and type 'file://a/aaaaa' into a new doc'>
    (gdb) <crash report>
    (gdb) disass DDResultCopyExtractedURL
    <dump of function>

Also, this means the bug can't be exploited

What do you mean "exploited"? It certainly can be exploited to cause a denial of service (like the one at this page: http://gironda.org/this_will_crash_safari.html).

'exploit' is the term for getting a bug to run your own shellcode

Can you clarify what about that output shows that the crash cannot be exploited? Not doubting, just curious.

Unhandled exceptions can't be exploited in general, because they safely unwind the stack and terminate the application. This crash is just an unhandled exception. By contrast, a segfault (at an address other than NULL) would be more interesting from a security perspective.

thank you sir!

The data detectors, at least in my TextEdit were turned off (never touched it before) so typing the aforementioned string doesn't cause any issues.

However in my stupidity of attempting to tell you guys that I could type the aforementioned string, I caused Safari to hang. No crash, but it was complete and utterly useless.

Nevermind ... re-ran TextEdit and tried again, immediately crashes. data detectors are still turned off.

Perhaps that preference only suppresses the display, but the data detectors still run.

Another link, with disassembly and a patch: https://twitter.com/landonfuller/status/297592929923502080

If you're stuck because you typed this and now your app is automatically crashing itself all the time, go to System Preferences, under Language & Text, Text, uncheck "Correct spelling automatically" _and_ "Use symbol and text substitution". Both need to be unchecked.

You can use TextExpander to work around it temporarily. Just map {The bad string that starts with 'F' that I cannot type here} to file:/// and it seems to add some protection.

Everything crashing:

  - Skype (type and right mouse click)
  - Sparrow (type and wait)
  - Chrome (address bar)
  - Safari (address bar)
  - Tweetbot
  - Twitter.app 
  - Mac App Store (search bar)
  - Base (any textbox)
  - terminal (in the preferences screen)

Not crashing:

  - SublimeText

Pretty much each and every text box on the entire system.

That's because SublimeText doesn't use NSTextFields, and therefore, doesn't use Data Detectors. It's not voodoo.

Seriously, people, learn how to read a backtrace. This is hacker news, not social-media-manager-who-claims-they-are-a-geek news.

Great. Now, can you say who ever said that it was voodoo ?

I only see someone who said that it was safe to type it in a software, but I can be wrong.

> can you say who ever said that it was voodoo

Listing every single app under the sun when it's completely obvious a common and widely used component (doesn't matter what's its name so really no need to know Cocoa and that it's probably NSTextView) is used is acknowledging it as voodoo.

No. It's being curious as to what you might be able to do with it. In my case, bricking Messages.app until they send themselves lots of messages.

Voodoo is in your mind, perhaps, but not those who found it interesting which apps use NSTextView and which don't.

Right now, Sublime seems to be the only one. Anyone care to try TextMate?

The likelihood of python/ruby/PHP/etc. programmer being able to interpret a native code stack trace is... what? Probably quite low. They might not even know what the function call names imply. And yet they'd fit perfectly in to this site's readership.

I'm not a social media manager. I'm an engineer. I was making list from casual testing and giggling.

You mean this isn't Slashdot?

Couldn't have said it better.

People act completely stupid when it comes to their OS. HOLY SHIT THERE'S A STANDARD TEXT FIELD CLASS?!?!?! APPLE IS DOOMZ0R3D!! Be a champ and submit these kind of things to your local devs and (as the super "hacker" posters say) carry on...

Oh, please. What is a standard text field class doing with the text inputted into it that would cause an entire app to crash? It's a ridiculous scenario.

Would you have the standard text field run in a separate process sandbox? Or not have standard widgets shared between apps? Or just try real hard to write code without bugs?

Uh, no - this is more of a "don't execute code in a textbox" thing.

Do you understand how the text box gets onto your screen?

Magick?

A great way around this would be for the system to ignore exceptions unless it was caught... wait nevermind

I don't think the poster implied anything else.

Add Messages.app to that list, I discovered as I stupidly tried to explain how to repro it to someone..

The fun thing about having it in messages.app, is it is actually a bug on the RECEIVING end of messages.app. And I can't seem to delete the message before the app crashes again.

I'm so happy I have nice friends.

Disable your spell checker and it will stop crashing. Then you can delete the message, and re-enable the spell checker.

Why would the spell checker be running against in-coming messages? So that you can be a grammar pedant and annoy your friends?

My guess would be that data detectors are used to detect and format links in incoming messages.

Then why would disabling Spellchecking affect that?

This did not fix it for me. Turned off spell checker and text substitution. Have another solution?

This will remove any messages from your iMessage database that contain %File:% (% is a wildcard):

sqlite3 ~/Library/Messages/chat.db "delete from message where text like "%File:%"

I dare not try it, but having that text as status on Facebook could crash those viewing my status using Safaris?

No, you have it in the page just fine. It is only when it is in an NSTextField that it becomes an issue.

This bug is even crashing the crash reporter app as well. It vanishes shortly after appearing when I reproduce the bug in TextEdit.

Typing "File:///" in these also cause a crash:

Spotlight.

Find field in chrome.

Sublime Text will crash if you type File:/// into the help textbox in the help menu.

(This is true of basically every OSX app there is)

That because menu and help search are OS X functions.

Typing it into a text box in Safari causes Safari to hang completely. Had to force quite it.

Add Finder to the list. It dies if you try adding it to one of the color label names.

The cause of this bug seems to be the OSX system spell checker; I've crashed a few applications to take a look at the dumps, and so far they common point of failure seems to be that they all have some call to something like `NSSpellChecker`.

In the OP for example:

    6   AppKit                              0x00007fff921dbd1a checkDataDetectors + 536
    7   AppKit                              0x00007fff921d9429 NSSpellCheckerCheckString + 13334
    8   AppKit                              0x00007fff921d5f9f -[NSTextCheckingOperation main] + 152

    7   AppKit                              0x00007fff921d9429 NSSpellCheckerCheckString + 13334

This explanation makes sense to me because the spell checker is integrated very tightly into the user-facing text entry experience across the board in OSX. It is one of the few bits of code that could explain reliable failures across applications that we've been seeing.

I've disabled the spell checker a long time ago, but it still happens. So NSSpellCheckCheckString is still being invoked even though the spell check is not running.

I think the title needs to be amended to say 'OS X Mountain Lion' because the bug is not reproducible in Lion or Snow Leopard ...

Confirmed that the bug doesn't affect Lion.

Deleted comment

I try to avoid upgrading OSX. When a new version comes out, I wait for a hardware refresh and just get a new Mac (Apple has a nasty habit of disregarding backwards compatibility, and it's really nice to be able to do stuff like run older powerpc programs)

EDIT: the [deleted] comment was 'I miss snow leopard'

Even that strategy isn't enough. I bought a Retina MBP with Lion pre-installed, which was the only configuration they sold, so you'd think it would have been pretty well tested. It turned out that the Lion video drivers couldn't handle the retina display. I had full machine crashes three times a day. Others online had the same problem, and some who were beta testing Mountain Lion said the new video drivers had cured their crashes. As soon as ML was released, I took the free upgrade, and the crashing stopped.

I then upgraded my kids' Snow Leopard Mac to Mountain Lion so I'd only have one Mac OS to admin (along with my Windows, Linux, iOS, and Android machines...sigh). The Mountain Lion upgrade caused all sorts of headaches on the kids' machine.

Moral: The new Mac OS version you buy might not be compatible with your Mac, even if it's the OS that came with it.

I'm not "upgrading" to Lion ever. Their next software update will determine whether or not I buy a Mac again.

> When a new version comes out, I wait for a hardware refresh and just get a new Mac

Apple must love you.

When you have a business, its far easier to just purchase a new machine and expense it than it is to upgrade existing machines. Time is far more value than money, and I'd much rather spend 3K for a new machine than waste a day or a week struggling with an upgrade issue and dealing with AppleCare.

PS: it's eligible for section 179 accelerated depreciation and sales-tax free in NY thanks to ST 121.3

Please note my reply was meant to be taken as a joke. I expect most people don't need to refresh their Apple gear on a yearly basis, but that is a bit of the stereotype of an enthusiastic Apple fan, and your post can be taken humorously to fit that image. Of course with Apple the answer is always more hardware. :-)

> Apple has a nasty habit of disregarding backwards compatibility

On the hardware front, every single major update runs better than the one before here (Mid '09 MBP 13", originally under Leopard). Only issues were the battery on Lion an Mountain Lion on both .0 and .1 minors, which was a bug that affected everyone.

Backwards compatibility refers to newer software/hardware not supporting older software/hardware. For example, Apple axed the rosetta powerpc support (which allowed you to run older software after apple switched to intel CPUs) in Leopard. I still keep a PowerBook G4 just for MacDraw.

Rosetta is optional but supported on Snow Leopard, and gets downloaded automatically on demand. Seven years of transition (assuming SL stopped to be supported when ML was released) to Intel was more than enough for active software to be ported.

You just can't carry legacy code indefinitely, you have to stay focused or you'll be all over the place and suffer death by a thousand cuts.

I intuitively agree as a programmer, but in practise, the focused 10.7/10.8 line has been pretty buggy compared to the legacy-happy 10.6; and the legacy-happy Windows 7 was a smash hit compared to the focused Windows RT. Of course, it might be even worse with Rosetta added to the mix...

I've also given away my Mid-09 MBP because 10.7 Safari was terrible without an SSD ("blank page" bug) :(

>(assuming SL stopped to be supported when ML was released)

Which they backed off from. You can probably thank Flashback for that.

Does not crash:

- 'File:///' typed slowly

- 'File://a' typed slowly

- 'File:// a' typed at any speed.

Does crash:

- 'File:///' typed quickly

- 'File://X' (X being any non-whitespace character) quickly

- 'File://X ' (any number of non-whitespace followed by any whitespace) at any speed

The word is out so it's only a matter of minutes for people to come up with this Safari DOS in Javascript:

https://gist.github.com/4696484

(remember to change to File)

Chrome survives, while Safari either crashes or behaves erratically up to being unusable. Firefox requires slight modifications to the event, but I'm bored.

Binary patch, for entertainment purposes only, do not actually use: http://twitter.com/landonfuller/status/297592929923502080

Landon is a really nice guy, by the way. He is the author of PLCrashReporter library and helped us out making it work with MonoTouch.

There was an x-ray machine called "Therac-25" which had a chance of killing you if the operator typed a specific (non-lethal) configuration too fast.

http://en.wikipedia.org/wiki/Therac-25

That was a disaster. This is a bug.

This is why I never want to work in dev or qa for medical machines. If I were involve in this product's design, the guilt would destroy me.

I wish they'd just fix the bug where typing "~" crashes Terminal.app (depending on your keyboard language) :(

Can you give us the steps to reproduce? I googled around but couldn't find the bug. I also tried a few different languages and I can't get Terminal.app to crash.

Set keyboard to Norwegian. Type Ctrl+"¨" (they key that is the dead-key for ñ, if you were to type Alt+"¨"+n) Crash.

Edit: Here's the same bug in VLC: https://trac.videolan.org/vlc/ticket/7268

Have you tried iTerm?

Maybe I should, but 10.8's Terminal.app seemed to have everything I need (well, except for the crash reporter ruining my work every time I forget and type ~)

I switched to iTerm a long time ago and never looked back. I recommend it.

iTerm 2 is brilliant, I can't imagine using the default Terminal for anything, ever.

Enlighten us. I have read the feature list over the years and don't see anything that really stands out enough.

You know, it's funny. I said the exact same thing you did, then a friend convinced me to try iTerm2 about a year ago. I still couldn't put my finger on what's better about it, exactly, but I've never considered going back after the first day. It just feels right.

It's probably easier to try than it is to find out why to try it...

I say the same thing about why I loathe Chrome and adore Safari. I can't really say why, Safari just feels right.

Panes and saved pane layouts are handy; I generally want to move all my terminals in a group and they're great for that.

It also has great tmux support built into the client.

The only one that keeps me using it is mouse support. Terminal.app doesn't actually send any mouse events.

I've found iTerm2 to be extremely slow on large buffers compared to Terminal.

You mean iTerm or iTerm2 http://www.iterm2.com ?

He without a doubt means iTerm2.

Looks like it is on github now...

https://github.com/gnachman/iTerm2

> I wish they'd just fix the bug where typing "~" crashes Terminal.app (depending on your keyboard language) :(

How did this bug survive the testing process?

Wait. I think I just answered my own question.

It's quite terrible. I even reported it on bugreport.apple.com on 10.8.0, but neither 10.8.1 nor 10.8.2 fixed it.

I can't believe there's no-one at Apple using i18n keyboard layouts and Terminal.app.

It's not like typing "~" is an uncommon event on the command line....

Meanwhile, VLC fixed the same bug (typing ~ in the VLC.app UI textfields) in about 30 minutes.

Doesn't apply to US-International keyboards, I use "~" all the time.

Did you try some other i18n keyboard layouts, like Norwegian or Swedish?

Mine is Swedish, and I am unable to reproduce it.

It crashes with Swedish layout on 10.8.2 when I type Ctrl + ¨ on my computer. (Alt+~+space seems to work, though)

Doesn't crash my Terminal.app. I use a swedish keyboard. Perhaps you could create a new clean account on your computer and try it there? You can always delete the account afterwards.

Interesting. Must be some kind of pref setting or something that's surfacing the bug. Ugh, sounds hard to track down.

Yup, and that's why I suggests you create a new fresh user and try it there. If the bug doesn't show there it's something in your personal settings somewhere, if not it's in the system settings.

Bug number?

problem id 12024039

This also happens in the address bar of Chrome. Great fun.

Wow, and it takes down the entire browser, too, and not just the tab!

And it doesn't just crash one tab of chrome - it crashes the whole application

What version of chrome? Does not happen with 24.0.1312.56 or 24.0.1312.57

Happens with 24.0.1312.57 on osx 10.8.2.

Oh that may be a mountain lion issue. I tried with Snow Leopard 10.6.8 and Lion 10.7.5

I'm also running the latest version of Chrome on Mountain Lion on a current Macbook Air, and I can't reproduce this. Entering file:/// just shows me "Index of /" as expected.

Tried it in Safari and Firefox too, no issues.

The capital F (or indeed, any case version except all-lowercase, such as "fILE") is critical.

Tried that too. It does crash TextEdit, but not Chrome.

OK, it also crashes Safari when capitalized.

Try adding a space after or something, so it doesn't auto-complete to your history of file:// urls?

No crash for me. Google must have patched it.

Geesh, tough crowd. No sense of humor.

(Chrome version 24.0.1312.57 really doesn't crash for me on Mac OS X Mountain Lion. Safari and TextEdit do, though.)

Fun exploit of this - you can use it to lock up Safari hard:

http://grack.com/hangsafari.html

(not a reduced testcase - it's more of a brute force)

You can also trigger a mailto: link that crashes Mail:

mailto:pete@bar.com?subject=File:///&body=File:///

Welp, sadly, Safari on Windows isn't affected.

If you have Xcode you can reproduce the crash in a scratch Xcode project. Drop an NSSearchField into a window, run the app, enter you-know-what, and boom. (I used NSSearchField since that's what I found most easily crashes Finder, VoodooPad, and System Preferences. Maybe NSTextField works as well.)

The assert that fails is this:

assertion on /SourceCache/DataDetectorsCore/DataDetectorsCore-269.1/Sources/PushDown/DDResultExtraction.c:1576 "CFStringHasPrefix(urlVal, CFSTR("file://"))" failed :wrong extraction: File://

There's an extra slash at the end, but I left it out because it crashes Safari.

I sent an iMessage (from iPhone) saying File:/// to my iMac and it crashed iMessage on the other end.. and now messages app crashes every time I try to launch!

Also Sent myself an email (from the iPhone) with File:/// as the subject (and in the body for good measure). The Mail.app won't crash on the incoming email, but it won't open that message.

Send yourself 80 messages and it'll open again, then delete the conversation the File:/// is in.

Worst Easter Egg ever.

I would appreciate if someone can explain to me why I am feeling a urge to visit the office tomorrow only to see stuff crashing on my OSX workstation.

That feeling was me for 10+ years, mainly teenage ones. Not sure where it went, but I prefer working stuff these days.

Quick everyone go to their respective Apple Stores around the world. We will then see how long it will be fixed then ...

Tried it out by sending an email to myself (from webmail) and opening the mail in Mail.app. Mail.app doesn't crash, but if you hit reply to the message and put the cursor on the "File:///" part, it does crash.

Reproduced on Sparrow with success. Whenever you touch the line with File://(/) it will crash.

In one instance the Sparrow crash caused the entire mail library to be corrupt and I have to download all my mails again.

Tried to tweet about this - Twitter client for OSX crashed instantly. Strange that it's not been discovered before!

Also crashes Alfred, Spotify, Calendar and Messages... It would probably be easier to make a list of un-affected apps.

Hilarious. I pranked my friend with this, and now he's pissed. Oh well, it was certainly worth it.

Interesting, though, what exactly causes this bug. It seems as if the built-in spellcheck seems to misinterpret the string "file:///" as some sort of alien construct, or perhaps false typed directories trigger some sort of lockdown. Either way, it's very puzzling how this sort of thing made it past the OS X developers, especially with Apple's level and standard of ultra-high quality control.

Doesn't Apple's quality control only apply to hardware? I hear people complain about bugs and just shear ugliness of their software pretty often.

Up until 10.6, actually, Apple used to produce very good, generally bug-free software. Starting with 10.7, they've begun to rush their software just because they have, say, 4 new "features". The yearly release cycle is partly to blame, but even then, iOS bugs are much more minor.

Several people have said that these apps are crashing at an assert. How did asserts make it into production code? Is it just a C thing to make them debug-only?

Sometimes (especially in dynamic-land) you assert stuff before doing some processing, so that stuff does not blow up halfway but upfront.

"- but, it should never happen?!"

"- so, make it not happen, ever"

My understanding is that asserts are for debugging, and exceptions/more robust error handling are for production.

Asserts make the code blow up, which can make a problem easier to spot in dev/testing. In production it seems better to throw an exception, even if the program can't handle it well and just has to quit nicely.

I like your defensive programming strategy - see if the tires are flat before you get out on the highway.

Maybe because of this: http://stackoverflow.com/questions/2035595/c-xcode-assert-ev...

This is the original discovery, before shess copied it into openradar: http://crbug.com/173405#c17

Original bug report was interesting, just typing "F" in the address bar and getting a reproducible crash that no one else could repro.

"F" probably autocompleted to "File:///" on that person's profile.

This is a bit nostalgic. Back in the day, Opera used to crash if you typed http:/// into the address bar.

(Edit: talking about bugs, HN formatting won't let me put http:/// in double quotes - it eats the closing quote.)

Can someone explain this error to me simply, like one might talk to a golden retriever?

Somewhere in the system is a friendly program called "DataDetectors", which sniffes at text so find out if there are links in it which should be highlighted by the application handling the text.

Now the programmer who developed DataDetectors wanted to make sure (maybe for tests) that a subcomponent was fed only valid file-urls (that is: file:/// is OK, File:/// not) and therefore inserted an assert-statement. Assertions stop the program flow if their condition is not met (an exception is thrown) and normally a code block upstream should handle this case.

I can only speculate, but either the assertion was left in the code despite being only intended for debugging/testing (ie. it was meant to be there only temporarily) or the upstream code has a bug that causes it not to catch the exception.

Either way, it is not handled and therefore bubbles up the whole code chain until some monitor in OS X or Objective C terminates the program because it sees a program error.

Someone at Apple forgot a test case feeding text with File:/// to DataDetectors.

Thank you, iSnow! Makes perfect sense.

"Someone at Apple forgot a test case feeding text with File:/// to DataDetectors."

There's obviously and blatantly a combinatorial explosion of possible inputs into a textbox so it's physically impossible ("physically" as in: "there aren't enough atoms in the universe to build a machine able to handle this) to test all the possible inputs.

By your logic when the terrible endless loop in the Java floating-point parsing library (you could stuck any JVM by trying to parse: 2.2250738585072012e-308) was discovered, it's because:

"Someone forgot to write a test case trying to parse 2.2250738585072012e-308"

Yeah. Sure.

I am not sure why you sound so angry, but let me try to explain: Every time you build in an assertion like that you should have a test case to prove the program handles it like you intended it to.

And concerning the Java FP bug: yes, someone forgot to test the corner cases of the Java FP range.

You don't need to test every FP number out there, but you absolutely need the highest, lowest, highest+1, lowest+1, zero, +/-infinity, division by zero and if you are good highest +0, lowest + 0 and some conversions from and to long, int etc.

Another reason to use Snow Leopard, best operating system until now.

Yes because every day one types "File:///".

This seems like hardly something that outweighs the massive performance improvements.

improvements ?!

Yes, now you too can drain your battery in just half the time as before! ;-)

ETA: Yeah... I can't make this stick. So it kinda-sorta works, but is not a real workaround. Guess I'm glad I kept testing it...

I found a workaround:

defaults write $DOMAIN DisableDataDetectors YES

Credit goes to: http://www.macosxtips.co.uk/index_files/data-detectors-in-ma... The following works for Adium:

defaults write com.adiumX.adiumX DisableDataDetectors YES

ETA: Doesn't seem to persist. Might be sleep/awake or some sort of refresh/timeout. Investigating...

Tested this a bit more. It seems to work on Adium "only some of the time." I am told it works for Colloquy. It does not work for the Google Chrome Browser, TextEdit or Mail.

I think it only affects 10.8. I have tried the suggested methods of this thread in Chrome, TextEdit, iTunes, terminal and Safari but nothing happened in 10.6.8.

For the impatient among us...

A shell script that patches the offending binary and bypasses the issue: http://pastebin.com/pqyePXqa

Copy script contents to a file, then execute (using sudo) This has been tested by others with positive results. It is however a community provided fix.

Original file is backed up before patching.

so, uh anyone else sense a zero day exploit? <a href="File:///<insert code here>">click me</a>... not saying that will work, but usually if you can hard crash something you just found some corruption in memory maybe bad use of memcpy, sprintf instead of snprintf... something along those lines...

Highly unlikely. If you look at the backtrace, it's dying on an assert, not some random memory dereference.

Seems to work in email though: http://news.ycombinator.com/item?id=5154915

A remote DoS isn't remote code execution, but it's still an exploit.

What an interesting bug.

Just tried in Mobile Safari and Noted in iOS 6.1, no problems there.

The iOS Simulator's mobile safari seemed to survive OK on OS X too.

Figured you can crash Safari on page load with this. http://gironda.org/this_will_crash_safari.html

I never felt need to upgrade my snow leopard. This bug is not happening in Snow leopard. I am going to Apple store and try this on one of the display laptop. :)

I put ut a JSFiddle crashing Safari. This is fun. http://jsfiddle.net/EJzhH/3

It's definitely a spell check bug, I've got that feature turned off (always hated it) and none of this is doing anything for me.

How do you turn it off globally? Even removing the AppleSpell.service directory and quitting the accompanying process doesn't seem to work.

Also, are you sure you're both affected and doing it right? It only affects 10.8.x and you have to capitalize the "F".

Seems to crash just about everything except Textmate 1&2 which is strange because they both use the built-in spellchecker

Anyone else wasting a lot of time typing "File:///" into every input in every program...? Just because they were told not to.

Not for me http://cl.ly/image/2i0S3r2b3q0d

OS X version?

Bug report says 10.8.2. I don't see this problem on 10.7.5 as the addendum mentions no problem in Lion.

Spotlight, Finder, Chrome & Activity Monitor all crash; Terminal, Firefox & Sparrow are fine...

I just did. I haven't seen a program crash this abruptly in a while, I'm happy.

in other words, this would wreak a lot of havoc: window.location = "File:///"

None of the browsers will redirect from the web to local, nor will they allow you to load images and whatnot from local either, so doing it that way won't work either.

"Not allowed to load local resource: file:///"

It just crashed an App that I was working on and then crashed XCode itself.

Can't reproduce it in Lion.

Do not send this string in an iMessage, unless, of course, you're evil.

Also, do not send file:/// to anyone using iMessage on their computer.

Now when I try to acces F ...acebook it crashes... calling File://[.]

Crashes:

XCode 4.5.2

TextEdit

iTunes

Preview

I'm typing File:/// in every textbox I could find. This is some weird fun. Way to spend my Saturday morning.

Sounds like an easter egg gone horribly wrong

And here I thought this was a Chrome bug...

Did not crash on LION MAC OS X 10.7.5

iMessage your friends with this string and their Messages app will start crashing. Fun!

Works fine in sublime text 2

File:///

Crashes search in iTunes

Weird - doesn't for me, just asked me if I wanted to search App Store. But kills finder, makes chrome do odd stuff etc.

It crashes finder. WTH?

irc.mactalk.com final solution! room cleared

It's a bug, it happens, let's move on.

Fail:///

Cool!

LINUX

This. IS. AWESOME.

Reply on news.ycombinator.com