Thank you! I actually fixed it at MacMegasite & WorldBeatPlanet by explicity specifying a path of "/" wherever I set a cooke, and Jon also applied that fix at MacMerc.

Now if you improve text editing (support find & replace and the spell checker), I can use Safari to write for my sites and trash OmniWeb completely, which I use only for that one purpose :)

There is another annoying cookie bug in Safari. Ironically, it affects this page (at least for me). Once you set a cookie (the preferred stylesheet) and quit the program, the preferred stylesheet cookie won't be able to change again, probably until the cookie expires itself or it is deleted manually by the user. This works fine in all other browsers with which I have tested it. Can anyone else confirm this?

i'm just wondering. there is a related problem: cookies that sites use to pass information to frames. the same problem applies, the frames don't seem to have access to the memory cookie they need so do not display any information. will this fix apply to that too? i hope so, cos a community site that i'm on nearly all the time is completely unuseable because of this problem. if this gets fixed and safari has tabs and form autofill, then it becomes my weapon of choice :-)

Hopefully this will fix the issues with cookies at aa.com (american airlines) and Citibank, which simply refuses to store any info. Maybe if a hypothetical bugfixed build were to accidentally slip out and fall into my hands...

yes. i might try to help you catch it...

Yep, literally the only reason why IE is still plaguing my system is beacuse it handles Citibank well. So ready to hit the jettison button on it, and hopefully this will do it.

Ok, I'm glad for this fix. In the weblog I've been building (my friend's weblog that I rebuilt completely, basically) I've been bitten by this. It's really annoying to have to grab $_SERVER['PHP_SELF'] and strip off the last path element. It really is.

This is not a cookie related bug, but a little annoyance I have found on my login pages (while fixing this cookie bug). If I put an 'onfocus="this.select()"' on a password field, I can not tab from a previous form field. If I hit tab to the password field I cannot type anything unless I click in the password field.

Has anyone else seen this?

Here's an example: http://davglass.com/test.php

Hurrah!! When will this be propegated to us general public type people?

Everytime I quit safari, I have to re-login to slashdot. Is this a related bug?

Krikey. I should have waited to read about this. I went and proposed a fix for PHPNuke site operators over at Cryptonomicon.Net. Still... Explicitly adding the "/" to the end of the setcookie() call is probably a good thing to do so this problem never reappears in other browsers.

Dav - I know exactly what you're talking about. a couple of my credit card and bill paying sites are like that, as well as hsx.com's login if I recall correctly...

Hopefuly this will fix the cookie problem with Bank of Montreal where the login expires right away.

Safari can't save permanent cookies from any site that uses Sun's Java Servlet/JSP API to set cookies... Safari just doesn't save them. Still not fixed, even in "unofficial" builds. These cookies work fine in IE/Camino/Mozilla/etc...

I figured it had something to do with the "path" as using lynx in Linux also will not allow users to login (Links works though). I look forward to the update being released.

Can we have a print button for the toolbar pleasssse? The kids at school miss it. (We have dumped IE for Safari and Camino on all our Macs)

:-)

I agree, Simon.

I'm under the impression that the toolbar implementation is a bit of a kludge just to get something there. I'm hoping for a standard Cocoa customisable toolbar with Option+Command+Drag button rearrangement.

Other than the hypothetically-existing tabs, a 'proper' toobar is about all I feel Safari needs to make me happy UI-wise.

>> a 'proper' toobar is about all I feel Safari needs to make me happy UI-wise.

me-too bar!

Hooray!

This one has bit me on phpwebsite, phorum, postnuke and a load of other php based scripts and is the only reason I still have IE on my dockbar.

I think Maciej is wrong in suggesting that the old Safari behaviour was correct and everyone else was wrong though. The Netscape spec specifies the path should default to the path element of the filename if no path is specified and that's what everyone else does, not including the filename part too.

I also hope www.domain.com/foo/bar.php will default to /foo and not /

I've been using headers to set my cookies with PHP, as oppose to setcookie. (i.e. Header("Location: http://someserver/somepage\nSet-Cookie:cookiename=value;path=/;domain=someserver\n\n");)
As you can see, the path is set to /, yet it still doesn't work with Safari. Anyone know what the problem is here?

Sol - why not just use setcookie()? That works fine with Safari.

Whoa, what happened to the rest of Dave's blog? Only the "Safari" items are left, and the archives are gone. Wah. :p

Ummm...am I the only one who enjoys both the safari info and the non-safari info?

Testing...

The Netscape Cookie Specification differed from Navigator 4.0's behavior in many details. To improve compatibility with existing sites, IE matched Navigator's behavior instead of matching the specification.

The take away is that the specification is not to be believed. Look at what IE and the other browsers actually do.

Kevin- A long, long time ago, when I first learned PHP, the big thing was to use Header() instead of setcookie() because it was the most compatible way to set cookies. Since then I have not bothered to explore whether or not this is an issue anymore. At any rate, I'd rather see Safari work with my existing code than to have to go through and change my method of setting cookies all over the place, I guess. Laziness. ;)

Sol, you could probably create a RegExp that, when applied to your PHP files, would translate all the cookie-setting headers into setcookie() calls.

Sol - You need to quote the values. I would also suggest that you write "full" cookies. - using setcookie i would define the variable before sending in the setcookie function: setcookie('$cookiename', $cookienamevalue, $cookie_life, $path, $hostname);

This way you avoid all the quote issues. And yes, the whole setcookie() issue in php was resolved long ago.

Safari does seem to be a LOT more picky (correct) about cookie formatting - more so than those OTHER name brands -- but writing full cookies will save you from the problem now and in the future.

One thing I have found to be a problem - Safari does not recognize a cookie expire time of less than 13 hours, (excluding 0). The cookie will not be written in this case. Gutterball.

I've got another php-nuke bug, I hope you don't mind me posting it here. My site uses scrolling text in a few blocks (ie. forums, reviews and old articles) on the index page. They work in Camino and Explorer but don't in safari. Can't figure out why. Using inserted javascript in to block. Any ideas?