My.Yahoo - Logs you out when using Back button

VERIFIED FIXED in mozilla1.0

Status

()

Core
Document Navigation
P1
critical
VERIFIED FIXED
17 years ago
3 years ago

People

(Reporter: Susie Wyshak, Assigned: Darin Fisher)

Tracking

({regression, topembed+})

Trunk
mozilla1.0
x86
All
regression, topembed+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
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

Comment 1

17 years ago
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? 

Comment 2

17 years ago
I think this is currently working on trunk builds.
Assignee: asa → radha
Component: Browser-General → History: Session
QA Contact: doronr → claudius
(Reporter)

Comment 3

17 years ago
I replicated on Gecko/20020111. Asa I can show you.
(Reporter)

Comment 4

17 years ago
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 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 5

17 years ago
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.

Status: RESOLVED → REOPENED
Keywords: nsbeta1, regression
OS: Windows 2000 → All
Resolution: DUPLICATE → ---
(Reporter)

Comment 6

17 years ago
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.

Target Milestone: --- → mozilla0.9.9

Comment 7

17 years ago
nsbeta1+ per ADT triage team
Keywords: nsbeta1 → nsbeta1+
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. 
Assignee: radha → darin
Status: REOPENED → NEW
(Assignee)

Comment 9

17 years ago
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...
(Assignee)

Comment 10

17 years ago
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...
(Assignee)

Comment 11

17 years ago
oops... when i said "cookies" i meant "POST data" ... it has everything to do
with cookies ;-)
(Assignee)

Comment 12

17 years ago
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).
(Assignee)

Comment 13

17 years ago
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.
(Assignee)

Comment 14

17 years ago
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...
(Assignee)

Comment 15

17 years ago
Created attachment 71957 [details] [diff] [review]
v0 minimal patch suitable for mozilla 0.9.9

Comment 16

17 years ago
Comment on attachment 71957 [details] [diff] [review]
v0 minimal patch suitable for mozilla 0.9.9

looks fine.
Attachment #71957 - Flags: review+
(Assignee)

Comment 17

17 years ago
-> 1.0
Keywords: mozilla1.0, patch
Target Milestone: mozilla0.9.9 → mozilla1.0
(Assignee)

Comment 18

17 years ago
setting appropriate priority and severity
Severity: normal → critical
Priority: -- → P1

Comment 19

17 years ago
Comment on attachment 71957 [details] [diff] [review]
v0 minimal patch suitable for mozilla 0.9.9

sr=mscott
Attachment #71957 - Flags: superreview+

Comment 20

17 years ago
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
Attachment #71957 - Flags: approval+
(Reporter)

Updated

17 years ago
Keywords: topembed
(Assignee)

Comment 21

17 years ago
fixed-on-trunk
Status: NEW → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED

Comment 22

17 years ago
VERIFIED Fixed with 20020041003 builds - using original steps to repro. the lock
icon does the right thing now as well (unlocked for both pages)
Status: RESOLVED → VERIFIED

Comment 23

17 years ago
Just want to connfirm... This IS in the 1.0 branch?
Keywords: topembed → topembed+

Comment 24

17 years ago
Nevermind I reread the bug and fix date. It looks like it made the 1.0 branch.
(Reporter)

Comment 25

17 years ago
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Reporter)

Comment 26

16 years ago
OK appears to be working in 2002043006
Re-marking fixed.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → FIXED
*** Bug 120234 has been marked as a duplicate of this bug. ***

Comment 28

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

Comment 29

16 years ago
v
Status: RESOLVED → VERIFIED

Updated

10 years ago
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.