Closed Bug 86067 Opened 23 years ago Closed 23 years ago

Closing all windows in -turbo mode keeps sessions informations

Categories

(SeaMonkey :: UI Design, defect)

defect
Not set
major

Tracking

(Not tracked)

VERIFIED WORKSFORME
mozilla0.9.7

People

(Reporter: giannici, Assigned: ccarlen)

References

Details

When in -turbo mode, even if all windows are closed, the following information isn't cleared: 1) Authentication passwords 2) "0 timeout" cookies 3) Something else? Usually, to be sure that nobody else can came and use our browser to continue a session (e.g. of Home Banking) on behalf of us, we have to close all browser windows. Now this is not sufficient when Mozilla is in -turbo mode. I think that many users could be confused by this different behaviour, and this can become an important security threat.
->law
Status: UNCONFIRMED → NEW
Ever confirmed: true
secound try ->law
Assignee: asa → law
Component: Browser-General → XP Apps
*** Bug 91089 has been marked as a duplicate of this bug. ***
*** Bug 90904 has been marked as a duplicate of this bug. ***
*** Bug 91459 has been marked as a duplicate of this bug. ***
Blocks: 75599
-> conrad, who I think has a fix for this.
Assignee: law → ccarlen
Yes. This will be taken care of by bug 86021. Now back from vacation, I should be checking that in this week.
Status: NEW → ASSIGNED
BTW, I'll leave this open for now. It's not a dup and it's certainly valid.
Fixed, right?
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Yes - with single or multiple profiles. Can somebody else verify?
On one of my systems with IMAP4.1 and NT4 SP6 not fixed! Closing Mail window and Mozilla hangs! build 2001083103 Win32. Not vialdated.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
What does that have to do with this bug?
*** Bug 98330 has been marked as a duplicate of this bug. ***
Seems like this was reopened for the wrong reason; please report hangs or any other unrelated problem as separate bugs. Targetting 0.9.4 to get on radar, putting this back as resolved:fixed, QA - please confirm ASAP that this has been fixed.
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla0.9.4
I'm using today's branch build 2001-09-10 on windows XP and when I'm in Turbo mode, after exiting the app, I don't have to give a password for my IMAP mail account, but I do have to give passwords for the other 4 mail accounts I have in this profile. So yes, this is not fixed at this time. Also, note 86021 is verified as fixed so this wasn't taken care of by that fix. While in Turbo mode, Launch a profile with 4 mail accounts ( I have IMAP as my default mail account and the checkbox for "check for New mail at startup is checked). The other mail accounts don't have this checked. I also don't have Save Password on any of them. 1. Open each Mail account giving password. 2. Exit the app. 3. Launch App again and go to each mail account. Notice the 1st mail account gets my mail without password. All the others require a password to get in. Re-opening, will check with other windows platforms to see if this is across OS version.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
More testing with Mail passwords and WindowsME. This happens on Windows ME too. Also, I created another new Profile, then added only 2 IMAP accounts. I see this same behavior (I don't have to give password for the 1st account, but do with the 2nd account after a warm launch). Thinking this is tied to the "Default" mail account, I made my 2nd acccount "Default", exited and did another warm lauanch. This time I didn't have to give a password for either account. I added another IMAP account, exited and did a warm launch. All (3) of my mail accounts do NOT require a password. Playing around with the Account Settings seems to change the requirement for a password. I saw an e-mail from Conrad stating " When the last window is closed, the current profile is shut down. This flushes passwords, shuts down mail accounts, logs out of AIM on commercial, persists global history, prefs, localstore, etc. On the next warm launch:". If this bug does not happen in the browser anymore let me know if you want a new bug written up for mail.
Esther, that was the description of how it is *supposed* to work and, last I checked (last week), it did. I'm looking into this.
Having 1 POP account and 1 IMAP account, I didn't have this problem. Making two IMAP accounts, I do see the problem. I made the new account be the default account, set it to check on startup, did a warm boot, started mail, and it asked for the password. I then checked mail for the 2nd account, it didn't ask for the password, so I thought I was seeing this bug. I later noticed that it does not ask for the password of the default account first, but was asking for the 2nd account. That's why when I checked the 2nd account it didn't ask. Something odd *is* going on here though.
Looking at the code where the account mgr gets the notification that the profile is shutting down, there's one suspicious thing when nsMsgAccountManager::Shutdown() gets called. After unloading all accounts, the account mgr still holds one strong ref to an incoming server in m_lastFindServerResult. Incoming servers hold a password. Maybe that's keeping it around? Bhuvan - A few questions about account mgr and friends: (1) Are incoming servers the only thing which may be storing passwords if the user has chosen not to remember them? (2) Is there some reason that an incoming server may not be freed after nsAccountManager::Shutdown()?
(1) Are incoming servers the only thing which may be storing passwords if the user has chosen not to remember them? Looks like smtpServer also stores the password in the cases where user tries to send a message before logging into the account. JFD, can you confirm ? If the user logs in, incomingServer stores it in a member var. (2) Is there some reason that an incoming server may not be freed after nsAccountManager::Shutdown()? We shall shutdown the incomingserver after the shutdown. This is probably happening because of biff..? Do you have biff turned on..? If so, what it is the interval value used there...?
Biff is turned on and the interval is 1 minute on both accounts. Although, in response to nsMsgAccountMgr::Shutdown() being called, nsMsgBiffManager::OnServerUnloaded() gets called 3 times (though I have 2 IMAP servers)
BTW, even with the exact same account info as Esther is using in the two account case and following her procedure, still can't reproduce this. Probably something having to do with timing.
Paul/Sol - If Turbo is in, we should nsbranch+ all related bugs required to meet the requirements for this round.
Keywords: nsbranch
Blocks: 99194
Blocks: 99488
To add more to my scenario. I found that after the intitial installation of the app, I had to toggle the checkbox for Quick Start, then exit the app before I saw this lack of password problem. I haven't checked with today's build, I will do so now and give the additional steps.
I have reproduced this with the 9-15 windows build on WinXP. I will have Ninoschka try it again with WindowsMe. 1. Launch app, create a new Profile 2. Launch Profile, Cancel Activation. 3. Set up 2 or 3 IMAP email accounts using Account Setup. Don't login 4. After the IMAP accounts have been created, select Preferences and check the box to Enable Quick Launch 5. Log into these accounts giving password. 6. Exit App 7. Launch app again using Quick Launch "N" in task bar 8. Go to mail, I am not asked for passwords for all 3 of the IMAP accounts I created. I exit and relaunch several times and am not asked for a password. The test accounts I used are qatest04, 3qatest07, 3qatest08. Conrad you have the password so you can try to reproduce this with these steps.
Ninoschka just reproduced this with WindowsMe.
Esther - was the 9-15 build branch or trunk?
Branch
Esther, following your instructions from 2001-09-14 10:24, and the accounts you gave me, on a debug branch build I just updated, it *does* happen - one one account anyway, not the other. There's some hope of solving this. While I'm debugging that, can you tell me if the procedure reproduces the bug on a current trunk build? I couldn't, but it would be good to have another test on your end.
marking nsbranch+ per PDT triage. Can we please get this bug sorted out for sure? Thanks.
Keywords: nsbranchnsbranch+
0.9.4 is out the door.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Conrad, we're looking to make a decision about Turbo very soon, how's this coming - any hope of getting it fixed soon? Need any help from the Nav Team?
I tried reproducing this many times from a branch debug build but couldnt. I always hit nsMsgAccountManager::Shutdown() from profileshutdown and that clears the passwords. Does it have to do with new accounts ?
We can't just call this WFM based on debug builds on NT. If QA can reproduce it using production builds on WinME and WinXP, then we may have to do that too, resorting to printfs or even just analyzing the code to figure out what is happening. Maybe it happens more on less buff machines? In any case, I'm sure there is a real, serious defect here, and we have to find and fix it before we can enable turbo mode by default for our enterprise customers.
I completely agree. If anybody with XP, ME or whatever can add printfs to a release build, please help by doing so. The first thing to ensure with the printfs is that nsMsgAccountMgr::Shutdown() is being called in response to closing the last window. Then, to ensure that on Shutdown(), that all accounts are in fact destroyed. As far as code analysis, does anybody know where a password may be cached that is not getting cleared by Shutdown()?
Placing "Turbo+" in Status Whiteboard for short list query.
Whiteboard: Turbo+
Bug 99387 was checked into trunk. Esther, can you test tomorrow's trunk build to see if it fixes this as well? The clearing of passwords happens differently in that patch.
See also bug 101263, make it a pref and add "log off PSM" to the context menu of the system tray icon.
I doubt more than a handful of users will have any clue what that means.
doron- since gbush is working on testing turbo, I changed qa contact to her. Pls feel free to change back to you if you wish to own verification of this bug fix when completed.
QA Contact: doronr → gbush
Minusing for branch. This was supposed to be fixed by multi-profile support and profile startup/shutdown in turbo. Since there are problems with that feature, it is being turned off in the branch. See bug 101364. WRT session infomation, we will be back to 6.1 behavior which was to *always* keep session info after closing the last window :-/
Whiteboard: Turbo+ → nsbranch-
correcting the nsbranch- to show on the keyword field.
Keywords: nsbranch+nsbranch-
Whiteboard: nsbranch-
Blake, this seems to indicate that we should go back to the old dialog that the user sees upon closing the last window - i.e the one that informs them that they may still be logged into services. Can we do that on the branch?
It's done. It's in the patch for bug 101364.
-> 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
I am experiencing what Esther observed on 9/10/2001. I have one profile and two mail accounts. When I launch with Quick Launch enabled, no password prompt appears and access to my mail account is active. With Quick Launch disabled, the expected password prompt does appear.
jimmylee, are you using branch or trunk?
Branch
That's to be expected on the branch. Read my comment on this bug from 2001-09-26 12:30 - not far above yours ;-)
Blocks: 107067
Keywords: nsbranch-
Conrad, you going to get to this by mozilla0.9.6? Is this still an issue?
> Conrad, you going to get to this by mozilla0.9.6? I hope to early next week. > Is this still an issue? Can QA test this again? When it was an issue, I couldn't repro it. Test only the case of 1 profile because bug 105177 is crashing profile switching right now.
Tested with Mozilla build 2001103003 (commercial trunk not available yet today- branch does not support multiple profiles) Had a profile with 2 IMAP accounts and 1 POP account. When I launched from icon in tray, I was asked for the passwords for both IMAP accounts as I accessed them. Will add results from trunk testing when a build becomes available
Conrad, I've got logging out of PSM when closing last window in bug 101263, so if you were thinking about fixing that, don't worry about it. ;-)
Mass move to 0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Blocks: 108795
Esther, I could never repro this but need to find some end to this. I'll be looking at it again soon. Could you see whether you can still repro this with current trunk builds?
First, I don't think this is a multiple profile issue, since it looks like the reproduced cases were only single profile, multiple mail accounts. Second, I'm pretty certain this bug was fixed by Conrad's checkin to nsMsgAccountManager.cpp, revision 1.234 done on Sept. 20 20:44, where he made mail forget passwords when we get a "session-logout" notification, which happens when you close the last visible window. It looks like the only reported reproducible cases were before this checkin. Also, I can't reproduce using 2001112903 win32 build on win2k. Unfortunately, I can't find a 09/19/01 build in the nightly directory on ftp.mozilla.org to make absolutely sure. However, like I said above, I think this puppy is fixed (well, the fact that this was reopened for not forgetting mail passwords, that part is fixed ;-) )
I tested on trunk build 2001113003 and got expected behavior for multiple profiles. clicking on icon brought up profile manager and I could change profiles or stay with same, each launch required I give passwords for mail accounts.
Based on Grace's testing, and my own, closing as WFM.
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → WORKSFORME
verified on trunk build 2001113003
Status: RESOLVED → VERIFIED
No longer blocks: 75599
Blocks: 75599
No longer blocks: 99488
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.