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