User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36

Steps to reproduce:

Run Thunderbird Beta Normally

Actual results:

There are no status messages in the footer at the bottom of the window

Expected results:

Prior to Beta when there are delays the footer would display various messages including "Opening Inbox", "Loading Message". There are plenty of delays in Thunderbird Beta 113.0b6 but no message in the footer characterizing the delay.
I would hope the status info would be at least as good as before beta, and really it would be helpful if it was more informative perhaps with a debug option.

I believe reporter's comment 0 that this happens, and would be nice to restore, but not a priority as a minor issue.

I've noticed this too for some time when testing with huge messages like over at bug 1840943. The problem is when you open a huge message for the first time and if it has to be downloaded from the server you can end up with a blank screen for a while and there is no indication that the download is in progress (before status bar showed "Downloading message..."). Also, when you open a message from cache or offline store, there might also be a blank screen with no progress indication but for a shorter time (before status bar said "Loading message...").
In addition, there used to be a not-so-great bar graph showing the Downloading or Loading progress over to the right and now it's missing too. It didn't always show the progress exactly but it least it gave some feedback that something was happening.

Letting Martin explore this issue.
Most likely we're missing a simple "wiring" between the about3Pane and the status bar, which are in different documents.

When looking into this I've found the following:

• The opening folder... etc. status bar messages come from the imap protocol, and from what I can call they still reach the frontend and should be displayed, however I didn't manage to get my imap server to behave such that these messages would be shown for considerable amounts of time.
• The loading message... is supposed to come from a C++ component that attaches a nsIWebProgressListener, well should attach one. I haven't quite been able to figure out if it's still even properly initialized or if it should even still work with the new message display setup.

Some code references:
I think the frontend is supposed to be hooked up here: https://searchfox.org/comm-central/rev/83561cca4167e0b330953ae01826bed2d112c08b/mail/base/content/mailWindow.js#188-196
And then there's also this C++ thing for the message loading: https://searchfox.org/comm-central/rev/83561cca4167e0b330953ae01826bed2d112c08b/mailnews/base/src/nsMsgStatusFeedback.cpp
These are the strings used by the IMAP protocol: https://searchfox.org/comm-central/rev/83561cca4167e0b330953ae01826bed2d112c08b/mail/locales/en-US/chrome/messenger/imapMsgs.properties#14

"no new messages" briefly flashes in status bar. Most people might miss it.

Re: Duplicate of this bug 1850326

With recent self-built daily, "Read Messages" button on Account Central does check for new mail (sends IMAP noop) but nothing at all appears in status bar. If I click "Get Messages" button or do right-click on account name context item "Get Messages" it also correctly checks for new mail and I see <Account name> There are no new messages on server for a very short time. I don't know if this is a change from 102 behavior but reporter of bug 1850326 says it is.

I had some success in getting the "Download message..." to display in status bar when a new message is downloaded from imap server. However, I don't know exactly why this fixes it or what has changed since about v110 (last version that showed correct status bar) that now requires this:

diff --git a/mailnews/imap/src/nsImapService.cpp b/mailnews/imap/src/nsImapService.cpp
--- a/mailnews/imap/src/nsImapService.cpp
+++ b/mailnews/imap/src/nsImapService.cpp
@@ -2352,32 +2353,54 @@ NS_IMETHODIMP nsImapService::NewChannel(
     if (msgDocShell) {
       nsCOMPtr<nsIProgressEventSink> prevEventSink;
       channel->GetProgressEventSink(getter_AddRefs(prevEventSink));
       nsCOMPtr<nsIInterfaceRequestor> docIR(do_QueryInterface(msgDocShell));
       channel->SetNotificationCallbacks(docIR);
       // we want to use our existing event sink.
       if (prevEventSink) channel->SetProgressEventSink(prevEventSink);
     }
   }
+  else {
+    printf("gds: no window on url\n");
+    nsCOMPtr<nsIMsgMailSession> mailSession = do_GetService(
+        "@mozilla.org/messenger/services/session;1", &rv);
+    NS_ENSURE_SUCCESS(rv, rv);
+    nsCOMPtr<nsIMsgWindow> msgWindow;
+    rv = mailSession->GetTopmostMsgWindow(getter_AddRefs(msgWindow));
+    if (NS_SUCCEEDED(rv) && msgWindow) {
+      mailnewsUrl->SetMsgWindow(msgWindow);
+      nsCOMPtr<nsIMsgStatusFeedback> statusFeedback;
+      msgWindow->GetStatusFeedback(getter_AddRefs(statusFeedback));
+      nsCOMPtr<nsIProgressEventSink>eventSink = do_QueryInterface(statusFeedback);
+      channel->SetProgressEventSink(eventSink);
+    }
+  }
+
   // the imap url holds a weak reference so we can pass the channel into the
   // imap protocol when we actually run the url.
   imapUrl->SetMockChannel(channel);

This also causes the progress bar graph to shows when a new message is downloaded from the server.

But when I open an existing message from storage (offline or disk cache) it should also show in status "Loading message..." along with the bar graph, but that still doesn't appear. I haven't been able to find a way to show "Loading message..." which should be displayed here:
https://searchfox.org/comm-central/rev/2fe8694a034fc959c6fd761b5b8f22f368d5463f/mailnews/base/src/nsMsgStatusFeedback.cpp#78

I notice also that at v110 and earlier, the header displays first and then the body. But after 110, the body downloads and displays first and then the header (subject etc) so the download and message load processes seems slower but not sure that they really are. This is mostly noticeable with large messages (e.g., 100 MB) and not as apparent with small or average sized messages.

It's probably related to bug 1837562. There is no longer any (correct) mapping to a msgWindow in general, so that part of the updating/notification mechanism needs to be reworked.

We noted that code similar to the one suggested by Gene in comment #9 was removed here:
https://hg.mozilla.org/comm-central/rev/5ad63468cbe2#l5.12
To fix the issue in nsMsgStatusFeedback.cpp, one would have to get a call stack from a debug version that was still working. This is not an IMAP problem, the "Loading..." was displayed as status for (larger) POP3/local messages as well.

(In reply to Magnus Melin [:mkmelin] from comment #10)

It's probably related to bug 1837562. There is no longer any (correct) mapping to a msgWindow in general, so that part of the updating/notification mechanism needs to be reworked.

According to our previous comment #11, Gene's code from comment #9 was likely made necessary due to the change in bug 1830600 we've pointed out. However, failure to display "Loading message..." is likely a Supernova issue. The code pointed out in comment #5 (https://searchfox.org/comm-central/rev/83561cca4167e0b330953ae01826bed2d112c08b/mail/base/content/mailWindow.js#188-196) applies to the main messenger window. Messages are no longer loaded into that window, they are loaded into a sub-window aboutMessage now. If the Mozilla platform code sends notifications for (mail) document loading, it will likely send them to aboutMessage (if that's equipped with a proper state listener) and not the top window where the status feedback is located. Just guessing, of course.