Closed Bug 1196662 Opened 9 years ago Closed 9 years ago

Thunderbird not checking for mails and becomes unresponsive after hibernation (problem is caused by upgrade to Thunderbird 38.2.0)

Categories

(Thunderbird :: General, defect)

38 Branch
defect
Not set
major

Tracking

(thunderbird40 wontfix, thunderbird41 fixed, thunderbird42 fixed, thunderbird43 fixed, thunderbird_esr3841+ fixed)

RESOLVED FIXED
Tracking Status
thunderbird40 --- wontfix
thunderbird41 --- fixed
thunderbird42 --- fixed
thunderbird43 --- fixed
thunderbird_esr38 41+ fixed

People

(Reporter: aryx, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [Fixed by bug 1197152][status/workaround: Comment 81/waiting on bug 1197152][no more comments please][regression:TB38.2.0])

Attachments

(5 files, 3 obsolete files)

Thunderbird 38.2.0 on Windows 8.1 64 bit, Lightning disabled Starting last week, I noticed that Thunderbird doesn't check anymore for mails if the machine resumes after hibernation while Thunderbird was running. The NSPR log has no items with timestamps after the hibernation. What I also noticed but only with NSPR logging active: The UI didn't response to my mouse clicks and scrolls after hibernation or very, very slowly (and only to clicks). This even affected a Thunderbird instance running in parellel with no NSPR logging set. I hadn't experienced the issue with Thunderbird 38.1.
I confirm. Having same problems since updating Thunderbird to 38.2.0 (Lightning enabled) - no automatic e-mail checks after hibernation and occasional UI freezes (only restarting Tb helps). Probably it's not important, but master password is set. I'm using Comodo Internet Security and Microsoft's EMET.
If you reinstall version 38.1, does the problem go away?
Flags: needinfo?(temp82)
Flags: needinfo?(aryx.bugmail)
I will check it soon, but first I'm trying to figure out for how long I need to hibernate Windows. Because when I do it just for few minutes, problem doesn't occur. It happens when I hibernate PC for a night (6-8h). I'm curious if it's somehow connected with times I set for checking for new messages (which vary from 10 to 200 minutes depending on the e-mail account). I didn't mention it earlier, but downloading e-mails manually (which works fine) doesn't fix/restart automatic checks. Probably tomorrow I will downgrade and report.
Flags: needinfo?(temp82)
The issue also occurred with hardware acceleration enabled. Downgrading to Thunderbird 38.1.0 fixed the issue. The sometimes unresponsive UI might be an indicator that Thunderbird is stuck in a loop.
Flags: needinfo?(aryx.bugmail)
In my case 210 minutes of hibernation was enough to replicate problem with Thunderbird 38.2.0. I also tried enabling, disabling hardware acceleration before - with no effect, even used Tb in safe mode, but unresponsive UI problem occurred too. Thunderbird 38.1.0 is unaffected.
Putting Windows in sleep mode for 2h (without hibernation) caused same problem.
Aryx, can you try bug 182831 comment 7?
Hopefully this will help engineers, as I believe this additional issue is related. At the same time that Thunderbird stops automatically retrieving email, it also no longer pops up alerts for calendar tasks. Both of these issues started within about the last 7 days (I'm on 38.2). I can manually retrieve mail with no problem. I haven't noticed whether it *only* happens after waking from nightly hibernation or if it happens other times as well; however it was fine last night and this morning after waking it is failing. Windows 7 (64 bit), with IMAP accounts set to download automatically every few minutes.
(In reply to :aceman from comment #7) > Aryx, can you try bug 182831 comment 7? Yes, autosyncModule._running returns always true after hibernation when checking its value several times.
We should make sure we have tests for this.
Flags: in-testsuite?
Flags: in-moztrap?
Same on Windows 7 32bit
(In reply to Aryx [:archaeopteryx][:aryx] from comment #9) > (In reply to :aceman from comment #7) > > Aryx, can you try bug 182831 comment 7? > Yes, autosyncModule._running returns always true after hibernation when > checking its value several times. Yeah, I meant bug 1182831 comment 7, but it seems you figured it out :) Would you mind trying to edit the JS code directly in your installation of TB38.2 to revert the change in bug 1182831 ? I am not sure there is a try server for release/ESR branch where we could produce try builds.
We should resolve this before we do beta 42. Or backout bug 1182831, assuming it is the cause. bug 1191905 is another possible duplicate
Blocks: 1182831
Severity: normal → major
Whiteboard: [regression:TB38.2.0]
Has anyone actually confirmed that bug 1182831 is the issue?
When Aryx basically backs it out in his build (comment 13), we should have the answer.
(In reply to Kent James (:rkent) from comment #15) > Has anyone actually confirmed that bug 1182831 is the issue? Users do not see it with 38.1.0 and no one has suggested other possible causes so we must consider it to be a strong contender until proven otherwise. Note - in total we have about 10-12 new bug reports in recent weeks about not getting or not seeing new messages http://mzl.la/1LtxbTH (sort it by bug number) Reports against 38.1.0 obviously predate bug 1182831, and tend to be about not seeing new messages at *startup*.
Reverting the changes from bug 1182831 didn't fix the issue, the main suspect is http://hg.mozilla.org/releases/mozilla-esr38/rev/57981d525846 / Bug 1178890 - Update timer arrays after sleep to account for time sleeping. A build with the parent mozilla-esr38 changeset before this change and comm-esr38 tip works as expected, so it's caused by a change on mozilla-esr38. The firing time gets moved to the future according to the sleep time. If mailnews already contained behavior like that, there might a double correction. Queries which might be interesting: https://dxr.mozilla.org/comm-central/search?q=sleep_notification&redirect=false&case=false https://dxr.mozilla.org/comm-central/search?q=wake_notification&redirect=true&case=false autosyncModules._running is only false for a few seconds (create autosyncActivities.logging.console and set it to "Info"). It also doesn't list enough running / sleeping states to match the account count, so there might be a concurrency issue. Furthermore, it's confusing that the versions aren't built with the changeset represented by the release tag, e.g. Thunderbird 38.2.0 lists http://hg.mozilla.org/releases/mozilla-esr38/rev/5f77862a6e66 in about:buildconfig, but THUNDERBIRD_38_2_0_RELEASE http://hg.mozilla.org/releases/mozilla-esr38/rev/e72e9054d9eb
No longer blocks: 1182831
Keywords: regression
Does this affect all OSes? Windows/Mac only? Mac only? We have one other possible regression (which I can't repro) which has only been reported on Macs. If you can reliably repro it, can I make a patch with some debugs for you to run?
Flags: needinfo?(aryx.bugmail)
Having the same problem with 38.2.0 on Windows 7 x64 reported as bug 1197515.
Jay, Javi, does this reproduce on Mac?
Flags: needinfo?(leofigueres)
Flags: needinfo?(iamjayakumars)
Blocks: 1177624
Blocks: 1186394
No issue in MAC OS X 10.11 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
Flags: needinfo?(iamjayakumars)
No longer blocks: 1195043
better query for potentially related bugs http://mzl.la/1MTwo1B
This log from a profile with many accounts has less timeouts in the log than the one with one pop3 and one rss account.
No longer blocks: 1186394
Many bugs are opened for this problem. Adding "unresponsive"(from bug 1197844) and "38.2.0"(many of dups has string for 'problem is caused by upgraded to Tb 38.2.0' but this bug doesn't), for ease of search, duping etc.
Summary: Thunderbird not checking for mails after hibernation → Thunderbird not checking for mails and becomes unresponsive after hibernation (problem is caused by upgrade to Thunderbird 38.2.0)
No longer blocks: 1197844
A possible(but never practically usable) workaround of this bug. Before Sleep/Suspend, go Work Offline, then after WakeUp/Resume, go Work Online. To develops: What is recommendation to Thunderbird users who unfortunately already upgraded to Tb 38.2.0(or Tb 40.0.2) and frequently uses hibernation? Downgrade to stable Tb38.1.0? Disable auto-sync of IMAP in Tb? Transfer to other usable mailer?
Those logs look totally reasonable. We may need a higher log level (let me check the other bug on Mac wakeup; nsTimerImpl:4 logs are already uploaded there).
Attachment #8652739 - Attachment is obsolete: true
Assignee: nobody → rjesup
Status: NEW → ASSIGNED
Attached file debug log with more details.log (deleted) —
Two timers get refreshed after the hibernation before all timeouts get adjusted: Timer: Slept 4494870ms Update mTimeout[22] (timer=13fae00, type = 0) from 9999ms to 4504870ms (original delay 10000ms) Update mTimeout[23] (timer=c3b9580, type = 0) from 9999ms to 4504870ms (original delay 10000ms) So after waiting the time the computer hibernated, Thunderbird checks for the mails and fetches them.
I confirm this bug and can give a little more info which I hope will be helpful. OS : Windows XP sp3 After coming out of hibernation, the UI is no longer responsive. The only way, other than restarting Thunderbird, is to change the window focus. So, if I click on a mail item, nothing visibly happens. If I now force focus to another window (swap to another app or simply click on the desktop) the UI will refresh correctly. Hope this helps.
(In reply to Aryx [:archaeopteryx][:aryx] from comment #41) > Created attachment 8653440 [details] > debug log with more details.log > > Two timers get refreshed after the hibernation before all timeouts get > adjusted: > > Timer: Slept 4494870ms > Update mTimeout[22] (timer=13fae00, type = 0) from 9999ms to 4504870ms > (original delay 10000ms) > Update mTimeout[23] (timer=c3b9580, type = 0) from 9999ms to 4504870ms > (original delay 10000ms) > > So after waiting the time the computer hibernated, Thunderbird checks for > the mails and fetches them. Aha! (also note the previous/earlier lines, like: 2015-08-27 10:49:15.122000 UTC - 0[1311140]: Update mTimeout[21] (timer=10f8c700, type = 1) from -2807772ms to 1687098ms (original delay 1800000ms) 2015-08-27 10:49:15.122000 UTC - 0[1311140]: Update mTimeout[22] (timer=13fae00, type = 0) from 9999ms to 4504870ms (original delay 10000ms) So this provides a smoking gun as to the cause: timers that are set after we wake up get modified as well. Likely this was also the cause of the hard-to-reproduce problems that mccr8 has referred to going back a Long Time (the old timer code pushed all timers forward, and effectively restarted them from scratch, so a 100sec timer with 1 second left went back to 100s). This bug can make that worse, if the machine is asleep a long time, *and* the timer gets rescheduled before the timer code itself processes the wakeup (which may be rare in "normal" use; in Firefox I've been totally unable to reproduce the OSX-freezes-on-wake bug even with step-by-step instructions).
Flags: needinfo?(nfroyd)
Flags: needinfo?(leofigueres)
Flags: needinfo?(docfaraday)
Flags: needinfo?(continuation)
So the callback is firing late or something? If this is the case, I would advocate removing the rescheduling entirely, since maintaining the order of the timer queue implies that we'd get unpredictable results. Consider the case where a timer with a duration of 0 is scheduled between coming out of sleep, and getting the callback. If we manage to detect this (pretty likely; a timer with a duration of 0 scheduled to go off nowish when we get the sleep callback, and the last time the event loop ran was long ago), the latest we can schedule the preexisting timers is also now (because there could be a pre-sleep timer with a duration of 0 that needs to fire first), which is identical to just not rescheduling. If we don't reschedule in the first place, at least the behavior is predictable (and less code!).
Flags: needinfo?(docfaraday)
I should also point out that if we're getting this callback late, and DoBeforeSleep is unreliable, it is totally possible that the event loop could run before getting DoAfterSleep, making the offset completely wrong.
The scenario in Comment 45 would result in some of the pre-sleep timers firing immediately, and then others being delayed a small amount; more weird unpredictable behavior.
I don't know anything about this issue.
Flags: needinfo?(continuation)
Attachment #8653298 - Attachment is obsolete: true
If we want to keep rescheduling, I think we would be forced to do something like the following (there are probably bugs): // For every delay, stores the next time at which a post-sleep timer with that delay is scheduled to fire. // This lets us ensure that we do not schedule a pre-sleep timer with the same delay after a post-sleep // timer. std::map<uint32_t, TimeStamp> delayToNextFiringMap; for (timer : mTimers) { if (LooksLikeAPostSleepTimer(timer)) { if (!delayToNextFiringMap.count(timer->mDelay) || delayToNextFiringMap[timer->mDelay] > timer->mTimeout) { delayToNextFiringMap[timer->mDelay] = timer->mTimeout; } } } // Now, we need to take into account that pre-sleep timers of a given delay should not be rescheduled after // post-sleep timers of that delay _or greater_. TimeStamp currentMax = forever... for (auto it = delayToNextFiringMap.rbegin(); it != delayToNextFiringMap.rend(); ++it) { if (currentMax > it->second) { currentMax = it->second; } else { it->second = currentMax; } } for (timer : mTimers) { if (!LooksLikeAPostSleepTimer(timer)) { TimeStamp newTimeout = timer->mTimeout + sleepDurationWeThink; auto it = delayToNextFiringMap.lower_bound(timer->mDelay); if (it != delayToNextFiringMap.end() && it->second < newTimeout) { newTimeout = it->second; } } } // Re-sort timers, stably
(In reply to WADA from comment #38) > A possible(but never practically usable) workaround of this bug. > Before Sleep/Suspend, go Work Offline, then after WakeUp/Resume, go Work > Online. Toggling between offline and online mode *at any time* will (re-)establish automatic mail check. Just click twice on the connection state indicator after having resumed from hibernation.
Attached file debug log with fix applied.log (deleted) —
Thank you, the patch fixes the issue. Reason for the already updated timeout: The biff manager detects the wakeup and requests that the accounts are checked for new messages in 10 seconds: https://hg.mozilla.org/comm-central/file/cc0929afb85b/mailnews/base/src/nsMsgBiffManager.cpp#l124
Any likelihood, irrespective of hibernate, that the timer changes could be causing hangs when mail notification windows pop up?
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #53) > Any likelihood, irrespective of hibernate, that the timer changes could be > causing hangs when mail notification windows pop up? This seems pretty improbable, since this change only affected code that ran when coming out of sleep.
(In reply to Randell Jesup [:jesup] from comment #43) > (In reply to Aryx [:archaeopteryx][:aryx] from comment #41) > > Created attachment 8653440 [details] > > debug log with more details.log > > > > Two timers get refreshed after the hibernation before all timeouts get > > adjusted: > > > > Timer: Slept 4494870ms > > Update mTimeout[22] (timer=13fae00, type = 0) from 9999ms to 4504870ms > > (original delay 10000ms) > > Update mTimeout[23] (timer=c3b9580, type = 0) from 9999ms to 4504870ms > > (original delay 10000ms) > > > > So after waiting the time the computer hibernated, Thunderbird checks for > > the mails and fetches them. > > Aha! (also note the previous/earlier lines, like: > > 2015-08-27 10:49:15.122000 UTC - 0[1311140]: Update mTimeout[21] > (timer=10f8c700, type = 1) from -2807772ms to 1687098ms (original delay > 1800000ms) > 2015-08-27 10:49:15.122000 UTC - 0[1311140]: Update mTimeout[22] > (timer=13fae00, type = 0) from 9999ms to 4504870ms (original delay 10000ms) > > > So this provides a smoking gun as to the cause: timers that are set after > we wake up get modified as well. Likely this was also the cause of the > hard-to-reproduce problems that mccr8 has referred to going back a Long Time > (the old timer code pushed all timers forward, and effectively restarted > them from scratch, so a 100sec timer with 1 second left went back to 100s). > This bug can make that worse, if the machine is asleep a long time, *and* > the timer gets rescheduled before the timer code itself processes the wakeup > (which may be rare in "normal" use; in Firefox I've been totally unable to > reproduce the OSX-freezes-on-wake bug even with step-by-step instructions). Hi, :jesup. Why have you removed the needinfo to my account?
Flags: needinfo?(rjesup)
Sorry, I thought I had asked you to provide logs
Flags: needinfo?(rjesup) → needinfo?(leofigueres)
FYI, the possible fix has a problem (even if you ignore the breaking of an invariant regarding two different timers) - if we don't offset uniformly, we need to re-sort the array after adjusting.
Attachment #8653545 - Attachment is obsolete: true
Note: bug 1197152 is where this will get fixed; moving work there. This will remain a Thunderbird bug.
Assignee: rjesup → nobody
Status: ASSIGNED → NEW
Depends on: 1197152
(In reply to Heribert Slama from comment #51) > (In reply to WADA from comment #38) > > A possible(but never practically usable) workaround of this bug. > > Before Sleep/Suspend, go Work Offline, then after WakeUp/Resume, go Work > > Online. > > Toggling between offline and online mode *at any time* will (re-)establish > automatic mail check. Just click twice on the connection state indicator > after having resumed from hibernation. NOT working here... Alsop calendarpane is not updated. only fix is restarting tb
(In reply to StefanBlochberger from comment #60) > (In reply to Heribert Slama from comment #51) > > (In reply to WADA from comment #38) > > [...] > > Toggling between offline and online mode *at any time* will (re-)establish > > automatic mail check. [...] > > NOT working here... Alsop calendarpane is not updated. only fix is > restarting tb You're right (and I was wrong). My "work-around" worked - but only once:-<
I have the problem "Thunderbird not checking for mails" after resume from PC standby. But Thunderbird UI is still responsive (using HW acceleration). Thunderbird 38.2.0 on Windows 7 64.
(In reply to Aryx [:archaeopteryx][:aryx] from comment #52) > Created attachment 8653675 [details] > debug log with fix applied.log > > Thank you, the patch fixes the issue. > How can i apply the patch on TB (Win7 32Bit)?
Can someone here provide already patched exe files for windows? When will be the release of teh fixed version; Maybe as beta?
Will we get a notification when the fix goes into a nightly build? I for one would like to give it a try, and I'm sure others would also. Thanks.
Compiler is not working here ;( 1:20.08 checking for gcc... cl 1:21.54 checking whether the C compiler (cl ) works... no 1:21.54 configure: error: installation or configuration problem: C compiler cannot create executables. 1:21.54 ------ config.log ------ 1:22.13 This file contains any messages produced by compilers while 1:22.13 running configure, to aid debugging if configure makes a mistake. 1:22.13 1:22.13 configure:1184: checking host system type 1:22.13 configure:1205: checking target system type 1:22.13 configure:1223: checking build system type 1:22.13 configure:1302: checking for mawk 1:22.14 configure:1302: checking for gawk 1:22.14 configure:1387: checking for python2.7 1:22.14 configure:1497: checking Python environment is Mozilla virtualenv 1:22.14 configure:1718: checking for perl5 1:22.14 configure:1718: checking for perl 1:22.14 configure:3398: checking for gcc 1:22.14 configure:3511: checking whether the C compiler (cl ) works 1:22.14 configure:3527: cl -o conftest conftest.c 1>&5 1:22.14 c:/Users/Darkwing/tb-src/comm-central/mozilla/configure: line 3526: cl: command not found 1:22.14 configure: failed program was: 1:22.14 1:22.14 #line 3522 "configure" 1:22.14 #include "confdefs.h" 1:22.15 1:22.15 main(){return(0);} 1:22.15 configure: error: installation or configuration problem: C compiler cannot create executables. 1:22.26 *** Fix above errors and then restart with\ 1:22.26 "c:/mozilla-build/mozmake/mozmake.EXE -f client.mk build" 1:22.28 c:/Users/Darkwing/tb-src/comm-central/client.mk:361: recipe for target 'configure' failed 1:22.28 mozmake.EXE[1]: *** [configure] Error 1 1:22.28 client.mk:375: recipe for target 'c:/Users/Darkwing/tb-src/comm-central/obj-i686-pc-mingw32/Makefile' failed 1:22.28 mozmake.EXE: *** [c:/Users/Darkwing/tb-src/comm-central/obj-i686-pc-mingw32/Makefile] Error 2 1:22.29 0 compiler warnings present. 2 Darkwing@Darkwing-PC ~/tb-src/comm-central
Bug 1197152 has to be fixed, then this bug can't be checked if it still requires action. When that bug gets set to "Resolved Fixed", you should get an email notification (this might even apply if you haven't subscribed to that bug because this one depends on it - I don't remember anymore Bugzilla's default email settings). Stefan, for resolving the build issues, please visit the other developers in the #maildev irc channel on irc.mozilla.org. More details on IRC at https://wiki.mozilla.org/Irc
I hope this bug gets an accelerated fix into the field. I put work into creating bug 1199499, which is similar.
See bug 1197152 for the simplest patch to fix this; I hope I can land that today and ask for uplift. Uplift should be trivial and very safe. I don't know if Thunderbird cherry-picks fixes, but you may want to do so here.
Just a comment to users who are new to how bugs are handled: I'm also a user, but I've had a career in software development, so I've seen both sides of this coin. The Thunderbird and Firefox developers do a great job of responding to bugs in general and regression bugs in particular. I'm a heavy TB user and rarely have I encountered a serious regression bug. Great work folks! To this bug in particular, while serious, it is annoying, but NOT a show stopper. There is a simple work-around. Simply stop and restart TB. That would cause many product developers to lower the priority to fix, especially if doing so involves risk of introducing more regression bugs. That said, the TB developers have been very quick to take this one on, and after a relatively short time, seem to be close to a solution. I also point out that very few product developers give this kind of behind the scenes visibility to the bug fix process. We are very fortunate to be able to follow the progress, and even get access to a fix as early as the first nightly build it appears in. This was one of the reasons a long time ago I switched from Netscape to Mozilla. I found a serious bug in Netscape which I reported and got an automated reply that there was no promise of if or when it would be fixed. After a little searching I learned about Mozilla and its connection to Netscape, found my bug in Bugzilla, and grabbed the first nightly build that had the fix. That was before the Firefox and Thunderbird spin-off from the integrated browser (now Seamonkey). We are a very fortunate user community.
(In reply to tajkkj from comment #76) [...] > To this bug in particular, while serious, it is annoying, but NOT a show > stopper. There is a simple work-around. Simply stop and restart TB. (...) It has been over-cited, but: If you had a car where you had to disconnect the battery for a few seconds to reset the engine electronics to make it work normally after a repeating problem, would you think it's a minor problem, especially if the engine would continue to run in some odd way without that measure?
> There is a simple work-around. Simply stop and restart TB. (...) FYI. If "Simply stop and restart TB when you see unresponsiveness after each hibernaation" is annoying for you, "Using Tb 38.1.0 instead of problematic Tb 38.2.0 until this bug will be fixed" is a good practice. I believe "Loss by this bug" is far greater than "Gain by security fix in Tb 38.2.0" for general Tb users.
Can someone just compile a working version and post it here (win32)?
Whiteboard: [regression:TB38.2.0] → [regression:TB38.2.0][work to fix being done in bug 1197152]
Hi, I'd like to confirm this bug in TB 40.0 beta. Win7 64bit.
To clarify, I hope with greater precision about the need to wait for bug 1197152 ... Thank you for your patience and the feedback provided thus far. A notification that bug 1197152 is fixed is not sufficient to help Thunderbird users, because we may not immediately have a nightly build of Thunderbird available, nor does it indicate the bug is fixed in a Thunderbird beta. So when we have something which can be tested the information will be posted here, *explicitly*. Until then, there is likely nothing further useful to be done or posted here, or in bug 1197152, that will solve this more quickly or provide relief that is better than the workaround. WORKAROUND: Use version 38.1.0, or before Sleep/Suspend, go Work Offline, then after WakeUp/Resume, go Work Online. It has been noted here and reported elsewhere, that Lightning may be impacted and that going offline does not help. The following currently active calendar bugs have similar symptoms, which calendar folks are disecting. If you are having a calendar problem you will want to cc: on one of these bugs. Bug 1195338 - Thunderbird freezes after update to version 38.2.0 Bug 1199994 - Today pane date incorrect after overnight hibernate [TypeError: this.mDeferred is null] Bug 1200540 - Lightning today pane not updating after hibernating Bug 1195974 - Lightning 4.0.2 switches caldav calendards off and read-only when offline / Bug 1200713 - Periodically Calendar is switched off in Thunderbird 38.2.0
Whiteboard: [regression:TB38.2.0][work to fix being done in bug 1197152] → [status/workaround: Comment 81/waiting on bug 1197152][no more comments please][regression:TB38.2.0]
Suggestion: since this bug is fairly major, why not add a notice to the Latest Download page (https://www.mozilla.org/en-US/thunderbird/download) for each language? The notice could briefly describe the bug, and have a link for downloading version 38.1.0, which I understand is the version before the bug appeared. Of course, the notice will have to be removed when the fixed version is posted there.
As a former Web designer, I know that it is possible to convert a standard form into a form with an optional server-side box containing text. In most cases, this can be done in a few minutes (in my actual experience editing Web pages) so it's not a major impediment to providing important announcements like this one. As to a notice during an automatic update, there is probably already a mechanism to provide the user with a message saying that TB has been updated, so the notice can be added to that text as well. And certainly it will be included in the Release Notes, but many people do not read them each time there is an update.
I tried the suggestion by WADA to install version 28.1.0, but this does not work for me because version 28.2.0 is immediately and automatically installed. I suppose that suppressing automatic update is not difficult to do, but I don't want to do this because I have a tendency to forget such things. Why not just change the knowledge of the current version of TB back to 28.1.0 until the bug is fixed and released? I don't know why I didn't think of that in the first place.
(In reply to David Spector from comment #83) > As a former Web designer, I know that it is possible to convert a standard > form into a form with an optional server-side box containing text. In most > cases, this can be done in a few minutes (in my actual experience editing > Web pages) so it's not a major impediment to providing important > announcements like this one. What you think is possible and what IS possible are two different animals. The download pages are standardized, and part of a complex automated process. For these and other reasons we're simply NOT going to change the download pages. This is off topic to the purposes of this bug. Please take this converation somewhere else. If you are offering to help maintain our processes that would be great - please email me.
(In reply to David Spector from comment #84) > I tried the suggestion by WADA to install version 28.1.0, but this does not > work for me because version 28.2.0 is immediately and automatically > installed. I suppose that suppressing automatic update is not difficult to > do, but I don't want to do this because I have a tendency to forget such > things. If you found the option "Check for updates but let me choose whether to install them" to be insufficient, please email me privately
(In reply to David Spector from comment #84) > I tried the suggestion by WADA to install version 28.1.0, (snip) I never referred to 28.1.0.... I referred to 38.1.0 in my comment #78... Please never mislead other users...
Excuse me, please! I hope no one is mislead. This is a great example of my poor memory. This also shows an important problem with your bug reporting system. A poster should be able to edit a previous posting when it contains incorrect information!! I try hard to post only correct information, but I really can't do much about my poor memory. I'll try not to post in this thread again, sorry.
(In reply to WADA from comment #38) > A possible(but never practically usable) workaround of this bug. > Before Sleep/Suspend, go Work Offline, then after WakeUp/Resume, go Work Online. This seems a hint for the right approach: I wonder why the system cannot do "go offline" before suspend takes place and "go online" after the system is resumed (because it seems like a good idea to log out before suspend anyway, and to log in after being resumed). I'm no Windows programmer, but MSDN article "WM_POWERBROADCAST Messages" suggests that the events PBT_APMSUSPEND and PBT_APMRESUMESUSPEND could provide the information if registered via RegisterPowerSettingNotification. Despite of that I wonder why there aren't hotkeys to go offline/online, and I wonder why going offline and then online does not help after suspend. Without knowing the details I guess that some timer expired during the suspend interval, and when resuming the timer is not rearmed, most likely because the event that the timer had expired during suspend is lost. How is the proposed fix working?
Off-topic: (In reply to David Spector from comment #88) > A poster should be able to edit a previous posting when it contains incorrect information!! That's exactly the problem: If you were allowed to change a comment, first you could probably change any comment (not just your own), and you could not just fix a few errors when typing, but you could change the whole comment to say something new. As later comments may refer to earlier ones, editing could introduce inconsistencies, and people would have to re-read old comments again, as they could have changed. A solution I could think of would be "update comment" that would allow the same user (owner of the comment) to add a new comment (not to change the original) that is (now the important point!) sorted directly after the comment to update. That way comments would not always be in chronological order, but that's off-topic. Sorry!
going offline before hibernate and going online after is not working here on my win / 32 bit. Found a lot of thgat kind of messages in log: 2015-09-03 16:11:23 gloda.index_msg WARN Observed header that claims to be gloda indexed but that gloda has never heard of during compaction. In folder: mailbox://nobody@Local%20Folders/Inbox sketchy key: 109064567 subject: Nicht verpassen! Süddeutsche und SPIEGEL mit Top-Angebot!
An adjustment approach like comment 50 seems like a reasonable way forward, given bug 1197152 comment 47. I'll keep poking at it and/or listening to feedback from folks on what timers should do during suspend.
Flags: needinfo?(nfroyd)
(In reply to Nathan Froyd [:froydnj] from comment #92) > An adjustment approach like comment 50 seems like a reasonable way forward, > given bug 1197152 comment 47. I'll keep poking at it and/or listening to > feedback from folks on what timers should do during suspend. Uplifting such complex code seems pretty scary to me. We also have no testing of wake-from-sleep whatsoever, which makes this even scarier.
Thunderbird worked as expected after powering on the computer after it had entered hibernation mode. Tested on OS X 10.10.5. Sorry for the delay in my response. OS X desktop users need to change some settings in order to enable hibernation mode and it was not a recommended procedure, so I need to wait until my more important work was finished before testing this bug.
Flags: needinfo?(leofigueres)
Comment on attachment 8653928 [details] [diff] [review] possible fix; use with NSPR_LOG_MODULES=nsTimerImpl:3 Review of attachment 8653928 [details] [diff] [review]: ----------------------------------------------------------------- ::: xpcom/threads/TimerThread.cpp @@ +816,5 @@ > + } > + } > + mTimers.SwapElements(timers); > + } > + This white-space should be removed.
With the dependent bug now resolved, it would be good if some could confirm that this is fixed in the next Thunderbird nightly. The dependent bug has also been requested for uplift to esr38, if so that would put it automatically in TB 38.3.0 If that gets rejected or delayed we will consider taking that patch on our mozilla esr38 branch.
(In reply to Kent James (:rkent) from comment #98) > With the dependent bug now resolved, it would be good if some could confirm > that this is fixed in the next Thunderbird nightly. I'm only a user, but I'd be happy to install the latest nightly. However, when I look at http://ftp.mozilla.org/pub/thunderbird/nightly it's not clear to me what I need to grab. A pointer would be most welcome. I'm using Windows 10.
The fix will be in tomorrow's (Sep 10) *Firefox* nightly. Not sure when that maps to a Thunderbird nightly.
Thunderbird daily builds at https://archive.mozilla.org/pub/thunderbird/nightly/latest-comm-central/ But you will want tomorrow's build dated 2015-09-10
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #101) > Thunderbird daily builds at > https://archive.mozilla.org/pub/thunderbird/nightly/latest-comm-central/ > But you will want tomorrow's build dated 2015-09-10 I just downloaded and unzipped thunderbird-43.0a1.en-US.win32.zip from the above dated 10-Sep-2015 11:57. Executing the thunderbird.exe from this, I verified the version as 43.0a1 (2015-09-10). After a brief hibernation of about 5 minutes, I awakened my computer, and sent myself a test e-mail from another computer. This message was pulled in automatically shortly thereafter. It's possible that my hibernation time was too short. I don't know how long a hibernation is required to see this bug. Assuming I do have the correct nightly to test this, I'll try a longer hibernation, and report the results here.
Yes, I think you need longer hibernation. After hibernation the mail is not fetched for the same interval as you were in hibernation (comment 41). So 5 minutes is not much of an indication.
The bug is fixed in nightly? if yes where do i get an de_DE version?
After a 2 1/2 hour hibernation with the nightly 43.0a1 (2015-09-10) I referenced above, I found it did check for messages automatically. I then sent myself an e-mail from another computer. The receiving account is set to check for new mail every 5 minutes. That message also was received automatically. As an aside, if you had the Lightning add-on enabled, this version of TB does not find it compatible. Might just be a version check issue.
I posted asking for feedback in SUMO topics which have a combined ~60 interested persons, but so far no feedback. That's a lot of people, but unfortunately SUMO feedback is typically spotty, so I'll be surprised if we get info from SUMO before the weekend.
Compiled Thunderbird myself and after sending a mail to the account which got checked and hibernating the machine, it fetched the mail a few seconds after waking it up.
After a 13 hour hibernation with the nightly 43.0a1 (2015-09-10) I referenced above in comment 105, I found again it checked for messages automatically shortly after coming out of hibernation.
(In reply to tajkkj from bug 1197152 comment #68) > If I understand the relbranch for TB correctly, the idea would be to put the > fix for this bug into the ESR for TB. As one of the many users affected by > bug 1196662, I would urge this fix go in as quickly as feasible for TB. This > affects TB for everyone who hibernates or sleeps their devices. For devices > which are put to sleep several times a day, the work-around for bug 1196662 > is more painful than for us who only hibernate or sleep our devices at > night. That work-around is closing, then restarting TB. Forgetting to do > this means not receiving new e-mails until one remembers to recycle TB. For > critical endeavors, this could be costly. tajkkj, et al, Thanks for your diligent testing. We know this is a serious issue, and thunderbird drivers already plan to take the patch for Thunderbird 38.3.0 as Liz alludes to in bug 1197152. Watch here for a patch landing. Until then there is nothing more to be done or said. Send me a private email if you'd like to help test 38.3.0 when we are getting it ready to ship.
"I would urge this fix go in as quickly as feasible for TB. This affects TB for everyone who hibernates or sleeps their devices." Note also that several other bugs were closed as being duplicates of this one, and that those bugs are also in need of verification (to see if they were fixed). For example, several bugs reported that incoming email was not always read every N minutes, as specified by the user. They reported random and inconsistent message loading times. At least one other bug reported malfunctions when the reading time was set to times other than exactly the default value. And I think I remember other bugs that may or may not have been related to sleep/hibernation, and were closed as duplicates. I'm not objecting to their having been closed, I'm just suggesting that all reported problems in such bugs ought to be verified, not just those listed in this bug. In my experience, in general, thorough testing early saves much more work later. With that proviso, I heartily agree on the need for a speedy release to everyone affected by this bug.
I think this is related to TB38 With SM 2.35 (based on TB38) I can not confirm the "becomes unresponsive" problem, but the lacking reliability of automatic download.
Version: unspecified → 38
Seamonkey 2.35 has the same bug, not only after hibernation but also after sleep mode it does not check for new e-mails but regretfully I found that it did not check for new e-mails automatically at all.
So can someone clarify please, this bug has been fixed in the nightly, but Lighting calendar doesn't work with them. If that is the case, can a developer please confirm when the next full release will be made available? Using a nightly to fix one minor problem, only to create another major problem (no access to calendar) is not an option. Thank you.
(In reply to Dean from comment #114) > So can someone clarify please, this bug has been fixed in the nightly, but > Lighting calendar doesn't work with them. See https://developer.mozilla.org/en-US/docs/Mozilla/Calendar/Calendar_Versions > If that is the case, can a > developer please confirm when the next full release will be made available? As previously stated, version 38.3.0. point releases are roughly every 6 weeks
I agree that making an addon fail should also be fixed. A bug fix should not create a new bug. Allowing that would not have been accepted in most companies I have worked for. Why should it be accepted for a public and heavily-used project like Thunderbird? On another issue, 6 weeks is a long time to wait for a significant bug fix. Why can't the TB team add a protocol for moving a bug fix through the system more quickly? It could be called 38.2.1. Or, if that is not acceptable, call it 38.3.0 but release it in two or three weeks instead of 6. I have already offered to help in the testing in my small way, and my email to the responsible party (Wayne) has not even been answered. Let's really believe in bug fixing and get this thing moving.
If you follow this and related bugs closely you would know the fix wasn't available until the past week. So no one will be waiting 6 weeks for a fix. Please take this type of conversation somewhere else. > I have already offered to help in the testing in my small way, and my email to the responsible party (Wayne) has not even been answered. Let's really believe in bug fixing and get this thing moving. If I were a less patient person I would say this is getting rediculous - please stop pestering. The patient answer is, you will receive a response when there is relevant information worth communicating - right now, there is not. You might assume we know what the heck we are doing.
Thanks Wayne. I don't fancy messing about with nightly and beta builds of Lighting as I or it will only likely fix one issue and create another. In the mean time I think I will just close/open Thunderbird again after restoring PC from hibernation until 38.3.0 is released.
I apologize for my sudden impatience. Won't happen again.
Feel free to delete my last three posts. I'd do it myself if I could.
We'll need a bug to manage the uplift of patches for bug 1197152 to THUNDERBIRD_38_VERBRANCH. Is there any reason why we can't morph this bug to that purpose? Otherwise we'll just dup it to there instead.
(In reply to David Spector from comment #116) [...] > On another issue, 6 weeks is a long time to wait for a significant bug fix. Remember you can press F5 to check for new messages whenever you need it ;-)
Landed patches for bug 1190735 and bug 1197152 on THUNDERBIRD_38_VERBRANCH which are intended to fix this bug, for TB 41 and greater patches accepted by mozilla-*. This bug should be fixed by those changes.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
I am not 100% sure if there is a causal connection but the effect started with the last Firefox/Thundbird Updates: If I only restart Thunderbird after hibernation Firefox sometimes behaves strangely. Example: FF doesn't create new tabs if an external application (like RSSOwl) calls a new page. I see then all FF tabs in the task bar but FF has only one tab for two different pages. So, after hibernation I have to restart both, TB and FF.
Whiteboard: [status/workaround: Comment 81/waiting on bug 1197152][no more comments please][regression:TB38.2.0] → [Fixed by bug 1197152][status/workaround: Comment 81/waiting on bug 1197152][no more comments please][regression:TB38.2.0]
Patch is available in 41.0b2 from https://www.mozilla.org/en-US/thunderbird/all-beta.html So far everyone reports success, and no one has reported bad side effects
Sound like it can be the same as Bug 1208746, although I use Power Save Mode, and it does check mail sporadically. And restarting TB is not needed as someone here says, pressing the "check e-mail button" manually is sufficient. Anyway, good to know it's a know bug so there's hope it will be fixed.
There seems to be a regression in 38.7.2 and earlier.
I'm at TB 38.7.2 and just came out of a night long hibernation. Mail was fetched upon resumption from hibernation as expected. I'm running Win 10 on Intel 64 bit hardware.
(In reply to Ralf Kuhn from comment #132) > There seems to be a regression in 38.7.2 and earlier. (In reply to Tim Johnson from comment #133) > I'm at TB 38.7.2 and just came out of a night long hibernation. Mail was > fetched upon resumption from hibernation as expected. I'm running Win 10 on > Intel 64 bit hardware. If this reproduces with Thunderbird started in safe mode, then please file a new bug report or support request with all your details.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: