Open Bug 1373940 Opened 7 years ago Updated 2 years ago

downloading header 10 of 1 in <folder> - counts/number of messages are in wrong order

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Type:
defect

Tracking

(Not tracked)

People

(Reporter: mkmelin, Unassigned, NeedInfo)

References

Details

+++ This bug was initially created as a clone of Bug #1348762 +++ On trunk I keep seeing "Downloading header 18 of 1 in <folder>". Seems the counts are the wrong order for some cases? Looking casually at the code, I didn't yet spot the problem. https://hg.mozilla.org/comm-central/annotate/ca379f40ef826555e7da4988f56205a117f30542/mail/locales/en-US/chrome/messenger/imapMsgs.properties#l84
Hmm, the message is assembled here: https://hg.mozilla.org/comm-central/rev/8ac8055cd42c05612a26558e684b9aa763ff36c2#l4.295 + PercentProgressUpdateEvent(progressString.get(), progressCurrentNumber, + m_progressExpectedNumber); So I don't see how that could be in the wrong order. The only thing I could think of is that the numbers don't get reset and the message should really read "1 of 1" instead of "18 of 1". Magnus, can you tell how many are really downloaded. Gene, can you please take a look.
Flags: needinfo?(gds)
Yeah the variables look correct, but something is off. Sorry I don't have more details to provide atm. Will keep my eyes open.
(In reply to Jorg K (GMT+2) from comment #1) > > Gene, can you please take a look. I did 100's of downloads of my fairly big imap mbox's and don't see this. I haven't had a chance to try the test again but I may have seen something similar but only when the server connection is lost and re-established during download; the number of messages is sometimes shown to be larger than the actual number to download, e.g. should be "55 of 2000" but says "55 of 4000". This is rare however. In your case, are you seeing the 2nd number counting (i.e. they are backwards), e.g., 10 of 1 10 of 2 10 of 3 : 10 of 10 ?? But should be; 1 of 10 2 of 10 3 of 10 : 10 of 10. Also, I assume you are downloading imap? Are you seeing this, maybe, only on a specific mbox, e.g., INBOX? Also, on a fast connection 18 emails will download quickly and you probably won't see all the counts. Is 18 a typical number that you download? Is this random or does it all the time? Are you using the English strings that I committed or has a translation been done that might have the placeholders reversed (just thought I'd ask, don't know how locale stuff really works).
Flags: needinfo?(gds)
Today it said "Downloading header 1632 of 8 in ......." The folder has 1900 messages. It likely downloaded more than 8, but I don't know.
I have pulled and updated to the latest/trunk tb and will check this after it all rebuilds. However, last time I checked this over a month ago it was OK.
(In reply to gene smith from comment #5) > I have pulled and updated to the latest/trunk tb and will check this after > it all rebuilds. However, last time I checked this over a month ago it was > OK. Still OK for me with latest version. In my test profile I delete all the "folders" for each account, e.g., files inbox and inbox.msf. Then I restart tb and let them all download. I never see a reversal of the fields for any header or message downloaded for any mailbox. I don't know exactly what you are doing when you see the reversal. I assume you are just bringing in new emails for the day? I usually don't receive enough emails in a day (or between starts of tb) to even notice the message counts at the bottom. So, on another computer, I copied about 25 messages from my gmail inbox to my normal account "spam" folder. When I clicked on that spam folder on the computer running hg latest (default branch) I see the correct downloading count fields 1...25 of 25 at the bottom, not reversed.
(In reply to gene smith from comment #3) > Are you using the English strings that I > committed or has a translation been done that might have the placeholders > reversed (just thought I'd ask, don't know how locale stuff really works). This does not seem to be the problem, the string isn't yet translated in Finnish: https://hg.mozilla.org/l10n-central/fi/file/tip/mail/chrome/messenger/imapMsgs.properties
Yes I'm using the en-US version. The problem is not easily reproducible. I think it's usually not the inbox but another folder, which can have new messages which were sometimes moved there earlier by Thunderbird on another machine.
Seems this most frequently happens when I run a filter on my mozilla folder to move some mails to a subfolder. After the filter has finished, the status bar says it's opening the subfolder, and then the downloading of headers, with wrong numbers.
Severity: enhancement → minor
Magnus, I think you haven't answered comment 3.
Flags: needinfo?(mkmelin+mozilla)
I'll have to pay attention next time it happens. Not sure now which way it is. Anyway, it still exists. Saw it yesterday on trunk.
I found a way to slow down my connection to sub-dial-up speeds so I can try this again and see better what the message says.

Haven't seen this in a while now.

Flags: needinfo?(mkmelin+mozilla)

Bug 1521472 claims that the first number is the count of all downloaded messages, not just the ones belonging to the account.

Yes, recently I've seen this when restarting a failed/hung copy to a folder. The first number will be larger than the 2nd. There are bigger problems with bulk copy/move between accounts (bug 538375) but this is on my list.

Blocks: 1678948

also reported in bug 708342

Perhaps look at the duplicates for clues?

I was surprised to not see more reports of this in query https://mzl.la/3ubBYEv

Summary: downloading header 10 of 1 in <folder> - counts are wrong order → downloading header 10 of 1 in <folder> - counts/number of messages are in wrong order

see also bug 1665146 comment 12

Flags: needinfo?(mkmelin+mozilla)

In addition to bug 1665146 comment 12 I think something similar happens when you move focus from TB to another app while a large download is in progress and then come back to TB and the the displayed counts get messed up. I've seen in while working on bug bug 538375.

Hard to say if that's the same or not. Perhaps.

Flags: needinfo?(mkmelin+mozilla)

This bug is still present in 91.11.0 (64-bit)

(In reply to Jeff Minna from comment #25)

This bug is still present in 91.11.0 (64-bit)

91.12.0 and 102.1.0 ESR are right around the corner. I would guess it's not fixed in 91.12.0 but more likely in 102.1.0. What OS are you using?

(In reply to Jeff Minna from comment #25)

This bug is still present in 91.11.0 (64-bit)

Looks like 91.12.0 got pushed to release level. Can you do a Help > About Thunderbird and see if it's offered to you as well as report back?

Looks like 102.1.0 got pushed to release as well. If you're feeling brave, you could always try that version. Back up your profile first to be safe.

Flags: needinfo?(jkorders)

(In reply to Arthur K. [He/Him] from comment #28)

Looks like 102.1.0 got pushed to release as well. If you're feeling brave, you could always try that version. Back up your profile first to be safe.

Nothing has been done on this that I know of. I think comment 23 shows a way to duplicate the bug. So if you select the folder and let it finish downloading and don't move anywhere in TB or to another app, the counts shown in status bar don't get confused.
Also, seems to mess up if the network goes down during download.

The link in comment 22 above points to autosync as the possible culprit. I'm working on another bug regarding autosync (bug 1776823) so I'm a little more familiar with it now. So I'll take a look at it while I'm at it.

See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1776823
Severity: minor → S4

In my case, it happens when you download the headers of several newly subscribed IMAP folders.
It seems that the progress count does not reset when the selection moves from one folder to another.
For instance:

  • the first folder shows 1... to 1000
  • the second 1001... to 500

TB Version 102.4.2
OS Ubuntu 22.10

You need to log in before you can comment on or make changes to this bug.