Thunderbird 26 occasionally locks up, switches windows and loses input text - or applies it as commands

RESOLVED INCOMPLETE

Status

Thunderbird
Untriaged
--
major
RESOLVED INCOMPLETE
4 years ago
3 years ago

People

(Reporter: Jim Klimov, Unassigned)

Tracking

({perf})

26 Branch
x86_64
Windows 7

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
User Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)

Steps to reproduce:

My ThunderBird Beta 26.0 running on Windows 7 x64 is connected to a dozen mailboxes, and a few other services including some Lightning calendars, a couple of LDAP "Address books" and an XMPP Chat client. 
Every once in a while (irregularly) all of the Thunderbird windows become "Unresponsive" and can stay in this state for several seconds up to a minute. I guess this may be due to client's queries of some inaccessible servers, and poor threading (i.e. a blocked thread hangs the whole process) - but this is only an educated guess.
When I browse and read the messages this is just annoying. But when I compose messages, the text which I input into the Compose window may later become part of the message as intended, but at about 50/50 chance the main window would pop up as the top window and catch all the input from the "hung time" - so the typed characters would be interpreted as commands for the message list - such as deleting, archiving, marking read and causing other serious mayhem.
I believe I had a similar problem a few years back (reported it - but can't find in the tracker), and I think it was resolved successfully for many releases. Now, again, this nehaviour became unacceptable :(


Actual results:

All of Thunderbird windows became unresponsive while I was typing messages. When the program became responsive again, another window (the message browser) has a high chance to have captured the input and interpreted it as message management commands - not intended by myself.


Expected results:

Even if the lock-up is unavoidable for some reason, the Compose window should remain active after the un-freeze. In a perfect world it would also remember and reapply all the text that I might have typed while the program was frozen (indeed, it does often happen this way, unless I used language-switch commands, arrow keys, etc.)

Comment 1

4 years ago
Start *Windows'* safe mode with networking enabled
- win7 http://windows.microsoft.com/en-US/windows7/Start-your-computer-in-safe-mode

Still In Windows safe mode, start thunderbird in safe mode
- http://support.mozillamessaging.com/en-US/kb/safe-mode

Does problem go away?
Severity: normal → major
Flags: needinfo?(jimklimov)
Keywords: perf

Comment 2

3 years ago
Jim, we'll need your involvement to move this forward
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(jimklimov)
Resolution: --- → INCOMPLETE
(Reporter)

Comment 3

3 years ago
Sorry about that delay, due to both personal issues and that this workhorse of a laptop is always on to many sessions that it was not comfortable to reboot it.

TB (32b1 now, but still connected to those several accounts with approx a million messages altogether) did lock up for up to a minute while I was reading a stack of emails, mostly noticeable while I was scrolling through the larger messages. I did not manage to reproduce the lock-ups while typing a message, however. But maybe I just did not have enough time to give it for the coincidences to fire...

This happened with windows same+net mode and both TB normal and addons-disabled modes. According to the status bar, it was busy refreshing an account with 4000-some messages in the inbox, then deleting some (probably spam-tagging along the way), so it seems to me like a problem with (lack of) thread-decoupling between the working and visualisation layers of the program. :(

100% of one CPU core (49-50% overall on a dualcore laptop) was consumed all the time by TB.
You need to log in before you can comment on or make changes to this bug.