Typing These 8 Characters Will Crash Almost Any App On Your Mountain Lion Mac

An anonymous reader writes "All software has bugs, but this one is a particularly odd one. If you type "File:///" (no quotes) into almost any app on your Mac, it will crash. The discovery was made recently and a bug report was posted to Open Radar. First off, it’s worth noting that the bug only appears to be present in OS X Mountain Lion and is not reproducible in Lion or Snow Leopard. That’s not exactly good news given that this is the latest release of Apple’s operating system, which an increasing number of Mac users are switching to. ... A closer look shows the bug is inside Data Detectors, a feature that lets apps recognize dates, locations, and contact data, making it easy for you to save this information in your address book and calendar."

Comments

printf

[Sigvatr]

C-strings strike again.

Re:printf

[Anonymous Coward]

Not likely. It crashes due to an assertion failure and subsequent exception being thrown.

Re:printf

[Anonymous Coward]

Here speaketh the Apple fan. No matter what... it's a good thing.

Re:printf

[Anonymous Coward]

as a programmer myself, when coding something and a harmless and not completely unexpected input occurs, your program shouldn't crash, due to any reason, asserts included. Such a failure is sign of nothing but lazy programming and even lazier unit testing.

Re:printf

[Anonymous Coward]

When you detect that your program is in an inconsistent state, is it better to continue executing, possibly corrupting data and granting an attacker access to your system, rather than aborting the program and providing a stack trace to help diagnose why things went wrong?

Re:printf

[TheRealMindChild]

Exceptions should be exceptional. A bad string isn't exceptional

Re:printf

[Dahamma]

No, it's better to return an error or thrown an exception rather than assert when the input to a function is perfectly reasonable but not what you expect.

And, in the end, who knows. Maybe it was the caller aborting by not handling the error/exception. In which case it's STILL bad coding by someone, as this is not an exceptional case...

Re:printf

[EvanED]

Yes, input validation is usually a good thing and no amount of you hating Apple Inc is going to change that.

That's true. But a crash is not the way to handle invalid input.

Re:printf

[Savage-Rabbit]

I have also had the impression that assert() is a hack that shouldn't be used much (?).

$ man assert

NAME
          assert -- expression verification macro

SYNOPSIS
          #include

          assert(expression);

DESCRIPTION
          The assert() macro tests the given expression and if it is false, the
          calling process is terminated. A diagnostic message is written to stderr
          and the abort(3) function is called, effectively terminating the program.

          If expression is true, the assert() macro does nothing.

          The assert() macro may be removed at compile time with the cc(1) option
          -DNDEBUG.

Somebody forgot to remove some debugging code, embarrassing but hardly something that hasn't happened before and definitely not the end of the world as we know it.

Re:printf

[fyngyrz]

C-strings strike again.

Nope. Lousy programmers strike again. There's nothing at all wrong with c-strings. There is, however, a sufficiency of lousy programmers who lack the skill to handle perfectly simple data structures. Seriously, if you can't handle a zero terminated string or keep from overrunning an array, it's not the string format that's the problem. It's you.

Assuming the problem here is a string problem may be jumping the gun, too. Could just as easily be something else.

Re:printf

[Anonymous Coward]

I agree with you, you couldn't abort on bad input.

However, based on my interpetation of what is happening, this isn't what is happening. My expecation is as follows:

The user types something in an address bar.

That string is passed to hypothetical function 'process_uri'.

'process_uri' sees that it is a file uri, and passes it to the hypothetical function 'process_file_uri'.

'process_file_url' sees that it wasn't given a file uri, and aborts.

The problem ISN'T that the use gave bad input. If process_uri was given a URI it didn't recognize, it would have generated a proper error and not called anything. If process_file_url was given a path to a file that didn't exist, it too would have generated a proper error. The problem IS that process_uri and process_file_uri have different expectations on what constitutes a proper file uri.

Re:printf

[Anonymous Coward]

Not likely. It crashes due to an assertion failure and subsequent exception being thrown.

Yeah. Data Detectors on Macs is just like Semantic Desktop on KDE. When I make a fresh install of the OS, disabling these pesky little "features" is one of the first things I do. I'm glad somebody somewhere out there finds them useful but I definitely don't.

Re:printf

[Anonymous Coward]

as a programmer myself, when coding something and a harmless and not completely unexpected input occurs, your program shouldn't crash, due to any reason, asserts included. Such a failure is sign of nothing but lazy programming and even lazier unit testing.

Sorry, but you are wrong.

By the time you fail an assertion, you better crash because you're not supposed to be there. The code in FRONT of the assertion is supposed to prevent that.

Assertions go between the input checking front, and the sane input needing rear. Their only purpose in life is to prevent an unknown state in the rear guts, not to do what should have been done up front.

Re:printf

[matunos]

And yet, unchecked input is the root of almost all software vulnerabilities

Re:printf

[AuMatar]

Totally and completely fucking wrong. A well written program should not crash for any reason. It should alert the user and allow new input or fail gracefully, not suddenly crash. Asserts should always be compiled out in release code, and cause premature return from the function with an error code or reasonable default, it should NEVER crash on release.

Re:printf

[Jorl17]

This is not input checking. Input checking is checking the input for validity and acting accordingly. This is an assert, which is usually used as a way for programmers to make sure they didn't fuck up. If it is triggered, then the programmer fucked up. That's how it's supposed to be used.

Hence, the programmer fucked up, and this isn't input checking. It is nevertheless, IMO; a good practice to assert things (in debug code), but it also isn't checking for valid inputs, it's checking for programmer stupidity.

Re:printf

[Obfuscant]

A bad string isn't exceptional

Especially when the interpretation of that "bad string" is supposed to be CASE INSENSITIVE and the "exception" occurs because one character is upper case.

URI are defined here, and the part that deals with the "file:" or "http:" part (called the "scheme") says this:

3.1. Scheme ...

Scheme names consist of a sequence of characters beginning with a letter and followed by any combination of letters, digits, plus ("+"), period ("."), or hyphen ("-"). Although schemes are case- insensitive, the canonical form is lowercase and documents that specify schemes must do so with lowercase letters. An implementation should accept uppercase letters as equivalent to lowercase in scheme names (e.g., allow "HTTP" as well as "http") for the sake of robustness but should only produce lowercase scheme names for consistency.

Emphasis mine.

This is a case of a programmer implementing a feature defined in a standard and ignoring the standard when doing so. Not lazy, just ignorant and stupid. Just like the ignorant stupid programmers who write javascript email address verifiers that refuse to accept valid email addresses because they contain characters like '+'. Those programmers should be shot.

Re:printf

[Darinbob]

Check the input, then deal with the error. Crashing is not dealing with the error. Assert should be used for "should never happen" cases, like pre/post-conditions.

Re:printf

[Darinbob]

To the user, there is no difference between crashing due to an assert or crashing due to following some strange pointer. Now the assert may give the developer more information to work with to fix the bug, but it should always be considered a major failing if a user ever sees it.

Re:printf

[matunos]

assert should be compiled away in production code. :-)

Re:printf

[Darinbob]

Well, yes, but the last three jobs we've had to leave them in...

Re:printf

[TheRealMindChild]

The point of assert is to set a breakpoint to go to during unit testing

Re:printf

[shutdown -p now]

assert() isn't really "debugging code". It's more of a sanity check - as the name implies, it's a macro that checks that expression is indeed true, where the standing assumption on this particular code path is that it must be true. If it's not true, then there's a logic bug somewhere in the program, and that may lead to data corruption or worse. So liberally sprinkling asserts around and leaving them in release builds actually helps - it's far better to fast-fail than to continue running the process in a potentially corrupted state, from security perspective.

Of course, the assert shouldn't be triggered in the first place - the fact that they somehow got into this state is itself a bug, which they should fix. Still, kudos to Apple folk for handling this one in a manner that makes it useless for an exploit.

Re:printf

[shutdown -p now]

A perfect program should not crash for any reason - but very few programs of any considerable size are perfect. And even well-written software has bugs.

Asserts are meant to indicate that the condition should always be true on this particular code path - that's why it's called an "assert". It's not a tool to check for exceptional conditions and gracefully handle them - you have conditional statements (and exception handling, if the language supports that) for those purposes. You use assert after you have used a conditional to fork off onto a code path to assert that all the implied conditions are, indeed, true. If the conditions are not true, it indicates a bug in the logic of the program - the assumption was not correct. There is no way to gracefully handle that, because you don't know where exactly the problem is, and therefore you can no longer rely on the state of your process being correct. If you hit an assert, it means that some objects you thought to be alive are now dead, and you might have dangling pointers around. Or maybe some variables that you think have correct values in them have something outdated and completely irrelevant. Either way, if you keep running, you risk integer and buffer overflows - and from there, execution of arbitrary injected code. From security perspective, this is the worst scenario you can end up with, especially for an application facing the network or processing external inputs from the network. Fast-fail (i.e. consistently crashing right away) is much preferable to that, even if it inconveniences the user.

Re:printf

[Jorl17]

You're right, the performance difference is negligible. I guess it's just a habit I've developed, though when I come to think of it, it really makes some sense to leave that in release code. OTOH, it might reveal what you expect a function to do more easily, thus facilitating reverse-engineering if one is afraid of that.

Re:printf

[gargleblast]

as a programmer myself, when coding something and a harmless and not completely unexpected input occurs, your program shouldn't crash, due to any reason, asserts included. Such a failure is sign of nothing but lazy programming and even lazier unit testing.

Whoa there!

1. Don't worry about the harmless. WORRY about the HARMFUL
2. Don't worry about the "not completely unexpected". That is, of course, the expected. WORRY about the UNEXPECTED
3. "your program shouldn't crash" ... thank you Capt'n Obvious. Now quick: think of three things a program can do that are worse than crashing.

Bzzzt. Time's up. Did you get: (1) Have exploitable security flaws; (2) Corrupt or delete data; (3) Hang or livelock. There are others.

Cheers.

Re:printf

[shutdown -p now]

I think I'd worry about security (think dangling pointers and integer/buffer overflows in case your data isn't in a state you expect it to be) before worrying about ease of reverse engineering in pretty much every scenario I can think of. In the end, if someone really cares that much about my code, they will reverse engineer it one way or another - by tracing all the way through the assembly, if necessary. Weaker security, on the other hand, means potential problems for users of my code - i.e. my employer's customers. When you have a lot of customers, that can add up to a major snafu real quick - not to mention the moral responsibility.

Re:printf

[Bomazi]

You don't understand what assert() is for.

It doesn't cause a crash. Quite the opposite. It is a way of deliberately causing program termination upon encountering an internal inconsistency; precisely so as to avoid a crash, a silent failure or some other undesirable behavior.

Obviously, in a bug-free program, assert() would never trigger and is therefore unnecessary. In the real world it is a useful safety net.

Note that assert() is sometimes used to catch runtime errors. That is indeed inappropriate. But you shouldn't condemn the tool because it is sometimes used incorrectly.

Re:printf

[AuMatar]

You can remove asserts because your program is NEVER supposed to rely on them. The following code:

assert(foo!=null); //do something

is WRONG. Because it depends on the assert. The correct way to code it is

if(foo == null){
        assert(false);
        return some_error_value;
} //do something

Crashing is NEVER acceptable. And you cannot assume its ever an option in a production system- when you crash cleanup code is not necessarily run, and you can leave the system in an unrecoverable state. Fucking amateur.

Re:printf

[Macman408]

I used to think the same way about kernel panics in an operating system - I thought there was no reason why the system should ever halt. And then I had an OS class, where it was pointed out that halting is a quite valid choice when encountering an error condition that indicates that something has gone fundamentally wrong. For example, if you have an allocation bitmap that tells you what parts of your disk is in use, and what parts are free, it has a checksum, and the checksum is incorrect. It may very well be that the safest thing to do in this case is halt, rather than risk a write making it to the disk and overwriting a block that is in use. The user can reboot, and that will probably be the best way to recover from the error. It might be possible to display an error message, however since the code to display such a message is not often used, it's likely still on the disk (it was either never loaded, or was loaded and then swapped out of RAM). So you might think it's safe to try to read the disk still - but you have to set some state somewhere saying that under no circumstances should you write anything while you try to load this code. But what's to say that whatever state you set is working? Obviously something is broken, your checksum was wrong! And for that matter, if you need to swap something else out to load this new code in, you can't, because you've decided that writes are now unsafe. For that matter, maybe the disk is acting up - maybe it'll interpret a read command as a write, or take some other completely bogus action. Or maybe what you think is your memory-mapped disk is now really the network card, because some CPU configuration registers picked up a bad value. Bottom line; there are definitely good reasons to just stop a program, OS, or whatever when you detect an error that should never happen.

That said, this case is not one of those good reasons.

Re:printf

[BasilBrush]

I have also had the impression that assert() is a hack that shouldn't be used much (?).

It should be used rather a lot. Every time you believe you know something will always be true, but might break if it wasn't, you should put an assert there.

There's no point putting an IF there, because you can't forsee the case where it will be taken. Likewise an exception - exceptions are for foreseen error states. And ignoring it will result in a harder to find bug if that belief is ever wrong.

It's pretty rare when the bug exists in the assert, rather than the main code. Rarer still when it's an assert that is active in release builds. This is one of those cases. But it doesn't mean that asserts are a bad thing.

Re:printf

[rve]

I have also had the impression that assert() is a hack that shouldn't be used much (?).

It's a hack that should be used extensively - in development code. In the production build, you generally turn on a compiler flag that prevents asserts from being compiled. This is why it's absolutely criminal to put code in an assert that has any side effects whatsoever.

Re:printf

[BasilBrush]

That's only one of it's purposes.

It's general purpose is to give physical form to assumptions in the program itself. It both assures that the assumption *is* always correct past that point, and it documents it.

A novice programmer might say, don't make assumptions. But real programmers make reasonable assumptions all the time. For example if you've just written code to calculate an count, and that calculation can't make a number that's zero or less, then that's a valid assert.

Re:printf

[BasilBrush]

Then instead of an assert you should have a return error (or throw exception) statement.

No. Those can only ever be for foreseen error states. If they are not foreseen, then they are no documentable, and therefore the calling code can take no sensible action to react to the error or exception.

An assert is a documentation of something that's always true and will never fail. If it fails, that's a bug, and there's no graceful handling of bugs - if you could foresee them, you would have already fixed them.

The question is whether to only have them in debug builds or whether to have them in release builds too. Contrary to your ASSERTION, asserts aren't necessarily compiled out of release builds. The answer is they go in release builds too if the worst case scenario is data corruption from continuing in an unpredictable state.

None of this is in Programming 101. This is stuff you learn when you've been programming a long time.

Re:printf

[BasilBrush]

Have you heard of Code Complete? If you're a programmer, you probably should have read it. You should probably have a copy in your bookcase. Go read what it has to say in it's section on Assertions before you post any more ill-informed comments on this thread.

Re:printf

[Hal_Porter]

I like C, but the problem is that most programmers cause chaos when they write it. C was always meant as a language that people who like assembler will like and use and be more productive. It was not meant as a language that today's script monkeys should use.

Also Objective C was designed according to the prinicples of Objectivism - i.e. the code of the looters and moochers would crash and burn and bankrupt their companies whereas the code of Great Men would navigate the formidable obstacles of pointers and demonstrate their status as Nietzschean Ubermenschen and be rewarded with tonnes of cash and Patricia Neal, so this is not really surprising.

Re:printf

[shutdown -p now]

This is terminated because the program did not expect to see an URI with such capitalization, and (presumably) doesn't have code to handle it correctly - leading to an unexpected state where you can no longer be certain of the data. It indicates a bug (they forgot to handle different capitalization correctly, and they forgot to do proper user input validation), yes. But the way it handles that program bug, until such time as it's fixed, is absolutely correct.

Re:printf

[shutdown -p now]

In your release build, it should never be hit. But unless you can absolutely guarantee it, leave it there. You will make mistakes, and it's better to handle them in a safer manner.

If it's hit, your program is in a state that you have not foreseen when writing it. If you're using assert for its intended purpose, then you're claiming: "I expect this condition to always be true here; the following code is written with this assumption in mind". If the condition is somehow not true, then the following code is a bug/exploit farm, and should not be allowed to run. You might also want to phone home, yes (though e.g. on Windows, WER will do it for you if you register for it). You definitely don't want to do nothing.

Re:printf

[Jappus]

Based on what you said, the summary title is incorrect. The programs aren't crashing, but rather are ending normally, just not when the user thinks they're telling it to.

It is easy to argue that while this is technically a "normal" shutdown given the code of the program; it is certainly not a normal shutdown given the task and role of the program.

You know: Letter of the law versus spirit of the law.

Your program can only execute the letter of the law (its code), but its true purpose should always be the spirit (its intended role). Otherwise, any bug inside the program would need to be considered as a "normal program exit", as the bug is an inevitable result of its code. Since that is obviously not the case:

This assert being thrown IS a bug, and the subsequent application exit not a normal shutdown. There is nothing to defend here as being "good".

Re:printf

[SanitaryFather]

Cool! Great way to restart apps, no more clicking those pesky little x's.

Apple's response

[Anonymous Coward]

You're doing it wrong.

no big deal.

Steve

Re:Apple's response

[girlintraining]

Steve is in the iCloud now. Someone tried turning him off and then back on again. In an appeal to hipsters, he's gone underground to sell more macs. He is permanently 404. There is no way he could have had anything to say about this. There is no app for that. Get it? :P

Re:Apple's response

[dugancent]

My response:

Steve is dead and has been for over a year. Time for some new jokes.

Re:Apple's response

[jrumney]

Indeed, they already released a fix for it. It's called iCloud. Keeping things in the privacy of your own disk is now officially a bug (soon to be reclassified as user error).

BRB

[AmiMoJo]

BRB, heading down to the Apple Store...

Re:BRB

[drcagn]

Typing the string has the same effect on the app as quitting the app. So.... have fun going to the apple store and quitting the apps.

Re: BRB

[rsmith84]

Not without a Genius Bar appointment you're not!

Re:BRB

[drcagn]

I know, I can be dangerously addictive sometimes.

Re:BRB

[Tablizer]

heading down to the Apple Store...

Reminds me when I was teen at the mall before the PC era, I'd see a computer on display in the store and type in:

10 PRINT "RUN, COMPUTER WILL EXPLODE!"
20 GOTO 10
RUN

Re:BRB

[AmiMoJo]

It produces a nice exception error message. Perfect for making Apple fanbois who claim that Macs never crash look like twats.

Powerpoint summary of TFS

[TapeCutter]

- An obscure library bug triggered by a magic string.

- In the latest version.

Re:Powerpoint summary of TFS

[jonadab]

> An obscure library bug triggered by a magic string.

The thing is, the magic string in question is not particularly obscure. Any app that normally handles URLs is fairly likely to get that typed into it at some point. Okay, granted, protocols are usually not capitalized, and File:/// is no more common than Http:// or Mailto:, but nonetheless, this is something people are definitely going to run into occasionally.

(Yes, file protocol terminates the protocol with just two slashes; but, importantly, the next segment of the URL is an absolute path. So while the third slash would be a typo on a multi-rooted system like Windows or VMS, it's pretty much mandatory on a single-rooted system that uses slash as a directory separator -- like, say, anything with Unix underpinnings.)

Re:Powerpoint summary of TFS

[oakgrove]

Just a thought, using something like vnc from a mobile device would make it more likely to happen since keyboards on most smartphones/tablets capitalize the first letter in anything it thinks is a sentence.

Re:Powerpoint summary of TFS

[adolf]

Actually, the third slash means "this computer" and is required on Windows too. You have to write "file:///C:/..." on Windows to get anywhere. So no, it isn't a typo.

[citation needed]

On my computer (Windows 7), in Windows Explorer, these all work the same:

file://C:/
file:///C:/
file:////////////////C:/

These also work the same:

file://
file:///
file:////////////////

You're doing it wrong

[greggman]

No one should ever need to type file:///

There are no bugs. You're doing it wrong

Re:You're doing it wrong

[sjames]

Maybe he's using a Mac. The first two times he tried that message, Safari crashed.

Re:Little light on specifics....

[Kenja]

Ah, did manage to replicate it. Despite what the long article says, it does seem to be case sensitive. Very odd bug. The truly worrisome thing is that this would seem to indicate that even the most basic of text editors is capable of running scripts from plain text (as opposed to apple script). Not sure what the ramifications of that are, but it seems like a potential vector for malware.

So?

[Bogtha]

First off, itâ(TM)s worth noting that the bug only appears to be present in OS X Mountain Lion and is not reproducible in Lion or Snow Leopard. Thatâ(TM)s not exactly good news given that this is the latest release of Appleâ(TM)s operating system, which an increasing number of Mac users are switching to.

Talk about over-egging the pudding. You're talking as if it's a fundamental flaw that ruins the whole operating system. It's a bug. Of course it's not good news, but it's not certain doom for Mountain Lion either.

Re:So?

[93 Escort Wagon]

Speak for yourself - I just rolled back to Tiger!

The cause, and a fix

[rsteele19]

Landon Fuller has posted a gist on GitHub with an explanation of the bug and a binary patch to the affected library.

Re:The cause, and a fix

[93 Escort Wagon]

Landon Fuller has posted a gist on GitHub with an explanation of the bug and a binary patch to the affected library.

Yeah, THERE'S a good idea - apply a binary patch from some random post on Slashdot!

Re:The cause, and a fix

[phantomfive]

You can read the patch first, like the rest of us, right?

Gödel Lives!

[Sam Williams]

http://kleinschmidt.wordpress.com/2006/07/03/i-cannot-be-played-on-record-player-x/

Re:No, It Doesn't

[Anonymous Coward]

The bug is case sensitive; as the bug report says "The capital 'F' is important."

Please do not bother posting something so quickly, without looking into it.

Let's look at the stack trace

[MrEricSir]

This is the stack trace mentioned in the article:
http://pastebin.com/UkhERvaA

Doesn't look like a c-string or printf issue to me at all.

Even crashes the crash reporter!

[Wormholio]

I tried this in Safari on Lion. Capital F required, but indeed just "File:/// " crashes it.
Then you get a pop-up asking if you want to report the problem to Apple? Sure.
But then that crashes with a pop-up reporting that crash reporter has crashed. Bonus!

It's the old Windows 98 bug all over again.

[Dwedit]

You used to be able to BSOD a Windows 95 or 98 machine by trying to read C:\con\con, and this included any web pages that requested file://C:/con/con.

Re:I actually typed it, and nothing happened

[mmarlett]

Oh, wait, capitol F. That does cause a crash. Since when has a Mac been case sensitive? I guess that's what they get for listening to all those hackers complain about case insensitivity. ;)

Re:I actually typed it, and nothing happened

[EvanED]

From a comment above, the problem is that it's not case sensitive, except for an internal sanity check which is.

E.g. the dispatching code said "the user typed File:/// and I have a handler for file:///, so I'll call it", but then the handler had what was basically an case-insensitive comparison assert(url.startswith("file:///")).

So the problem isn't case sensitivity or insensitivity -- it's that it was being inconsistent about it.

Why is Apple shipping non-optimized code?

[Branka96]

If this is an assert as it appears to be, my question is, why is it in shipping code. Normally asserts are controlled by the NDEBUG symbol (or equivalent) which is undefined in optimized builds. In my opinion asserts should not be in shipping code. You should have something more solid in place.

Re:Why is Apple shipping non-optimized code?

[fnj]

And that, people, is why operating systems have become so grotesquely bloated and gigantic. An endless accumulation of "oh it's only a few more bytes".

Re:Why is Apple shipping non-optimized code?

[shutdown -p now]

asserts are there to catch bugs. Not invalid user input or other conditions that you can predict and gracefully handle, but actual programmer bugs - mistakes in the logic of the program.

If you ship your code with asserts disabled, you are, effectively, asserting that your code is bug-free. If you don't feel confident enough to make such a claim, then leaving them in there is a good idea - you lose a wee bit of perf, yes, but if things do go wrong, the user (and therefore you, when the user files a bug report with a crash dump) will find out much faster, and you will be able to pinpoint the problem more precisely. Furthermore, it prevents the program from running in a bad state and potentially opening up vectors for exploits.

WTF

[Anonymous Coward]

Ok, I didn't believe this, I thought it might be a hoax so I wanted to try this and typed it into a file in the TextEdit.app, and it crashed the TextEdit.app completely!!!!! I had a 10 page paper that I was writing in there opened and it hadn't failed yet. The paper is due tomorrow!! is there a way to sue apple for damages over this?!!?!!!!??

Re:WTF

[BasilBrush]

I realise this is a troll, but for anyone thinking it might be real:

He's just need to restart Textedit, and all the documents he had open will still be there, still opened, in exactly the state they were in seconds before the crash. Snow Leopard documents don't need saving, they are constantly persisted whilst editing. Even if you have't yet given them a filename.

Re:Sure enough

[BasilBrush]

Even more interesting is that fact it didn't prevent you from making that post.

Re:Little light on specifics....

[cheesybagel]

Let me guess. The Google search box in Firefox was not implemented using Apple's Cocoa widget Framework.

Re:So, how can I type it for them?

[cheesybagel]

File:/// Or whatever.

It is case sensitive

[PhunkySchtuff]

After trying this in every app I could think of, and failing to crash them, it turns out that this is case sensitive.

Some dude has done a more detailed analysis over on github but the long and short of it is that there is a specific check in the code for 'file://' and any other case will cause it to crash. All caps - crash. Capital F and the rest in lower-case - crash. All lower-case and a capital L - crash.

Re:Running Mountain Lion....

[Frankie70]

You are holding it right. The others aren't.

it's an old joke

[PopeRatzo]

"Doctor, it hurts when I do this... Can you help me?"

"Sure, don't to that."

I'm going to give some free advice to users of Apple's OSX Mountain Lion: Don't do that.

you obviously didn't read it

[Chirs]

It's a commented assembly listing with a proposed hacky fix in assembly.

Re:donotwant

[node 3]

It's kind of fantastic, actually. Someone sends you an email saying, "let's meet for lunch tomorrow", or "my new phone number is ...", etc., and these become clickable to enter a calendar appointment, or address book entry, etc.

These trace back to the Newton, and were a huge part of that device's "magic". And when you get an email with a UPS tracking number as plain text (instead of a hyperlink), and it becomes clickable and asks if you want to track your shipment, you get one of those, "oh, now that's cool!" moments.

Google does something similar in search results. If you put in a UPS tracking number, the top result is for you to track the shipment, etc.

oh ya.

[AndyKron]

It just works...

I've been closing my apps that way for years.

[joelville]

I thought everyone knew File:/// is the new Command-Q