Live data from Hacker News

Do Not Type "File:///" in OS X

openradar.appspot.com

131–140 of 206 posts

Re: Do Not Type "File:///" in OS X

#132
post #126
post #53

Earlier quoted context omitted.

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'

> 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.

Re: Do Not Type "File:///" in OS X

#136
post #33

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 cr…

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:…

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
    
    (gdb) 
    (gdb) disass DDResultCopyExtractedURL
    
Also, this means the bug can't be exploited

Re: Do Not Type "File:///" in OS X

#137
post #94

Earlier quoted context omitted.

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?

Re: Do Not Type "File:///" in OS X

#138
post #126

Earlier quoted context omitted.

> 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.

Post reply on HN