Live data from Hacker News

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

openradar.appspot.com

201–206 of 206 posts

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

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

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

#202
post #152
post #145

Earlier quoted context omitted.

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

[deleted]

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

#203
post #152
post #145

Earlier quoted context omitted.

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

[deleted]

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

#204

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

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.

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

#205
post #147

Earlier quoted context omitted.

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

"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 parsin…

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.

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

#206
post #147

Earlier quoted context omitted.

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

"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 parsin…

[deleted]
Post reply on HN