Bug 13777 – Username and password not saved in cookie

• Status: RESOLVED
• Resolution: FIXED
• Component: Page Loading

[Peter]

When entering my username and password to this site and chacking the "remember me" box, the username and password are not saved. After closing WebKit and reopening again I will have to enter this agin. It is remembered when I use Safari.

[Alexey Proskuryakov]

I couldn't find any area asking for username/password on this site, with a possible exception of the forum. Is that where you see the problem?

Please note that form auto-fill is not supposed to work in WebKit nightlies, although "remember me"-like boxes should work.

[Peter]

Sorry, I did mean the forum. Thanks.

[David Kilzer (:ddkilzer)]

(In reply to comment #2)
> Sorry, I did mean the forum. Thanks.

Peter, did you verify that cookies aren't saved in Safari that are saved in Firefox (for example)?

There is a bug in Mac OS X 10.4 (Tiger) that prevents some cookies from being sent to the server when they should be (Bug 3512).  They will show up in the cookie viewer, but they aren't sent back to the web site when requesting a new page.

Are any cookies like this set for the forum?

[Peter]

A cookie is shown in the cookie viewer in Safari and Webkit. Previous nightlies did not have this problem. How can I check if a requested cookie is not returned to the server? Thanks.

[David Kilzer (:ddkilzer)]

(In reply to comment #4)
> A cookie is shown in the cookie viewer in Safari and Webkit. Previous nightlies
> did not have this problem. How can I check if a requested cookie is not
> returned to the server? Thanks.

You'd have to run a packet sniffer like Ethereal or Wireshark (which don't have "native" OS X builds; they only run under X11) or running the tcpdump command to save the outgoing packets.  Then you can look at the HTTP headers sent by Safari/Foundation to determine if the cookies went out.

What does the cookie look like, e.g., it's domain ("web site"), name, path, secure, expires, contents (if it's not private)?

[David Kilzer (:ddkilzer)]

(In reply to comment #4)
> A cookie is shown in the cookie viewer in Safari and Webkit. Previous nightlies
> did not have this problem. [...]

Can you narrow it down to a nightly version that worked, then next version that did not work?  That would be VERY helpful as well.

[Peter]

The nightly that I downloaded friday did not work. Mondays version did work though.

[David Kilzer (:ddkilzer)]

(In reply to comment #7)
> The nightly that I downloaded friday did not work. Mondays version did work
> though.

So it regressed sometime between Monday, May 14 (which worked) and Friday, May 18 (which did not work)?

[Peter]

Yes

[Alexey Proskuryakov]

I haven't been able to reproduce this yet. I do see that cookies are saved somewhat irregularly (for example, deleting all retrobike.co.uk cookies and restarting the browser sometimes results in some of them being still there), but it may be normal, caused by NSHTTPCookieStorage asynchronous nature.

Also, there is an apparent problem with the server, which sends multiple Set-Cookie headers for each cookie; not sure how we deal with it:

Set-Cookie: phpbb2mysql_data=<skipped>
Set-Cookie: phpbb2mysql_sid=<skipped>
Set-Cookie: phpbb2mysql_data=<skipped>
Set-Cookie: phpbb2mysql_sid=<skipped>

Even worse, the server sets the cookies in a response with an incorrect status (302 Not Modified, instead of 200 OK).

Peter, I am sorry for asking you to double-check your findings, but this looks very much like a random server-side fluctuation, rather than a recently introduced WebKit bug. Could you please try to narrow down the range where the problem occurred to a pair of consequent nightly builds?

[Peter]

This can be closed. The problem disappeared, so it is probably due to the server. Thanks for the help though!