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)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
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 ago → 23 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: nsbranch → nsbranch+
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 ago → 23 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.