在最新的 Tb 31.2.0 上，HTML 编写功能已禁用，并且没有签名，我经常体验一下：我打开一个新的/空白的撰写窗口，或者点击回复，然后开始在主区域输入内容，结果发现 Tb 似乎没有响应。5-20 秒后，我执行的每个按键或鼠标点击都会突然生效。之后，它可能会顺利完成其余的撰写，或者对于平均 1-2 段的电子邮件，这种情况可能会再次发生一两次。我在 Windows Server 2003 和 Linux Mint 17 上都遇到过这种情况，这两个版本都是 32 位版本。
据我所知，我没有安装日历插件或任何与作文相关的插件（Linux 上只有 DivX Web Player、Google Talk、IcedTea、QuickTime、Shockwave Flash、VLC、WMP，还有 Messaging Menu 和 Unity Launcher integration 1.3.1 扩展，但没有其他的；Windows 上没有任何扩展，还有 Foxit、MS DRM、Shockwave、Silverlight、MS WPF-- 这两个平台上都是默认的）。在 Mint 上，我通过 IMAP 访问 Gmail，有一个巨大的收件箱；在 Windows 上，我通过 POP 访问私人服务器，我的收件箱里有不到十几封电子邮件（其余的则根据年份放在存档文件夹中）。我禁用了全局搜索和索引器。在 Windows 上，我禁用了操作系统范围的文件索引服务。
我还没有尝试过安全模式，但我很好奇视频播放器插件或弹出集成扩展如何会对文本编写窗口造成如此有害的干扰。我很想切换到 CLI 来处理电子邮件。基本操作不应该那么痛苦……
更新：刚才在 Linux 的安全模式下，我手动永久禁用了每个插件，当我在附加组件窗口中遇到类似的事情时，在“始终激活/永不激活”下拉菜单响应我的初始点击之前有 5 秒钟的延迟。
答案1
我想我找到了原因。有一天我从终端运行了 Tb 并观察了它。就在发生扭曲时，终端中出现了两个这样的新条目：
1423554445542 addons.update-checker WARN HTTP Request failed for an unknown reason
...这可以解释在附加组件屏幕上发生的相同扭曲，有点（在那里比在撰写窗口更有意义。）
我使用 Tb 中的配置编辑器将其设置extensions.update.enabled为 false。当然，这样做存在风险，但可能有助于缩小范围。从那以后我再也没有遇到过这种情况，但我们拭目以待。
更新：我再次遇到了这种情况（扭曲，而不是日志），但等待时间短得多，约为 1.5 秒。
更新 2：该问题仍然发生，Tb 31.7.0。