Forum Moderators: open
<a href="#" onfocus="document.cookie='bandwidth=4;path=/;expires=Tue, 2 Jun 2015 00:00:00 UTC;'" onmousedown="document.cookie='bandwidth=4;path=/;expires=Tue, 2 Jun 2015 00:00:00 UTC;'" onmouseup="window.location.href=('http://www.example.com/');" tabindex="1" title="Enter JAB's site with site's audio enabled using broadband.">Broadband Connection</a><span> - </span>
<a href="#" onfocus="document.cookie='bandwidth=2;path=/;expires=Tue, 2 Jun 2015 00:00:00 UTC;'" onmousedown="document.cookie='bandwidth=2;path=/;expires=Tue, 2 Jun 2015 00:00:00 UTC;'" onmouseup="window.location.href=('http://www.example.com/');" tabindex="2" title="Enter JAB's site with site's audio enabled using dial-up.">Dial-Up Connection</a>
<br />
<a href="#" onfocus="document.cookie='bandwidth=3;path=/;expires=2592000;'" onmousedown="document.cookie='bandwidth=3;path=/;expires=Tue, 2 Jun 2015 00:00:00 UTC;'" onmouseup="window.location.href=('http://www.example.com/');" tabindex="3" title="Enter JAB's site with site's audio disabled using broadband.">Broadband Connection</a><span> - </span>
<a href="#" onfocus="document.cookie='bandwidth=1;path=/;expires=2592000;'" onmousedown="document.cookie='bandwidth=1;path=/;expires=Tue, 2 Jun 2015 00:00:00 UTC;'" onmouseup="window.location.href=('http://www.example.com/');" tabindex="4" title="Enter JAB's site with site's audio disabled using dial-up.">Dial-Up Connection</a>
Anyway, what happens if you use GMT in stead of UTC?
Basically it looks like the order of the cookie parameters is stricter in Safari than in other browsers. (This belief based in part on quirksmode article on cookies.)
- name/value
- expires
- path
- domain
? That would be rather picky behaviour.
The cookie setting code from JAB Creations works as expected in Safari when isolated. Isolated cookie setting code that works:
document.cookie='bandwidth=4;path=/;expires=Tue, 2 Jun 2015 00:00:00 UTC;'
In fact, this entire test page works correctly in Safari:
<script type="text/javascript">
<!--
function getCookie(name) {
var dc = document.cookie;
var prefix = name + "=";
var begin = dc.indexOf("; " + prefix);
if (begin == -1) {
begin = dc.indexOf(prefix);
if (begin!= 0) return null;
} else {
begin += 2;
}
var end = document.cookie.indexOf(";", begin);
if (end == -1) {
end = dc.length;
}
return unescape(dc.substring(begin + prefix.length, end));
}
//-->
</script>
<p><a href="#" onclick="document.cookie='cookie1=10;expires=Tue, 2 Jun 2015 00:00:00 UTC;path=/;'" >Set a onclick cookie</a></p>
<p><a href="#" onclick="alert(getCookie('cookie1'));">Read it</a></p>
<p><a href="#" onfocus="document.cookie='cookie2=10;path=/;expires=Tue, 2 Jun 2015 00:00:00 UTC;'" >Set a onfocus cookie</a></p>
<p><a href="#" onclick="alert(getCookie('cookie2'));">Read it</a></p>
<p><a href="#" onmouseover="document.cookie='cookie3=10;path=/;expires=Tue, 2 Jun 2015 00:00:00 UTC;'" >Set a onmouseover cookie</a></p>
<p><a href="#" onclick="alert(getCookie('cookie3'));">Read it</a></p>
Of course, onfocus is *not* the same as onmouseover, and in Safari at least that means onfocus is only triggered when a user gives the link focus through alt-tabbing to the link (in other words, keyboard focus, not mouse focus). I'd personally recommend using onclick.
So, if Safari isn't setting a cookie, it's some other piece of code that is bungling it.
JAB Creations site is very frame heavy, so the comment from that page may be relevant... (my bold)
Safari ships with a conservative cookie policy which limits cookie writes to only the pages chosen ("navigated to") by the user. This default conservative policy may confuse frame based sites that attempt to write cookies and fail. Be sure to check the Safari preferences before assuming that your cookies are not written due to a bug; it may just be the users preference.
Anyway I've implemented a cloaking based work around for Safari on my site. It's not a bug fix however though it can be tested by simply spoofing as Safari. Keep in mind that spoofing too much on my site will mess up virtually all browsers.
Still I have not been able to find a fix for setting the cookie via JavaScript for Safari.
AWildman & RonPK, tried your suggestion and it had no effect.
RonPK, my Uncle has a Mac and Gregg has been assisting me as well.
I suspect that it is the way I've set the cookie. I'll have to wait a while before I can call my uncle to confirm whether it works or not.
My site isn't frame heavy, four frames. They are only required (since version 2.7) if you wish to listen to music on my site. In fact I've intentionally set the non-audio links to not use frames!
Anyway I've got to keep the script simple, I am very against adding proprietary related scripts. Safari has been one step short of a nightmate (IE, IE). It does not support noscript (conditional, without a script associated with it), nor does it play nice with my theme changer.
I'm starting to think that Safari has issues specifically with JavaScript but I never have a grand sitting in the bank doing nothing to put any of my theories to test.
We shall see! I'll post after I test the order thjat Ron suggested. Thanks for your help folks! :)
- John
Added: Safari does support <noscript>... Safari does not support conditional comments (<!--[if IE]>) which is a proprietary IE-only feature.
onclick="document.cookie='bandwidth=3; expires=Tue, 2 Jun 2015 00:00:00 UTC; path=/';"
Still looking to get this working.
- John
So you need to have a web server running in order to test Safari's cookie handling.
Here is my test code:
<a href="#" onclick="document.cookie='bandwidth=4; expires=Fri, 05 May 2006 00:00:00 GMT; path=/'; return false">set cookie</a>
<br><br>
<a href="#" onclick="alert(document.cookie); return false">show cookie</a>
Thanks for the help, they'll have to suffer with the work around I implemented on my site however.
John
Apple Menu > System Preferences > Sharing > Check "On" next to Personal Web Sharing.
Then he can drop a file into /Library/Webserver/Documents and visit [localhost...] to access it.
I'm just facing facts that Safari refuses to do it's job and the downside of finding out with little to no direct access. Just like with the case of IE, there are much better browsers available. Thanks anyway though, the efforts are very appreciated.
- John
I used to have four framesets for each setting before I starting using cookies. I starting using cookies to reduce all the files since preference on a site are properly set by database/registration or cookies (in contrast to my file/preferences of version 2.6 and earlier).
*PS - The bandwidth cookie which was not being set has values 1-4 set according to the following...
4 - Broadband with audio enabled (64kbit)
3 - Broadband with audio disabled
2 - Dialup with audio enabled (20kbit)
1 - Dialup with audio disabled
** version 2.6 of my site and prior required visting the same frameset as the frameset would open certain files in certain frames. Preferences people had would not be remembered. So to keep user's preferences always know cookie is required!
This means that the preference must be set clientside so when the next page loads the cookie is read by the server and the server knows what to do.
By forcing HTTP I have been forced to create a work around *JUST* for Safari *cough* IE's new trouble-making friend *cough*.
That means I have to add files like I had previously done with framesets *JUST* to set a preference that otherwise would be set by JavaScript and have things run smoothly.
The BEST work around would be a hidden quick page. However if I visit a site and a hidden page quickly clicked by I'd be more then suspicious and have a look to satisfy my "why did they decide they had to do that" question freshly running through my head. So instead I have an obnoxious page that says that safari basically sucks and that the page is required.
This also means that the setup I have to enter *ANY* file through my site to ensure the person's preferences are set have to have a note for Safari users telling them it wont work unless they go through the frontpage (and here is a link for you (in the message to them, not my post)).
So *only* HTTP cookies are *NOT* acceptable. Cookies may be used to track but that is the point of them. They track a person's preferences. They are *NOT* spyware regardless of what the security companies would like to hype. The more of a selling point they can make to con people in to paying for programs that you can otherwise use for free the less ethical they will be. Cookies pose no threat and the stance Safari has decided to go with is simply unacceptable.
Furthermore besides this specific issue my theme changer (which is set by HTTP cookie) doesn't work. Another JavaScript issue with Safari.
Lastly Safari is a *insert really bad word here* to code for serverside. It is **NOT** like Gecko. This forces me to go off the "rv:" string in the UA. I don't care about spoofs, easy to sniff out (not going to discuss that though, personal trade secret ;-)). It caused lots of head aches.
ADDITIONALLY Safari does not support noscript element.
Yes it does.
*BUZZER* WRONG! If you put a noscript element without a script element it will automatically execute the noscript element regardless of the fact that JavaScript is enabled in Safari. I use noscript to automatically tell people to turn on JS for my site. Again my site is personal so I'm able to do what I please and traffic/cash is of no concern. It's strictly for my learning (and you BET I learn from working on it). It works or it does not work, end of story.
By finding issues with browsers it builds my skills. By knowing what I'm doing (compared to the overwhelming vast majority of people (in regardless to clientside specifically for the most part, (9.0/10 XHTML, 8/10 CSS, 4/10 JS self rating) I'm able to actually talk without having to worry about people asking me questions I don't know. This means I can confidentially say "Sir your bill will be *five digit number* for the final sum minus mod/max changes you make" versus say several hundred. I know the issues I have to deal with and the territory at hand.
If the day comes something doesn't work in Safari it's just more money I have to charge to get it to work correctly with specifically crafted work arounds or fixes. With Safari it's more about work arounds then fixes because that browser just ain't right!
I could continue to rant but I assume my point has been solidified. I have my work around, I know the issue. I can talk the talk and I've learned for Safari how to dance (because you might as well be in the spotlight, in your underwear at your high school prom for this one anyway if you don't know why in front of a client in this regard).
- John
*BUZZER* WRONG! If you put a noscript element without a script element it will automatically execute the noscript element regardless of the fact that JavaScript is enabled in Safari.
Interesting... I tested that theory by making a file that only contained this code:
<h1>No script?</h1>
<noscript>
<h1>Show me.</h1>
</noscript>
When I opened it in Safari, all I could see was the "No script?" The "Show me." did not render. Isolated code fails to support the claim. If you have a more complex test page, I'd be interested to see it. If I can find a browser bug, I'll send it to the Safari team.
Regarding your original issue, I have provided you working code already where the only modification to your original code was moving all the separate javascript into a single onclick insted of them being scattered into an onfocus, onmouseover, and onmouseup.
Like I've said before, the onfocus event in Safari is triggered by keyboard focus, not mouse focus. That is the only bug here that can be blamed on the browser.
. . . but I never have a grand sitting in the bank doing nothing . . .
Remember, Safari is based on Konqueror, Konqueror runs on Linux and virtually any x86 machine can be set up to dual boot. Voila, instant ability to test for Safari compatibility without having to give a penny to any Bill Gates wannabes. Note also, Linux is now on more desktops than OS X.
Additionally, excellent development products are available for Linux and IE can be run under Linux with Wine or Crossover Office. Basically, only when using ActiveX do you have to run Windows.
