42456 - Changes not written to IMAP INBOX at mailnews shutdown if browser still open

Status: NEW

(SeaMonkey :: MailNews: Backend, defect, P3)

Description

[Ben Bucksch (:BenB)]

Reproduce:
1. Use a standalone biff (not Netscape or Mozilla)
2. Send an email to your IMAP account (I use UW-IMAP)
3. Open Mozilla Mailnews (via |-mail|)
4. Read all new msgs
5. Open Navigator via the Task menu
6. Close all Mailnews windows
7. Ask the standalone biff to update
8. Close the browser
9. Ask the standalone biff to update

Actual result:
- After step 7:
  - The biff still notifies about new mail, because it thinks, there were new
    mail (but you already read all)
- After step 9:
  - The biff stops notifying

Expected result:
The biff already stops notifying after step 7.

Additional comments:
Bug 28355 is related (update even after |Get Mail|).

Comment 1

[Scott MacGregor]

i'm not sure if this is a biff issue or an imap flags issue?

re-assigning to gayatri. If it doesn't look  like biff, feel free to bounce this
back to me or bienvenu gayatri. 

Comment 2

[scottputterman]

cc'ing bienvenu.

Before I reassign this back, I just want to know what the biff code could be
doing to cause this so we could investigate.  It seems to me that once we've
downloaded all of the headers and read them in steps 3+4, that the biff visual
code is out of the picture and that we must must not be doing whatever it takes
to let the imap server know that we've downloaded all of the headers.

Comment 3

[scottputterman]

moving to future milestone.

Comment 4

[Ben Bucksch (:BenB)]

*sigh*

This bug is important for interop with other mail clients running against the
same account, including biffs.

Example setup (happens to be mine):
- Browser is open all day (unless it crashes)
- A standalone biff is running in the Taskbar equivalent

- A mail comes in. biff plays animation.
- User selects Tasks|Mail and newsgroups
- User reads mail
- User closes Mailnews (but still has other browser windows open)
- User wants biff to stop. It doesn't.
- User is annoyed
- A new mail comes in
- Since the biff notified all the time although no new mail where there, the
user doesn't know that there is new mail. biff is useless.

Summary: This bug makes operation in the example setup (see above) impossible.
Need to be fixed for release. nsbeta3 nomination.

Comment 5

[Ben Bucksch (:BenB)]

s/where/were

I should note that this setup is quite common, at least under Unix users.

Comment 6

[lchiang]

- per mail triage.  Adding to helpwanted keyword list.

Comment 7

[Ben Bucksch (:BenB)]

I cannot close the browser just to make the biff stopp notifying. I need the
standalone biff. The product is unusable for me with this bug.

I cannot fix it - it is in the networking tier. Please reevaluate.

Comment 8

[Ben Bucksch (:BenB)]

BTW: This bug is propably just a symptom of an arch bug. If I open the browser,
open Mailnews and close (just Mailnews), it should be as if Mailnews were never
started.

Comment 9

[scottputterman]

mail triage marking [nsbeta3-]

Comment 10

[Ben Bucksch (:BenB)]

So, guys, what am I supposed to do? Drop the biff, or what? Or drop Mozilla?

OK, I'll nominate bug 28355, maybe that is easier to implement.

Comment 11

[Ben Bucksch (:BenB)]

Another reason to fix this bug: No other client can write to the folder until
the connection is closed. So, it also harms interop with other mail clients
(e.g. 4.x).

Comment 12

[scottputterman]

sorry for the extra email. Removing mail2 keyword.

Comment 13

[David :Bienvenu]

This may need to be a preference - many people will want biff to be running
after shutting down the last mail/news window (as it has in every Netscape
product since 2.0). Another possibility is when we implement offline, the user
can bonk the offline icon to force the client to close any imap connections,
which should make biff stop.

Also, the UW server, AFAIK, will kick existing imap connections off if a new
connection is attempted - it doesn't lock out new connection attempts, unless
this has changed.

Comment 14

[Ben Bucksch (:BenB)]

bienvenu, can't we make it dependant on the 2 variables you mentioned? I.e. if
either (biff is disabled and all Mailnews windows are closed) or the user
enables "offline", the connections are closed? 

Comment 15

[scottputterman]

marking nsbeta1-

Comment 16

[Håkan Waara]

-> default qa and assignee

Comment 17

[Denis Antrushin]

Attachment: close connections upon last mail window close

Comment 18

[Denis Antrushin]

Does attachment 54335 [details] [diff] [review] makes sense?
I'm not sure of few things:
1. What about biff service in that case
2. Is it better to send offline-status-changed notification to mailnews
   (don't think so)
3. Do I need new preference, or it's possible to reuse some existing prefs...

Comment 19

[Denis Antrushin]

BTW, shouldn't description be changed? This bug not about not writing changes now,
but about closing connectons... ;-)

Comment 20

[Ben Bucksch (:BenB)]

> 1. What about biff service in that case

Maybe close only, if the biff pref is off? OTOH, there might be way more
connections open than biffs needs.

> 3. Do I need new preference

If so, it should be hidden. Unfortunate.

> BTW, shouldn't description be changed? This bug not about not writing changes
> now, but about closing connectons... ;-)

No, since writing out changes was the most important thing. If you don't achieve
that, you didn't fix the bug and should maybe file a different one.


bienvenu, is that in your area?

Comment 21

[Denis Antrushin]

I don't think that changes are not written.
As far as I remember, IMAP spec says that fetching message body implicitly
sets Seen flag. But I don't insist on that statement, let me refresh my
memory first :-)
BTW, what IMAP server you use?

Comment 22

[Ben Bucksch (:BenB)]

> what IMAP server you use?

UW

Comment 23

[David :Bienvenu]

yes, fetching a message marks the message read, but the server doesn't have to
commit that state unless the client asks the server to (by either closing the
connection, or explicitly issuing a check command). And as I mentioned earlier,
the UW server, in certain configurations, will drop the first connection, and
all its state, if a second connection is made to the same folder.

Comment 24

[Denis Antrushin]

I tested UW server with another mail client and its behaviour is the same.
I used gbuffy biff client. The problem is that biff client checks mailbox
with STATUS INBOX (MESSAGES RECENT) command (w/o selecting inbox).
RECENT flag cannot be changes by client; it not changed by server during the
session either (until CHECK or CLOSE). But IMAP spec says that "A checkpoint
MAY take a non-instantaneous amount of real time to complete." I don't think
that sending CHECK command every time is a good idea.So the best we can do
is to close all connection upon closing last messenger window (based on user
preference).

Comment 25

[Ben Bucksch (:BenB)]

If CHECK (or CLOSE?) is the only way to reliably write out the changes, then you
must do that (to fix this bug). *shrug* - Or did I misunderstand something?

Comment 26

[Denis Antrushin]

My patch closes all connections (so CLOSE command sent to server and external
biff notised the changes).
May be someone from mailnews team can add few words here?
(Is it okay to CHECK everytime, or just close connection, wharever)
On the other hands, this bug may be covered by bug 95130 (Mailnews stays in RAM
after being closed) - if you unload mailnews, you probably don't want to keep
open connections, except for biff service, buf biff doesn't need to SELECT
inbox....

Comment 27

[David :Bienvenu]

It's not OK to "CHECK everytime", if you mean whenever we do anything with the
server, issue a check command, because that will hurt server performance. Our
biff service does keep the inbox in the selected state, so we cannot keep biff
working after closing the inbox.

Comment 28

[Denis Antrushin]

Okay, "close connections upon closing last mail window, if user wants so" then?
What about patch in that case? :-)

Comment 29

[Ben Bucksch (:BenB)]

> It's not OK to "CHECK everytime", if you mean whenever we do anything with the
> server, issue a check command,


No, I meant "issue CHECK whenever the last Mailnews window has been closed".
(Assuming that CHECK is the only reliable way to write out changes.)
I don't think we need a pref for that, unless it's a noticable perf hit.

Comment 30

[Denis Antrushin]

Please remove 'patch' from keyword - it's need to be reworked

Comment 31

[Denis Antrushin]

Looking at this bug now, I'd add commitState to nsIInconingServer and
upon closing last window either close connection to server if user don't
want biff it or call this method if user wants biff.
commitState will do nothig for all servers except IMAP one, for which
it should issue CHECK command...

Comment 32

[Ben Bucksch (:BenB)]

Not limited the UW IMAP, I think.

Comment 33

[Ben Galbraith]

I'm surprised this had only one vote before I cast mine. Everytime I shutdown
Win2k, if I haven't remembered to close Mozilla first, I lose all changes to my
inbox, as this bug's summary aptly describes.

I appreciate any work towards fixing this bug and am willing to help in any way
I can with testing -- I use Mozilla 1.1 on RedHat 7.3, Win2k, and OS X 10.1.

Comment 34

[David :Bienvenu]

if we're not closing the imap connections when you shut down win2K with mozilla
open, that means that mozilla is not handling the request for app shutdown
correctly when win2K is shut down. It should be just like the normal app close
as far as the imap code is concerned - we should get a shutdown notification, at
which point we will close our imap connection(s).

There is a known problem if you shut down mozilla with Ctrl C on linux - Mozilla
doesn't catch that and tell the imap code to shut down cleanly, but that's a
different problem.

Comment 35

[Ere Maijala (slow)]

There is nowadays code to do a periodical checkpoint, maybe it helps this at
least a bit, although I've also seen recent changes getting lost when shutting
down Windows.

Comment 36

[Ryan Grove]

OS should probably be changed to "All", since I see this on Win2K with build
2003031304. In addition to read messages being marked unread again, deleted and
moved messages that weren't purged seem to reappear in the Inbox.

Comment 37

[Jason M. Abels]

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

Comment 38

[Jason M. Abels]

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

Comment 39

[Jason M. Abels]

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

Comment 40

[Jason M. Abels]

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

Comment 41

[Jason M. Abels]

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

Comment 42

[Jason M. Abels]

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

Comment 43

[Jason M. Abels]

Changed Summary from:
Changes not written to IMAP INBOX at shutdown if browser still open
to:
Changes not written to IMAP INBOX at mailnews shutdown if browser still open
because mailnews stays in RAM

Comment 44

[David :Bienvenu]

this is a suite bug only now, I'd say, first of all.

standalone biff was a separate application in 4.x that checked a user's accounts for new mail.

The issue, as I remember, is simply that closing the last mailnews window when you had both browser and mail windows open, didn't shutdown the mail connections, thus telling the imap server to flush its state.

Comment 45

[Wayne Mery (:wsmwk)]

OK, but does standalone biff (a separate application) even exist anymore either in reality or on some SM suite plan?
If not in reality, then this shouldn't this be marked as an enhancement request?

Comment 46

[Wayne Mery (:wsmwk)]

Is the following an accurate summary of what is requested?
...
  "add preference option to cleanly terminate all mailnews / imap 
  operations at closing of last mailnews-related window and browser still open"

Comment 47

[Ben Bucksch (:BenB)]

No. Comment 8 describes it accurately. Thunderbird delivers that, but seamonkey users would still suffer from it. This severely hampers using 2 IMAP clients (on different machines or just any "new mail" check tool), and leads to uncommited changes when the client crashes or is killed.

Comment 48

[Ben Bucksch (:BenB)]

> does standalone biff (a separate application) even exist anymore

Yes, there are countless biffs out there, in GNOME, KDE, even my wireless phone can notify me about new email in account. All these keep notifying until a flush happens.

Comment 49

[Wayne Mery (:wsmwk)]

I don't see the distinction you are trying to make in comparison to comment 8.  

Are you asking for the connection / mailnews to stay alive but something needs to be flushed (comment 44)?  Comment 8 doesn't state nor imply that.

Comment 50

[Ben Bucksch (:BenB)]

No. When all mail windows are closed, all connections (that these windows used) should be flushed and closed.