1832149 - No longer showing status info like "Opening Inbox..." or "Loading message..." in status bar of TB Beta 113.0b6

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect, P2)

Description

[km]

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.

Comment 1

[Thomas D. (:thomas8)]

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

Comment 2

[gene smith]

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.

Comment 4

[Alessandro Castellani [:aleca]]

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.

Comment 5

[Martin Giger [:freaktechnik]]

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

Comment 7

[Wayne Mery (:wsmwk)]

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

Comment 8

[gene smith]

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.

Comment 9

[gene smith]

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.

Comment 10

[Magnus Melin [:mkmelin]]

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.

Comment 11

[betterbird.project+9]

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.

Comment 12

[betterbird.project+9]

(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.

Comment 14

[betterbird.project+10]

However, failure to display "Loading message..." is likely a Supernova issue.

Confirmed via mozregression:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=76f62fd3a78092592457e19dbc6e59f87c4f084d&tochange=ac5c72f2e56036e2088b5aa794891978fcede5aa

Comment 15

[betterbird.project+10]

https://github.com/Betterbird/thunderbird-patches/blob/main/115/bugs/1832149-fix-status-feedback.patch

Comment 16

[Brendan Abolivier [:babolivier]]

Attachment: Bug 1832149 - Properly route status updates to the main window for user feedback. r=leftmostcat,aleca

Comment 17

[betterbird.project+10]

Hello Brendan, please attribute the hunk in aboutMessage.js, displayMessage(), to our project (see comment #15 of 2023-09-18). We spent a bit of time on analyzing why the "Loading..." didn't show, so we believe the investigation and solution should be attributed appropriately. If you don't copy our hunk 100%, something like was done here is an option. As for your try/catch: Hopefully there is a better solution since this will throw for all messages that are displayed in that window/browser except the very first one.

Comment 18

[betterbird.project+10]

Is there a misunderstanding as to whom this request was directed to and what the license conditions are? You can consult them here:
https://github.com/Betterbird/thunderbird-patches/blob/main/LICENSE

When You apply source code patches from this product, resulting revisions must be attributed to the
Betterbird Project in an appropriate form (changeset header or commit message) by means of Your
version control system.

We assume that in this case the non-attribution was just and oversight since it is usually done correctly.

Comment 19

[Alessandro Castellani [:aleca]]

Jorg, please stop NI core developers, you were banned and you keep ignoring the ban.
We write attributions in the commit message if needed, but the patch is still in draft and unfinished.

Comment 20

[Brendan Abolivier [:babolivier]]

Sorry for the confusion, but I did not use your patch. The section of my patch you're referring to is meant as a partial revert of this patch (plus trying to account for the issues mentioned in the comments), which (if I remember correctly) I found through some searches on https://searchfox.org/comm-esr102/source/ and some manual bisecting.

Comment 21

[betterbird.project+10]

Sorry about the confusion here as well. Good research, thank you! The try/catch situation still needs to be resolved, you saw our clumsy attempt with window.statusFeedbackAdded = true;.

Comment 22

[Magnus Melin [:mkmelin]]

The patch has bitrotted. Please rebase.

Comment 23

[Brendan Abolivier [:babolivier]]

Rebased on latest c-c

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/59dc5047d862
Properly route status updates to the main window for user feedback. r=leftmostcat,aleca

Comment 25

[Brendan Abolivier [:babolivier]]

Attachment: Bug 1832149 - Properly route status updates to the main window for user feedback (ESR + beta patch). r=#thunderbird-reviewers

This is https://phabricator.services.mozilla.com/D189943 (which is already on c-c) but rebased to be uplifted to ESR and beta.

Partly based on the changes @gds suggested at https://bugzilla.mozilla.org/show_bug.cgi?id=1832149#c9

Comment 26

[Wayne Mery (:wsmwk)]

Good for 115?

Comment 27

[Wayne Mery (:wsmwk)]

Comment on attachment 9356396 [details]
Bug 1832149 - Properly route status updates to the main window for user feedback. r=leftmostcat,aleca

[Triage Comment]
Approved for esr115

Comment 28

[Rob Lemley [:rjl]]

Thunderbird 115.5.2:
https://hg.mozilla.org/releases/comm-esr115/rev/40a078f121af