InformAction Forums

Disclaimer: I realize this isn't a problem induced by NoScript in any way, but NoScript has become rather the one-stop-shop for fixing bogus Firefox / site / add-on behaviour.

I'm playing with a very small script surrogate that solves a problem that's been driving me up the wall since forever: sites that believe testing navigator.cookieEnabled is still a valid way to find whether a browser accepts cookies. An example of two (not a typo) large-ish sites that do this:
Unfortunately, from Fox 3.6.x on down (I haven't tested Fox 4.x builds), the global cookie preferences still determine what navigator.cookieEnabled returns: site exceptions are not taken into account. Ever. The vast majority of websites actually work quite well with extensions such as Cookie Monster and CS Lite, correctly detect whether cookies are enabled (probably by attempting to set a cookie, then testing whether an error occurred, which seems like the only sane way to do it...), correctly display errors if cookies are not allowed for that site, and so forth.

Sites coded up by dunces, as in the two examples, simply test the twelve-year-old flag and refuse logins, draw in-browser "pop-ups" to let you know you've got cookies disabled (even if you're logged in and navigating just fine!) and otherwise break. With the above surrogate, these two sites (at least) work the way you would expect them to.

If the example code is sub-optimal for some reason, it's because I know nearly nothing about JavaScript.

Giorgio: If you happen across my old post requesting help with this problem, throwing a JS exception is equally as bad as Fox' broken cookieEnabled behavior, at least insofar as sites testing this value continue to be broken.

anonymous_user wrote:

aloishammer wrote:[...] sites that believe testing navigator.cookieEnabled is still a valid way to find whether a browser accepts cookies.[...]

You're making it sound like the sites are at fault here[...]

Precisely! I explained why.

anonymous_user wrote:This is pretty much a bug that has been in Firefox for 6 freaking years. Well, maybe longer, but there are 3 Bugzilla tickets, the oldest of which is assigned to someone, and also 6 years old. I guess fixing it is a task akin to finishing up Duke Nukem Forever.

Worse, really: DNF is finally finished; just not in the sense of a released product. That's why I'm proposing NoScript fix (hack around) it if Mozilla refuse. And they do, apparently. (It may as well be marked WONTFIXTOOBADSOSAD.) Six years on, I've found a promising work-around, and I'd like to see other people benefit from it.

You need just one surrogate prefix "@" at the beginning, not one per source.

al_9x wrote:You need just one surrogate prefix "@" at the beginning, not one per source.

Thanks!

anonymous_user wrote:Anyway, I wrote this a couple months ago. It is rather less elegant than the OP's solution, but you can apply it to @* and be done with it.

If I understand what your code does-- You've written a proper shim that saves the date in a test cookie and returns true if the cookie ends up being set? --then it's actually quite a lot more elegant than mine.

I considered reading up on the necessary material to set (possibly also un-set) a randomly-named cookie with a random value, then trap errors, and so forth, but 1) I don't know where Fox gets its randomness, and 2) I was hoping someone would have an even better solution if I just posted the simplest possible code that didn't throw exceptions.