111–120 of 206 posts
Earlier quoted context omitted.
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.
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.
Spotlight.
Find field in chrome.
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:…
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
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?
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,…
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.
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".