Comment 86 for bug 603402

(In reply to alister.hood from comment #50)>
> but I see the same thing (going offline does not work, I have to restart) in "standard" Seamonkey, (snip)

IIUC, there is no difference between SeMonkey and Thunderbird, as for phenomeon of this bug.

(a) As repeatedly written, after go Work Offline the go back Work Online, explicit folder open by new folder click is mandtory to force server access again. When did go Work Offline the go back Work Online, did youa ctually do it?
      - If Inbox is already selected at folder pane when "go back Work Online" is executed,
          click account then click Inbox again at folder pane.
(b) As repearedly written, Gmail IMAP started to enable CONDSTORE and Tb's CONDSTORE support is enaabled by default.
      When CONDSTORe is used, Tb may not use "uid fetch 1:* flags" or "uid fetch 1:* flags CHANGEDSINCE nnnn".
      Tb may use "uid fetch <HighestUID>:* flags" or "uid fetch <HighestUID>:* flags CHANGEDSINCE nnnn".
      As repearedly written, to force "uid fetch 1:* flags" always in recovery operation for this bug,
      disbaling Tb's CONDSTORE support is needed for problem determination.
      Did you properly disabled Tb's CONDSTORE support?
      Read thru Bug 912216 and bug 885220, al repeatedly written.

Further, get IMAP log and check imap level flow by yourself, before adding comment like "annoying ..." which will never help activity for resolving problem.
Problem of this bug is pretty simple.
1. To know flag state change of already fetched mail of UID=NN<CurrentlyHighestUID, one of next is needed.
    1-1. flag staae change notification for the UID=NN from server via unsol response to lIDLE for selected Mbox.
            => Tb expects it, but maany IMAP servers including Gmail IMAP won't do this.
    1-2. uid fetch NN flags at connection where the Mbox is selected.
            => Tb uses "uid fetch CurrentlyKnownHighestUID:* flags" for new maail check of already selected Mbox.
                  So, flag state change of UID=NN can not be known untill "uid fetch 1:* flags" is issued again for the Mbox.
2. Recovery operation stated in this bug is simply "a procedure to try to force uid fetch 1:* flags".
    2-a. Unless you explicitly click Mbox, connection with server for the Mox won't be opened immediately.
            Without connection with imap server, any "uid fetch ..." won't be issued for the mbox by Tb.
    2-b. Even when connection for the Mbox is established and the Mbox is selected at connection,
             Tb may not issue uid fetch 1:* flags". Tb may use "uid fetch HighestUID:* flags ...".
             Even if "uid fetch 1:* ..." is used by Tb, it may be "uid fetch 1:* CHANGEDSINCE nnnn"
             where nnnn is too large(may be newer than MODSEQ for flag change of UID=NN).