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 :)
Posted by Mike Cohen at March 16, 2003 12:27 PMThere 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?
Posted by joe at March 16, 2003 12:58 PMi'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 :-)
Posted by lee underwood at March 16, 2003 1:37 PMHopefully 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...
Posted by payo at March 16, 2003 2:10 PMyes. i might try to help you catch it...
Posted by lee underwood at March 16, 2003 2:26 PMYep, 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.
Posted by payo at March 16, 2003 2:29 PMOk, 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.
Posted by Kevin at March 16, 2003 4:51 PMThis 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
Posted by Dav Glass at March 16, 2003 5:16 PMHurrah!! When will this be propegated to us general public type people?
Posted by zeus at March 16, 2003 7:24 PMEverytime I quit safari, I have to re-login to slashdot. Is this a related bug?
Posted by Chris at March 16, 2003 7:37 PMKrikey. 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.
Posted by Matt Hamrick at March 16, 2003 8:52 PMDav - 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...
Posted by Chris Kelly at March 17, 2003 6:56 AMHopefuly this will fix the cookie problem with Bank of Montreal where the login expires right away.
Posted by Anakin at March 17, 2003 7:30 AMSafari 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...
Posted by Hunter at March 17, 2003 8:48 AMI 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.
Posted by Technical Support at March 17, 2003 11:29 AMCan 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)
:-)
Posted by Simon at March 17, 2003 12:43 PMI 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.
Posted by Chris at March 17, 2003 2:39 PM>> a 'proper' toobar is about all I feel Safari needs to make me happy UI-wise.
me-too bar!
Posted by backspinner at March 17, 2003 3:00 PMHooray!
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 /
Posted by Shaun at March 17, 2003 4:34 PMI'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?
Suits and religions rupture if you force them on.
Posted by Seltzer Dan at February 28, 2004 6:05 AM