+++ This bug was initially created as a clone of Bug #1811720 +++

Note: This bug will not be noticed by users with default imap account setups. See comment 3 below.

This is a continuation of Bug #1811720 where no folders displayed at startup with new UI code.
I thought for a while that the solution for that bug fixed all the problems since I was able to see all the folders and click on and open several random messages.
However, I finally noticed that I could only open messages that were already stored in cache or offline store and I could not open other messages and new messages were not retrieved. No imap activity to the server occurs when attempting to select folders or open messages.

An early URL that occurs is "discoverallboxes" (it typically occurs first). Before the recent UI changes, that URL always had a "window" property/parameter associated with it. But now the window is always null. The imap code sets the window for that URL so that a password prompt, if needed, has a place to display.

Here's where the window is stored to the URL. I was unable to trace back and determine how or why the window pointer is now null:
https://searchfox.org/comm-central/rev/fcf37b20a6095ac4f75a5db27503e1480d8c56a8/mailnews/imap/src/nsImapService.cpp#1702

This is great, thank you so much for the info and detailed overview.

Gentle ping for Geoff to investigate this.
As I'm not familiar with the IMAP code, I have a bunch of questions that might be silly.

What are the historical reasons for saving a window?
It seems that almost every method is using SetMsgWindow() for an nsIMsgMailNewsUrl.
Is this a good design?
Should we try to get away with it and if anything is needed (for prompts or other), could we "simply" use the current window without needing to store it or cache it?

Here's a link that describes the issue and why a window is associated with some, not all, URLs: bug 1793599 comment 19.

I don't know if it's a good design but the window parameter on URLs has been around a while. The reason some URLs have a null window pointer is because they are triggered by "unattended operations" like moving messages via filtering or periodic biff or autosync and you want to inhibit a prompt, such as for a password, from popping up out of the blue.

I learned about the need for the window pointer after a go-around with Ben Bucksch. He describes the purpose here: Bug 1690093 comment 12 and it's discussed at other places in that bug. I had suggested to use just a global "top level" window pointer if the URL's window pointer is null but that was pointed out to me to be wrong.

FYI, a workaround for the current bug reported here is to right-click the account and select the "subscribe" function and don't change anything. This produces a subscribe URL with a "window" that lets the queued up "windowless" URLs run so authentication and other normal imap activities starts up and then you can access your mailboxes for the account.

I usually run, while testing imap, with all account server setting "check for new mail at startup" disabled. This avoids running URLs on accounts that I'm not looking at and keeps the imap log less cluttered. So another workaround I found is to enable this instead. This causes the initial "discoverallboxes" URL to have a window so imap URLs run for that account.

I also noticed, compared to pre-UI changes, that now with "check for new mail at startup" disabled, on click of Inbox not only does URL "discoveralboxes" have a null window but the next URL "select" also has a null window. Before the recent UI changes, both URLs had a valid non-null window.

Note: Since "check for new mail at startup" enabled is the default setting, this bug may not be noticed by most "daily" users.

I've known about this for some time. I think there's a simple fix, but I'm trying to establish if there are unwanted side-effects. Looking good so far.

I've not told a bunch of front-end things about nsIMsgWindows as it's a bit of a broken idea – an nsIMsgWindow used to represent a window which could only display one message at a time, now we can display many messages in one window but there can still only be one nsIMsgWindow. Once I've gone in and ripped the guts out of that interface things will be a bit happier.

Okay, I think this is okay. I'm only guessing that it solves the problem though – does it, Gene?

Yes, that fixes the startup problem. I don't know if this will cause all URLs to have the "topmost" window since it is expected that sometimes the URL will have a null window pointer/reference.
Anyhow, thanks for looking at this!

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/07ceab5685a8
Add msgWindow to dbViewWrapperListener. r=aleca

I've noticed a few other random things that are not quite as they were with the older code. I'll file these as separate bugs if you want me to. Or maybe you already know of these issues. If so, just ignore this list.

• Starts as a fixed size window and it's not possible to drag with mouse on sides or corners to adjust the size. Have to maximize and then restore and then can grab an edge and adjust the size. I think running a pre-UI change older version or the release version affects this. If I only run the new UI version the previous size is remembered and can be grabbed.

• The status bar at bottom is blank except for the offline/online icon at the far left. There no indication of status such as "Downloading message" or "Loading message" and the progress bar graph is not there.

• Scrolling the message list down causes the message info to display over top of the column headings.

• Message list position is not remembered on restart. E.g., if sorted by size, on startup smallest size is at the top and in view even though I shut down with largest at bottom in the view. Expected it to start with largest at bottom in view.

• Dragging the scroll bar on a long list of messages for, e.g., Inbox with 1000s of msgs, causes the display to go blank until the drag stops or the bar is released.

• When moving from a displayed messages to one that requires downloading and the new message is very large (e.g., 100Mbyes) the previous message remains displayed until the whole message is downloaded. With older code, the header info (subject, etc) would instantly appear as soon as the message is selected and then then download would occur to bring in the message body and attachments (with progress shown in status bar). This isn't as noticeable with small messages or for messages already stored to cache or offline store.

• Note: This is not a new problem and I see it with the older code too so maybe doesn't belong on this list.
  Cache usage on the General Settings screen doesn't update until the tab is closed and re-opened. Usually clicking "Clear Cache" button doesn't update the cache usage even though cache is definitely cleared when clicked; but sometimes it does update to zero.

(In reply to gene smith from comment #9)

• Starts as a fixed size window and it's not possible to drag with mouse on sides or corners to adjust the size. Have to maximize and then restore and then can grab an edge and adjust the size. I think running a pre-UI change older version or the release version affects this. If I only run the new UI version the previous size is remembered and can be grabbed.

Are you running 111 and 110 with same profile?
I never noticed this issue. Could open a bug and attach a video recording of it (if you can hide your personal data)?

• The status bar at bottom is blank except for the offline/online icon at the far left. There no indication of status such as "Downloading message" or "Loading message" and the progress bar graph is not there.

• Scrolling the message list down causes the message info to display over top of the column headings.

Yup, just themeing issue, fixing in bug 1813368

• Message list position is not remembered on restart. E.g., if sorted by size, on startup smallest size is at the top and in view even though I shut down with largest at bottom in the view. Expected it to start with largest at bottom in view.

Do you mean the scrolling position?
If that's what you mean, we're aware of that as we haven't implemented that yet.

• Dragging the scroll bar on a long list of messages for, e.g., Inbox with 1000s of msgs, causes the display to go blank until the drag stops or the bar is released.

We're still working on improving the performance and the items recycling of the new list, so yeah, some flashing is expected. It'll get better with time, no need to open a bug for it.

• When moving from a displayed messages to one that requires downloading and the new message is very large (e.g., 100Mbyes) the previous message remains displayed until the whole message is downloaded. With older code, the header info (subject, etc) would instantly appear as soon as the message is selected and then then download would occur to bring in the message body and attachments (with progress shown in status bar). This isn't as noticeable with small messages or for messages already stored to cache or offline store.

Please open a bug for it.

• Note: This is not a new problem and I see it with the older code too so maybe doesn't belong on this list.
  Cache usage on the General Settings screen doesn't update until the tab is closed and re-opened. Usually clicking "Clear Cache" button doesn't update the cache usage even though cache is definitely cleared when clicked; but sometimes it does update to zero.

Unrelated to this, and we currently don't have capacity to look at this issue.

Thanks for the info.