This is the same issue as with the empty trash and empty spam folders 
- we would have to do in-depth parsing of the URL to enable us to 
return to the same page.  i.e. we can't just say return to 
'message.php' since message.php requires certain parameters.  same 
with 'mailbox.php' since the mailbox may have changed in the session 
in the meantime.  or what if we are currently in a page that can only 
be reached through a previous POST/GET - there is no way to return 
this page.  Thus, we pick a sensible default that will always work as 
expected rather than a separate method that can never be guaranteed to 
work all of the time.

Maybe.  At the time I generated the ticket, the behavior was as I had 
noted.  At some point since then and when Michael added his notes, the 
behavior changed and most of the items are gone.



However, I have one issue with the fix commited to imp/fetchmail.php 
for the mailbox that you are returned to.  I would expect to be 
returned to the same page display that I invoked Fetch Mail from.  But 
regardless of that, I'm returned to 'lmailbox', which, as I read the 
code, is the folder value for the first fetch mail account.



Example of how I have my home setup configured:



Three fetchmail accounts, A, B, and C.



A downloads to Folder A

B downloads to INBOX

C downloads to Folder C



Fetchmail invoked as a maintenance task on initial login drops me into 
my INBOX (expected behavior).



Fetchmail invoked manually drops me into Folder A, no matter where I 
was before.  While that is a predictable behavior (no matter where you 
are, you always end up in Folder A), I'd much favor the behavior of 
where you were before you invoked Fetch Mail, thats where you end up.   
If you're in your INBOX,  you end up in the INBOX.

Can we close this ticket then?

Implemented returning to the local download mailbox after fetching.



As for the rest, as I mentioned I can't reproduce it any what you are 
asking for is already the way it is coded (i.e. no matter how we fetch 
mail, the fetching is *always* complete before the mailbox.php page is 
even loaded).

This works for me (new messages are indicated via the 'INBOX (#)' 
header and I am sent to the page with the first unread message.
Once again, I can not duplicate this.  And this makes no sense.  the 
maintenance stuff is done before the mailbox page is even loaded, so 
when the mailbox is built all these messages are already in the mailbox.
This can probably be changed.

this is exactly what the code does now (except for the last part).



My testing is with IMP HEAD btw.

The fetchmail/accounts code in IMP behaves inconsistently, depending 
on the results of a fetchmail operation.  In addition, the message 
index is not updated if new messages are received.



mailbox_start=1

sort_by=0

sort_dir=0



Examples:



On initial login, with unread or read messages in the INBOX, if you 
have fetchmail configured as a maintenance task and confirm that, and 
no new messages are on the remote server, you are dropped into your 
INBOX, at the first unread message.  This works as expected.



On initial login, with no unread message in the INBOX, if you have 
fetchmail configured as a maintenance task and confirm that, you're 
dropped into your INBOX and the notification is that Fetchmail: N 
messages in Account name.  However, the message index is not updated 
to reflect the fact that you have a new message and you are positioned 
at the beginning of the messages.  I would expect that the number of 
new messages would be reflected in the INBOX and that you would be 
taken to the first new unread message.  But I need to refresh to get 
that to happen.



On initial login, with one or more unread messages in your INBOX, if 
you have fetchmail configured as a maintenance task and confirm that, 
you're dropped into your INBOX and the notification is that Fetchmail: 
N messages in Account name.  However, the message index is not updated 
to reflect the fact that you have a new message and you are positioned 
at the first unread "old" message.  Again, you have to refresh your 
INBOX to see the new message count.



After initial login, if you go to the Accounts icon in the menu of IMP 
and force a check for new messages, you are presented with a 
confirmation screen.  After you confirm, your accounts are checked.   
And you are returned to the confirmation screen, with Fetchmail: N 
messages in Account name.  My expectation is that you'd be returned to 
your INBOX (or whatever folder you were in when you invoked fetchmail).



I think the algorithm for fetchmail should go something like this 
(everywhere its invoked from):



Check for confirmation and which accounts to check

Check for mail in remote accounts

Update folder index with new message index

Return to either the folder that fetchmail was called from, or 
initial_page (if initial login and there was no folder that fetchmail 
was called from) and honor the value of mailbox_start