Environment: * Windows 7 SP1 x64 * Mozilla Thunderbird 24.3.0 I've tested this behaviour right now using Mozilla Thunderbird 24.3.0 but it has been regular Thunderbird behaviour ever since I can remember. To reproduce you need to set up a Mozilla NNTP account. In my case, the account is connected to and named after the news.gmane.org NNTP server and is subscribed to the following newsgroups (content of my profile's 'news.gmane.org.rc' file): gmane.comp.encryption.openssl.announce: 1-116 gmane.comp.encryption.openssl.devel: 1-24050 gmane.comp.encryption.openssl.user: 1-51003 gmane.comp.ide.eric: 1-3723 gmane.comp.lib.boost.announce: 1-396 gmane.comp.lib.boost.build: 1-26378 gmane.comp.lib.boost.devel: 1-249889 gmane.comp.lib.boost.documentation: 1-5089 gmane.comp.lib.boost.threads.devel: 1-629 gmane.comp.lib.boost.testing: 1-7696 gmane.comp.lib.boost.user: 1-81282 gmane.comp.parsers.spirit.general: 1-26402 gmane.comp.python.cx-freeze.user: 1-1792 gmane.comp.python.devel: 1-146364 gmane.comp.python.general: 1-755083 gmane.comp.python.pytest.devel: 1-184 gmane.comp.python.tulip: 1-1975 gmane.comp.version-control.git: 1-244202 gmane.comp.version-control.msysgit: 1-19656,19665-19920 gmane.comp.version-control.subversion.devel: 1-145881 gmane.comp.version-control.subversion.user: 1-116351 gmane.comp.version-control.subversion.tortoisesvn.user: 1-38647 gmane.comp.version-control.subversion.tortoisesvn.devel: 1-42292 gmane.comp.version-control.subversion.tortoisesvn.announce: 1-31,34-39,50-99 gmane.comp.version-control.subversion.trac.announce: 1-33 gmane.comp.version-control.subversion.trac.devel: 1-7995 gmane.comp.version-control.subversion.trac.general: 1-35955 Once you have an NNTP account set up, select it in the main tree-view control on the left side of Thunderbird's GUI and press <F5> to get new messages for the current account. This gets new messages for the selected NNTP account but also seems to, at least partially, block the main GUI thread while it does so. While the 'refresh' operation is doing its work, mouse clicks on the GUI are handled only sporadically, seemingly only after Thunderbird finished updating messages for one newsgroup and just before it moves on to updating messages for the next one. GUI operations such as: - selecting a message - selecting a message folder - expanding/closing a node in the main tree-view control - opening/closing a main menu item should be prompt and not lagging. Their processing should not be delayed just because a NNTP account content refresh operation is currently running. Note that this does not occur with regular mail accounts, e.g. POP3, which seem to be processed correctly in a separate worker thread. Hope this helps. Best regards, Jurko Gospodnetić

Jurko, thanks for your time to share this problem, which is well described (and looks correctly analysed to me). We rely on volunteers to fix such bugs in TB. Can you assist with fixing it? Magnus, can you confirm this technically or CC someone who knows about this?

Let me know what help you need and I'll see what I can do. Just keep in mind that the last time I built Thunderbird from sources was about a year ago, and that was to test run some PKCS#11 modules, so I am not well versed on how your code-base functions. Best regards, Jurko Gospodnetić

I don't know, but i would be a bit surprised if it's true.

(In reply to Magnus Melin from comment #3) > I don't know, but i would be a bit surprised if it's true. Need a .mpeg to convince you? ;-) *gdr*

We can't easily run NNTP off the main thread without rewriting a few thousand lines of code. I've had ideas for how to rewrite the protocol backend using JS, but the necessary web APIs are still under major development and unsuitable for use yet. In bug 717016, I posited some rules on handling the pending URI queues which would fix all of these problems. Since then, however, I've been tied up in other work and haven't been able to return to working on NNTP.