60953 - [RFE] Messages shouldn't be automatically downloaded when mailer window is closed

Status: NEW

(SeaMonkey :: MailNews: Backend, enhancement)

Description

[Koike Kazuhiko]

Messages shouldn't be automatically downloaded from pop server
when mailer window is closed.

(1) Launch navigator and mailer.
(2) Open Account Setting dialog and check "Check for new messages" and
"Automatically download".
(3) Close mailer window. New messages are downloaded automatically.

Somebody may think this is a convenient feature, but I don't need it.

Comment 1

[David Hallowell]

Personally I think this is the correct behaviour, if you want the messages to be
downloaded immediately it may as well also download the messages when the mail
window is closed so that when you next open mail the messages are already there.

Comment 2

[Max Alekseyev]

*** Bug 210008 has been marked as a duplicate of this bug. ***

Comment 3

[Max Alekseyev]

Hardware/OS -> All/All

Comment 4

[Maarten Brouwers]

Shouldn't there be at least a option for disabeling this... a case example:

During breakfast I turn on my computer, for checking my e-mail, browsing some
news-sites etc., after wich I head for work/school. During my time at work or at
school, my computer still runs, acts as a server, and helps finding a solution
for cancer... 

At work or at school, I always want to have the ability to download my personal
e-mail, and so I've configured my programs there to do so... but when I've left
my computer on, running mozilla all the time... most of my e-mails are
downloaded already before I've had the chance to read them at school/work.

I find it rather irritating. Of course one could work around by leaving the
messages on the server, or not to download the messages at all, but's not the
preferred option. That's why a switch should be there, imho.

Comment 5

[Age Bosma]

It's not just about the automatic downloading of the e-mails, if you launch your
browser window it doesn't check for e-mails, only when you opened the mail
client once and close it again while keeping the browser windows open it checks
for e-mails on the set time. Imho this is a bug because a piece of software does
something unexpected only when you did something unknown (at fist sight).
If a "feature" like this should be included atleast be consisted and check for
e-mails as soon as the browser windows get's opened as well. Not only when the
mail client has been opened once. Also include an option for people to
enable/disable it and I'm also of the opinion this should be disabled by default
(as for checking/downloading e-mails while the mail client is closed that is).

Comment 6

[Charles Fenwick]

*** Bug 221340 has been marked as a duplicate of this bug. ***

Comment 7

[Doug Hockin]

From my original report that was a duplicate of this bug:

Before about version 1.4, if there was browser windows open, but no mail window
open, the mail was not periodically fetched.  I fetch mail from work
and home from the same mail account.   I liked to leave browswer windows
open at work, but close the mail window so my work computer stopped
fetching mail and I could get it from home.  Now, the only way to
accomplish this is disable mail fetching in the Preferences before I
got home.

My hoped for "solution" to this problem didn't work.  I tryed
turning off mail fetching in Preferences, but low-and-behold,
it kept fetching mail anyway.  My guess is the new setting
won't take effect until I restart the browser.  I think this
also used to work -- i.e., the new setting used to take effect
immediately, but I'm not sure.

Comment 8

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 9

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 10

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 11

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 12

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 13

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 14

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420

Comment 15

[Karsten Düsterloh]

We took pains to even make mail fetching work *before* opening the mail window, including a pref to not do that, so this bug is actually the other edge case:
How do we get the mail libraries to unload immediately after closing the windows...