Closed Bug 501288 Opened 15 years ago Closed 3 years ago

mail folder opened on startup because of session restore, causes prompts for password

Categories

(Thunderbird :: Mail Window Front End, defect)

defect
Not set
normal

Tracking

(blocking-thunderbird3.1 -)

RESOLVED DUPLICATE of bug 506526
Tracking Status
blocking-thunderbird3.1 --- -

People

(Reporter: jugg, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug, )

Details

(Keywords: regression, Whiteboard: [gs])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090629 Lightning/1.0pre Shredder/3.0b3pre

When opening thunderbird/shredder the folder that was open last when closing thunderbird is restored/given focus.  Because of this, thunderbird tries to connect to the server.

I have thunderbird configured to *not* auto check for new mail on start, and I do not use the password manager - ie I always manually type my password in.

With this new behavior of restoring the last folder on startup, it causes thunderbird connect to the server and  to prompt me for a password when I open thunderbird.  I do not want this as it causes usability problems in my work flow.  This is a change in the last week or two and it'd be great if the previous functionality could be restored.

Reproducible: Always

Steps to Reproduce:
1. Select a folder in an imap account
2. Close thunderbird
3. Open thunderbird
4. Thunderbird restores previously selected folder and attempts to connect to the server.
5. If not using the password manager, you are prompted for a password.
Actual Results:  
Thunderbird restores previously selected mail folder on startup and connects to the server.

Expected Results:  
Thunderbird should display the account summary page of the last selected account on startup.

This only started in the last week or so.  Prior to that the "Expected Results" was the existing behavior.
Flags: blocking-thunderbird3?
Keywords: regression
Sounds like this is bug 501212 comment #6.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Flags: blocking-thunderbird3?
Resolution: --- → DUPLICATE
(In reply to comment #1)
> Sounds like this is bug 501212 comment #6.

No it isn't. This specifically says if you are not using the password manager. This is an issue that the tab restore has given us.
Status: RESOLVED → UNCONFIRMED
Flags: blocking-thunderbird3?
Resolution: DUPLICATE → ---
Sounds like the user wants to turn off tab session restore. Is there a pref for that?
(In reply to comment #3)
> Sounds like the user wants to turn off tab session restore. Is there a pref for
> that?

No.  There probably should be, though.  Since we're basically at string freeze, we could do the dubious thing of using another pref as a proxy for that desire right now.  For example, if they have disabled checking for new mail...
I wouldn't mind having access to tab session restore (to keep the calendar tab open), but am happy to trade that for getting rid of the password prompt for now.
We could make mail tabs not restore themselves if they would trigger an onload.  Which is basically all of them.  But it introduces an edge case relating to the first "folder" tab.
To me the real core problem here is the password prompt.  Turning off session restore or altering it in some way seems like it would fix the symptom but take away a good feature at the same time.
if the user doesn't save passwords, we're going to need to prompt for the password before running imap urls and showing the contents of imap folders, unless it's ok to show stale folder contents. I think for most users showing stale contents would be a bit confusing.

It sounds like the user wants a pref that says, don't persist/restore tabs that would cause a password prompt on restart in order to show those tabs. Or a pref that says I'd rather see stale contents than a password prompt, but I wouldn't default to that...
(In reply to comment #8)
> if the user doesn't save passwords, we're going to need to prompt for the
> password before running imap urls and showing the contents of imap folders,
> unless it's ok to show stale folder contents. I think for most users showing
> stale contents would be a bit confusing.

I think that's likely to sometimes be true and sometimes not.  For users who have already set the various prefs to indicate that they never want Thunderbird autochecking mail folders without them first doing an explicit "Get Mail" (I'm one of those users), breaking the invariant of "clicking on a folder implies SELECT" doesn't strike me as problem.

> It sounds like the user wants a pref that says, don't persist/restore tabs that
> would cause a password prompt on restart in order to show those tabs. Or a pref
> that says I'd rather see stale contents than a password prompt, but I wouldn't
> default to that...

Do we actually need a separate pref here?  If we decide this is the right behavior, couldn't we figure out when to do it based on some combination of the existing prefs?
(In reply to comment #9)

> I think that's likely to sometimes be true and sometimes not.  For users who
> have already set the various prefs to indicate that they never want Thunderbird
> autochecking mail folders without them first doing an explicit "Get Mail" (I'm
> one of those users), breaking the invariant of "clicking on a folder implies
> SELECT" doesn't strike me as problem.

That's a POP3 way of doing things. It makes less sense in IMAP. With IMAP, we do a lot more than just get new messages - we sync the folder with the server state for the folder, so messages you've read/deleted/tagged from an other machine/client are updated on the current machine. I suppose we could change the Get Mail button to "Sync with Server" :-)
My supposition was that most users who set their prefs to never auto-get mail understand the underlying model, but the more I think it about, the more I bet that's not actually true.  I think you're onto something here: we probably need to figure out how to tweak our UX design in such a way that it better reflects the underlying model(s) without requiring the users to have a complete picture of those models in their heads.
My use case is this:

I have thunderbird set to not check mail at startup - I just want to get the application open without a bunch of password prompts. I have all of my accounts set to auto check for new mail on intervals (just not at startup).

Then depending on which account I'm interested in checking (sometimes I'm in a hurry and only need to check one account), I select that account's inbox and enter the requested password.  Or maybe I only need to check my calendar and not my mail accounts.

This worked great in the past.  Now, with the tab session restore, whether or not I have that account set to check for new mail on startup, it does anyway.  That is broken.

Regarding showing cached folder contents instead of connecting to the server - sure why not... it doesn't matter if the index is stale or not... as soon as you try to read a message you'll connect to the server and the index will be brought into line with reality.  That isn't a perfect solution, but it doesn't seem to cause any problems either.

1. short term fix options:
* Show account summary page for all tabs when account is not configured to check for new mail on startup - when clicking on "Read Messages" from that page, it takes you to the folder that the tab was supposed to restore.
* Disable loading tabs for any account that is not configured to check for new messages on startup.
* Disable tab restore across the board until this can be fixed correctly.

2. long term fix:
* Option to use tab restore or not
* New placeholder page that is shown in place of folder index that has "Read Messages" or "Synchronize with Server" or "Connect to Server" or some such that is used when the account is not configured to check for new mail on startup.
* Make tab restore manually customizable, so regardless of what state the application was left in at shutdown, the configured state is restored every time on start.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: General → Security
QA Contact: general → thunderbird
Version: unspecified → Trunk
Since this is a regression, and since the failure mode is pretty irritating (ie in the face of the user every time they start up), I think we probably do need to block on this.

Targetting at b4, since there may be UX implications here.  clarkbw, I'd be interested to hear your thoughts about my hypothesis in comment 11...
Component: Security → Mail Window Front End
Flags: blocking-thunderbird3? → blocking-thunderbird3+
QA Contact: thunderbird → front-end
Target Milestone: --- → Thunderbird 3.0b4
i'm guessing that code-wise it probably isn't best to special case the situation of folder restore.  A special case for folder restore to not trigger the check account (like what happens when you click a folder) I assume would solve the problem presented in the use case.

I like chris' solution of just focusing the account central pages on tab restore of accounts that not supposed to be checked on startup.  However I think that will have implications we don't want to deal with.  If you had multiple folders in the same account open they would all go to the account centrall... Also I don't think people would readily understand why we didn't restore things "correctly".

I'm not sure how to move forward on this.  Changing the behavior of tab restore because of an option on accounts doesn't seem like the best route.  Turning off tab restore seems like curing the function by killing it.  I feel like I'm waiting on technical options to decide what is feasible.
I am having a similar password prompt issue.  Ever since I upgraded to a newer Shredder nightly (I believe it was the build I quoted below, however it may have been 03-Jul), every time I start the program I am prompted for my master password.  None of my server settings for any of my accounts are set to check for new mail automatically in any way whatsoever -- not upon program start, not at intervals -- all of those options have always remained unchecked.  There are several accounts where I am storing their passwords, but the behavior has always been to prompt me for the master password when I initiate "Get Mail", never at program startup.

All of my accounts are POP.  Also, a subfolder under Local Folders is selected with no other tabs open, so Shredder isn't even "seeing" an account folder at startup.  This is happening to me in both Windows XP and Linux.

This is the closest thing I could find to my issue when I searched, closer than Bug 501212.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1pre) Gecko/20090704 Shredder/3.0b3pre
To add to the mix, I've set up my default account (Gmail IMAP) to check for new mail on startup. Before session restore, the Inbox of that account was selected and I was prompted (once!) for the password. Now, if I closed Thunderbird in a different folder of the same account, session restore will bring me back to that folder, prompt me once for the password - then, yet again, this time for the Inbox to get the new mail on startup (I'm not using saved passwords).

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3

(In reply to comment #4)
> (In reply to comment #3)
> > Sounds like the user wants to turn off tab session restore. Is there a pref for
> > that?
> 
> No.  There probably should be, though.

It would be good to have some way to influence the startup behavior beyond the password issue. Think of it as the equivalent to a browser's home page. You may want to start with your previous tabs restored, or with a given set of tabs.
In this case, I'd simply like to get to the Inbox of my default account for new mail, regardless of where I've been before closing Thunderbird.
OS: Windows XP → All
Hardware: x86 → All
(In reply to comment #16)
> To add to the mix, I've set up my default account (Gmail IMAP) to check for new
> mail on startup. Before session restore, the Inbox of that account was selected
> and I was prompted (once!) for the password. Now, if I closed Thunderbird in a
> different folder of the same account, session restore will bring me back to
> that folder, prompt me once for the password - then, yet again, this time for
> the Inbox to get the new mail on startup (I'm not using saved passwords).

This part would be fixed by bug 338549 which is a blocker.
Depends on: 338549
Probably a duplicate of bug 475053?
(In reply to comment #18)
> Probably a duplicate of bug 475053?

Ah, sorry, looks like it is not.
Filed bug 506526 about a pref to turn of session restore. (Not that it would solve this bug.)
The Thunderbird drivers wish to release Thunderbird 3 as soon as possible. As a result, we feel that this bug shouldn't stand in the way of all the other good work getting into the hands of users sooner rather than later. Therefore we are retargeting it for 3.1. See http://ccgi.standard8.plus.com/blog/archives/242 for more details. The 3.1 release is expected to be a quick release soon after Thunderbird 3.
Flags: blocking-thunderbird3+ → blocking-thunderbird3-
Target Milestone: Thunderbird 3.0b4 → ---
Flags: blocking-thunderbird3.1+
"Therefore we are looking at shipping Thunderbird 3 as soon as possible. This will mean that we won’t have time to fit everything into Thunderbird 3 that we would like to get in."

That approach does not make any sense.  You are pushing buggy software out the door.

This bug is part of a new feature you've put into TB3.  Therefore, cut the feature until it is fixed. ie, remove/disable session restore until it works correctly.  Don't ship it with it enabled and broken.

Please return this to be blocking TB3, it is a royal pain to use TB3 every day with this broken - I've only done so to be able to help keep testing the builds.
Given that our main priority for Tb3.1 is to provide a softer landing pad for Tb2 users to upgrade to, and this is a regression of sorts, this might want to block, but I'm on the fence.  clarkbw, what do you think?
blocking-thunderbird3.1: --- → ?
Flags: blocking-thunderbird3.1+
Flags: wanted-thunderbird+
Whiteboard: [needs input clarkbw]
It feels like this bug can't block as we don't have a clear solution but multiple issues wrapped up into one experience.

a) I feel like we could block on bug 527434 which helps when closing Thunderbird with tabs such that chris could close all tabs while closing Thunderbird and thus not have any restored.

b) Or we could block on bug 506526 for a hidden preference to session restore.

I would rather do a) because it's on our priority of items to finish and is more forward looking than the hidden pref.
Whiteboard: [needs input clarkbw]
clarkbw: a) sounds better to me to.  The more I think about it, the less I'm convinced that that really wants to block, since it doesn't seem like it meets the criteria of "making the upgrade experience from Tb2 very painful for a large number of users."  For now, I'll mark this bug blocking-, that bug wanted+, and if you're convinced that it does meet that criteria, I'd encourage you to mark it blocking directly.
blocking-thunderbird3.1: ? → -
a) is not a valid nor usable solution.

First, the last tab can not be closed, and if it has a folder view open, then this issue will manifest anyway when TB is reopened.

Second, I dislike dialogs asking to confirm an action I've taken.  I intend the action I take... accept when I don't; in which case I quickly learn.  So, I always disable those confirmations.  Besides, all that this suggested solution is meant to do is to train a person to close the tabs and deselect any folders prior to closing TB.  That isn't a fix.  And imagine what, that would already be a process I've taken to work around this issue.  So no need to block the next release on bug 527434 on my account, as I wouldn't want that implemented anyway. :)

Actually, closing all tabs and deselecting folders before closing TB was the first work around I took.  Not anymore.  Now I simply have TB configured to start up offline instead.  Various tabs can be open, folders selected and yay, no dialog prompts until I go online.

Of course, with that work around, whether or not an account *is* configured to connect at start-up is no longer relevant, unfortunately.  This probably belongs in another bug report but... I would expect that any account that is configured to connect at start-up, should also connect when going from offline to online - which isn't currently the case.  In fact, accounts don't even start checking for new content at the configured interval when switching from offline to online.  Those along with a whole other slew of usability bugs with starting offline...

Basically the apparent view point (attitude?) that seems to exist in regards to all of this and several other somewhat related bug reports is that if you use TB, then you should store your passwords using the password manager and probably not use the master password mechanism if you want a "convenient" TB experience.  You can have a slightly more crippled usability experience (but more secure) if you use the master password, but really, don't even bother using TB if you don't want to store your passwords.
Whiteboard: [gs]
Depends on: 506526
See Also: → 546553

(In reply to Bryan Clark (DevTools PM) [:clarkbw] from comment #24)

It feels like this bug can't block as we don't have a clear solution but
multiple issues wrapped up into one experience.

a) I feel like we could block on bug 527434 which helps when closing
Thunderbird with tabs such that chris could close all tabs while closing
Thunderbird and thus not have any restored.

b) Or we could block on bug 506526 for a hidden preference to session
restore.

I would rather do a) because it's on our priority of items to finish and is
more forward looking than the hidden pref.

a) was wontfixed, so let's dup to the solution for b)

Status: NEW → RESOLVED
Closed: 15 years ago3 years ago
Resolution: --- → DUPLICATE
Summary: mail folder opened on startup - prompts for password → mail folder opened on startup because of session restore, causes prompts for password
You need to log in before you can comment on or make changes to this bug.