For initial login to an Office 365 account, there are either IMAP subscriptions issues, or bad UX. Basically just the Inbox shown even if many folders exist. If we ever get such states and it's for real, we should make sure the user gets set up properly, maybe just pop up the subscription dialog(?)

I think this also makes us miss out on using the standard folders (RFC 6154). Or perhaps they don't support that.

xref bug 1528136.

nsImapProtocol::FindMailboxesIfNecessary may be a good place to debug it... https://searchfox.org/comm-central/rev/b51510f313fdf504158e766b4ac7b326454d9e9a/mailnews/imap/src/nsImapProtocol.cpp#6965

I'm seeing only Inbox and Trash. The server reports via lsub that only trash is subscribed. I guess that's OK since inbox always shows. I then sent a message from the o365 account and it created and subscribed the "sent" mailbox and shows in tb. So i thought maybe only folders containing something are reported subscribed by the o365 server. So I went to the webmail and copied the message I sent to existing "Conversation History" folder. Tb didn't see it even after I manually subscribed to "Conversation History". It appears in the response to imap LSUB but never appears in TB. Don't know why, I'll have to research this.
Edit: The "Conversation History" folder never appeared even on restart.

There are many m/s specific folder to subscribe and I'm pretty sure we don't want to show them all unless the user wants to see them. I'll look closer at this issue.

o365 don't seem to mark any of their folders as "special use" like Archive, Sent etc so its pretty much up to the user to use (subscribe to) the ones they provide or create their own (either via tb or at the web site).

The main problem I see is that when new folders are created or existing ones subscribed to they don't show up in tb unless you restart and sometimes not then either. I've seen this problem with other servers but was never sure why. Typically collapse/expand of the folder tree at the top (server) level discovers new folders. This causes function PerformExpand() to occur: https://searchfox.org/comm-central/rev/aeda6566a38a785ab44018e04dc6ca79ee4fbf74/mailnews/imap/src/nsImapIncomingServer.cpp#856

This seems to reliably occur on expand and if the call to DiscoverAllFolders() at the bottom is called, new folders are discovered. However, there are several place where a return can occur before this is called. With printfs and debugger I found the problem is because the returned password is empty: https://searchfox.org/comm-central/rev/aeda6566a38a785ab44018e04dc6ca79ee4fbf74/mailnews/imap/src/nsImapIncomingServer.cpp#862

I don't know why a password is looked at here. Maybe it's to avoid accessing folders (imap list and lsub) if you are not authenticated at the server. But this often returns empty when you are authenticated and new or newly subscribed (or unsubscribed) folder don't appear (and don't disappear) on expand.

I can't find any documentation on why the password is needed here in bugzilla history or dxr/searchfox blame functions.

Commenting out the call to return NS_OK on an empty password seems to fix the problem. If you are not authenticated at the server and you try to send the imap commands to the server, they will be rejected. So I'm not sure why the check for password occurs here at all.

Note: I have observed that if the o365 account is not touched and remains idle for a while (maybe 1/2 hour, not sure) that a non-empty password is obtained and the function does the discover on expanding the tree. But trying a collapse/expand immediately again fails to discover because of empty password.

Given that office is a major platform, and we have many office bug reports, shouldn't we have a go at mitigating this?

comment 2"Commenting out the call to return NS_OK on an empty password seems to fix the problem. If you are not authenticated at the server and you try to send the imap commands to the server, they will be rejected. So I'm not sure why the check for password occurs here at all."

(In reply to Wayne Mery (:wsmwk) from comment #3)

Given that office is a major platform, and we have many office bug reports, shouldn't we have a go at mitigating this?

comment 2"Commenting out the call to return NS_OK on an empty password seems to fix the problem. If you are not authenticated at the server and you try to send the imap commands to the server, they will be rejected. So I'm not sure why the check for password occurs here at all."

The problem of not seeing subscription changes for oauth2 servers was, I thought, fixed here: bug 1759883

Also, FWIW, yesterday I tried to access the office365 mail account that Magnus provided me for testin (gene@mozthunderbird2.onmicrosoft.com) and it seems to be non-functional again. Can no longer login with TB. I can login at the site using the password but it shows I have no applications authorized for use.

Right that sandbox expired. Sent you a new account.