351565 - Existence of movemail account prevents all accounts from being synced for offline use

Status: RESOLVED WONTFIX

(MailNews Core :: Movemail, defect)

Description

[Till Dörges]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.0.6) Gecko/20060728 SUSE/1.5.0.6-1.4 Firefox/1.5.0.6
Build Identifier: Thunderbird version 1.5.0.5 (20060725)

I have several accounts (IMAP/POP3) configured in TB.

Usually File->Offline->Work Offline->Download works fine.

If I add a movemail account syncing doesn't work any more.

Reproducible: Always

Steps to Reproduce:
1. add a movemail account
2. try to download messages for offline use


Actual Results:  
Nothing, except for a quick message rushing through the status bar (something like "no new messages are on the server").

Expected Results:  
Normal download of all messages in all folders marked for offline use.

Comment 1

[J. Scott Berg]

A big 'ol me too.  I was wondering why my messages weren't being downloaded.  Saw this bug report, removed the movemail account, and voila, the download/sync menu item actually downloads everything.

A couple of observations from when the movemail account was there: if you go to the properties on the individual folder, select the Offline tab, and click the Downlad now button, it will actually synchronize.  Second, the problem seemed to be with messages that were moved into IMAP folders; the act of reading the message in the folder seemed to be enough to make the synchronization happen.

Comment 2

[Morgan Read]

Yup; Me TOO!
As above, complete ditto
Now I know how to get my mail locally; but, now I can't get my logs...
Weird, why would these two components be mucking with each other?

Comment 3

[Morgan Read]

Hmm, is there an explanation why the person this bug is assigned to is being excluded from receiving mail on this bug...?  Perhaps it needs re-assigning?

Comment 4

[Phil Ringnalda (:philor)]

Here you go, current default assignee and QA contact instead of the defaults from a year ago; just like having a leprechaun grant you a wish, isn't it?

Comment 5

[Morgan Read]

I suspected I was likely to get more than I bargained for...:)

Comment 6

[Wayne Mery (:wsmwk)]

how is this related to bug 350380?

Comment 8

[Magnus Melin [:mkmelin] (away, back June 30)]

Maybe this has a similar cause as bug 278383...

Comment 9

[Wayne Mery (:wsmwk)]

seems overdue for confirming

Comment 10

[Joshua Cranmer [:jcranmer]]

Reconfirmed on Linux trunk, 3.0b1pre.

If you select Work Offline and then (attempt to) download messages before going offline, it doesn't actually go offline although the indicator seems to indicate that is offline.

Bumping up to major.

Comment 11

[Joshua Cranmer [:jcranmer]]

Oh, that's why it fails. Since movemail downloads synchronously, it doesn't bother with the URL listeners, which is how the offline manager decides to move to the next account. The simplest fix would be to construct a URI and use the listener stuff. Some clients may not like the url listener being used before GetNewMail is called, but such is life.

Comment 12

[Joshua Cranmer [:jcranmer]]

Attachment: Patch, version 1

This allows nsMsgOfflineManager to go offline with movemail. It should probably be noted somewhere that some callers depend on GetNewMail using nsIURLListeners to work properly.

Another option I did not explore would be to make the offline manager not download inherently offline protocols.

Comment 13

[David :Bienvenu]

Comment on attachment 389409 [details] [diff] [review]
Patch, version 1

why not poke aUrlListener directly? aUrlListener->OnStartRunningUrl(nsnull), aUrlListener->OnStopRunningUrl(nsnull, rv);

Comment 14

[David :Bienvenu]

Comment on attachment 389409 [details] [diff] [review]
Patch, version 1

marking obsolete since jcranmer's going to try my suggestion.

Comment 15

[Joshua Cranmer [:jcranmer]]

Attachment: Patch, version 2

Updated patch, using bienvenu's suggestion.

Comment 16

[David :Bienvenu]

Comment on attachment 390649 [details] [diff] [review]
Patch, version 2

sr=me, with one nit:

@@ -382,6 +383,7 @@ nsMovemailService::GetNewMail(nsIMsgWind
                               nsIURI ** aURL)
 {
   LOG(("nsMovemailService::GetNewMail"));
+  NS_ENSURE_ARG_POINTER(aURL);

you can lose that change - we allow callers to pass null in if they don't care about the resulting url, and we don't assign it if null. (In this case, we never assign it, actually).

Comment 17

[Joshua Cranmer [:jcranmer]]

Pushed as changeset 3200:484c394ba889, with bienvenu's nit.

Comment 18

[Karsten Düsterloh]

This now utterly crashes almost any profile with a Movemail account when getting new mails by biff or manually.

I wonder under which circumstances I tested this patch that I didn't crash... :-(

1. Startup with "Check on startup": see bug 507721
2. Even with NS_ENSURE_ARG_POINTER(aURL), you can't get new mails for Movemail:

An error occurred executing the cmd_getNewMessages command
[Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIMsgIncomingServer.getNewMessages]"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: chrome://messenger/content/mailCommands.js :: GetNewMessages :: line 56"  data: no]


Backing out as <http://hg.mozilla.org/comm-central/rev/ffc4730d6619>.

Comment 20

[Thommie Rother]

no activity for a long time, should be closed

Comment 21

[Mark Banner (:standard8)]

(In reply to comment #20)
> no activity for a long time, should be closed

No, there was a valid bug, that we don't know if it has been fixed or not, and there's a patch that was started but needs revisiting.

Comment 22

[Joshua Cranmer [:jcranmer]]

 (In reply to comment #20)
> no activity for a long time, should be closed

Nope, the bug still exists. Just because I haven't touched it for 1.5 years doesn't mean it isn't a bug anymore

Comment 23

[Morgan Read]

Re Comment 22:

I've been using 'Server Type: Unix Movemail' successfully for a long time now.

So, 'worksforme'

So, imho, should be closed fixed

Comment 24

[Wayne Mery (:wsmwk)]

Support for Movemail has been removed as of version 87 per Bug 1625741