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)
SeaMonkey
UI Design
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.
Assignee | ||
Comment 7•23 years ago
|
||
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
Assignee | ||
Comment 8•23 years ago
|
||
BTW, I'll leave this open for now. It's not a dup and it's certainly valid.
Comment 9•23 years ago
|
||
Fixed, right?
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 10•23 years ago
|
||
Yes - with single or multiple profiles. Can somebody else verify?
Comment 11•23 years ago
|
||
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 → ---
Comment 12•23 years ago
|
||
What does that have to do with this bug?
Comment 13•23 years ago
|
||
*** Bug 98330 has been marked as a duplicate of this bug. ***
Comment 14•23 years ago
|
||
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
Comment 15•23 years ago
|
||
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 → ---
Comment 16•23 years ago
|
||
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.
Assignee | ||
Comment 17•23 years ago
|
||
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.
Assignee | ||
Comment 18•23 years ago
|
||
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.
Assignee | ||
Comment 19•23 years ago
|
||
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()?
Comment 20•23 years ago
|
||
(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...?
Assignee | ||
Comment 21•23 years ago
|
||
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)
Assignee | ||
Comment 22•23 years ago
|
||
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.
Comment 23•23 years ago
|
||
Paul/Sol - If Turbo is in, we should nsbranch+ all related bugs required to
meet the requirements for this round.
Keywords: nsbranch
Comment 24•23 years ago
|
||
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.
Comment 25•23 years ago
|
||
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.
Comment 26•23 years ago
|
||
Ninoschka just reproduced this with WindowsMe.
Assignee | ||
Comment 27•23 years ago
|
||
Esther - was the 9-15 build branch or trunk?
Comment 28•23 years ago
|
||
Branch
Assignee | ||
Comment 29•23 years ago
|
||
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.
Comment 30•23 years ago
|
||
marking nsbranch+ per PDT triage. Can we please get this bug sorted out for
sure? Thanks.
Comment 32•23 years ago
|
||
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?
Comment 33•23 years ago
|
||
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 ?
Comment 34•23 years ago
|
||
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.
Assignee | ||
Comment 35•23 years ago
|
||
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()?
Comment 36•23 years ago
|
||
Placing "Turbo+" in Status Whiteboard for short list query.
Whiteboard: Turbo+
Assignee | ||
Comment 37•23 years ago
|
||
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.
Comment 38•23 years ago
|
||
See also bug 101263, make it a pref and add "log off PSM" to the context menu
of the system tray icon.
Comment 39•23 years ago
|
||
I doubt more than a handful of users will have any clue what that means.
Comment 40•23 years ago
|
||
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
Assignee | ||
Comment 41•23 years ago
|
||
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-
Comment 42•23 years ago
|
||
correcting the nsbranch- to show on the keyword field.
Comment 43•23 years ago
|
||
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?
Assignee | ||
Comment 44•23 years ago
|
||
It's done. It's in the patch for bug 101364.
Comment 46•23 years ago
|
||
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.
Assignee | ||
Comment 47•23 years ago
|
||
jimmylee, are you using branch or trunk?
Comment 48•23 years ago
|
||
Branch
Assignee | ||
Comment 49•23 years ago
|
||
That's to be expected on the branch. Read my comment on this bug from 2001-09-26
12:30 - not far above yours ;-)
Comment 50•23 years ago
|
||
Conrad, you going to get to this by mozilla0.9.6? Is this still an issue?
Assignee | ||
Comment 51•23 years ago
|
||
> 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.
Comment 52•23 years ago
|
||
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
Comment 53•23 years ago
|
||
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. ;-)
Assignee | ||
Comment 55•23 years ago
|
||
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?
Comment 56•23 years ago
|
||
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 ;-) )
Comment 57•23 years ago
|
||
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.
Assignee | ||
Comment 58•23 years ago
|
||
Based on Grace's testing, and my own, closing as WFM.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•