I don't know if this is a product or evangelism issue: Start out not logged in to a Yahoo account. 1. Go to my.yahoo.com and log in 2. Click to a news story 3. Use Back button REsult: No longer logged in Expected: Remain logged in (as worked in earlier browser versions) NOTE: If I log into Yahoo mail, then go to my.yahoo I *do not* get logged out when going to a news story then using Back button to get back to my.yahoo. Occurs in Gecko/20011128

hmm. I can't reproduce this bug with 0.97 or 0.9.7+ builds. going back after reading a news item does not log me out (win2K). can you test it again?

I think this is currently working on trunk builds.

I replicated on Gecko/20020111. Asa I can show you.

I found the bugzilla bug that IS this issue. http://bugzilla.mozilla.org/show_bug.cgi?id=105299 Marking duplicate *** This bug has been marked as a duplicate of 105299 ***

Reopening; Radha said the other bug wasn't a dupe of this. ________________________ Additional info re. replicating Yahoo problem: -I do not have "Remember my ID & Password" checked -I have my.yahoo listed as a "Passwords never saved" in Password Manager -If I log in, then use the Back button I go to the website that I was on *before* my.yahoo. So to replicate you don't actually need to go to a page within Yahoo.

Pasting comment from jaimejr@netscape.com: I've been able to reproduce this, and do have "Remember my ID & Password" checked (but i had signed out, prior to signing back in again). I am adding regression, because this has worked for ME in previous releases. Of note, the lock icon is RED and broken when i log into yahoo, and unlocked when i go to news story.

nsbeta1+ per ADT triage team

After you type in a user id and password, the login script does a server side redirection to my.yahoo.com. The postdata in the original channel (which contains all login information) is not passed over to the new channel created for my.yahoo.com. session history stores this url with out the postdata and therefore all future back/forward operations to my.yahoo.com logs you out. Giving to Darin, who can process this further.

something interesting: if you press reload after logging in, and then click on a story and go back... you won't see this bug. something about the reload fixes this. i'm not sure yet why. more to come...

also, if i login to my.yahoo.com and then open a new window and type my.yahoo.com in the URL bar, i get the correct (logged-in) page. so, this doesn't have anything to do with cookies. moreover, if i clear my cache after logging in and then go visit a news story and then press back, i get the correct (logged-in) page. my http log shows that on back we are pulling the page from the cache. i'm going to try to verify the contents of the disk cache. it seems like the page that results from logging in is not get stored correctly under the key "http://my.yahoo.com/" or something like that... more to come...

oops... when i said "cookies" i meant "POST data" ... it has everything to do with cookies ;-)

ok, i found the source of the problem. the POST request is to a HTTPS site. therefore the INHIBIT_PERSISTENT_CACHING load flag is set. when we get redirected, the new channel inherits this load flag. as a result we store the logged-in my.yahoo.com in the memory cache. when the users visits a new page and then hits the back button, we retrieve the document from the disk cache instead of the memory cache. i confirmed that the memory cache entry hadn't been evicted, so i suspect there's a bug in the cache device search order or something like that. gordon: can you take a look? could any of the recent cache changes possibly explain this? i'm going to put together a patch that fixes HTTP to not merge the INHIBIT_PERSISTENT_CACHING flag if redirecting from HTTPS->HTTP, but that would only be a work around for the regression... though it is still a completely valid bug that was hidden by our cache working as designed (i think).

actually, after stepping through the debugger i see that mMemoryDevice->FindEntry is failing, which is strange because i recall seeing my.yahoo.com in the memory cache after demonstrating this bug... hmm.

nevermine, it's not strange... upon pressing back the full cache key is "HTTP:http://my.yahoo.com./" instead of "HTTP-memory-only:http://my.yahoo.com/" so of course it wouldn't find it in the memory cache. i think we've had this bug ever since http was modified to use the new cache. will continue on with the solution from comment #12...

Comment on attachment 71957 [details] [diff] [review] v0 minimal patch suitable for mozilla 0.9.9 looks fine.

-> 1.0

setting appropriate priority and severity

Comment on attachment 71957 [details] [diff] [review] v0 minimal patch suitable for mozilla 0.9.9 sr=mscott

Comment on attachment 71957 [details] [diff] [review] v0 minimal patch suitable for mozilla 0.9.9 a=asa (on behalf of drivers) for checkin to the 1.0 trunk

fixed-on-trunk

VERIFIED Fixed with 20020041003 builds - using original steps to repro. the lock icon does the right thing now as well (unlocked for both pages)

Just want to connfirm... This IS in the 1.0 branch?

Nevermind I reread the bug and fix date. It looks like it made the 1.0 branch.

Reopening. It is broken again on Win2K Gecko/20020428 To replicate, start from the my.yahoo.com page while signed out, not from a page where password manager has stored your info.

OK appears to be working in 2002043006 Re-marking fixed.

*** Bug 120234 has been marked as a duplicate of this bug. ***

*** Bug 123828 has been marked as a duplicate of this bug. ***

v