Bug #96
closed
CocoMUD freezes its window at unexpected times
Description
Sometimes, at random moments, the client just freezes its text field. One can still type commands and the result is read by the screen reader, if the text-to-speech is enabled. However, reading by line doesn't work. With some screen readers, only the lines at the top of the window are visible. With others, nothing is visible at all (the screen reader just see "blank" everywhere). Some screen readers are happy if the tab is closed and re-opened. Some needs a system reboot.
This bug is tricky, hard to identify and reproduce. It doesn't seem to happen very often. Some have pointed out that it seems to happen more frequently when the audio prompt is read, but there's no way to clearly pinpoint the origin of the problem for the time being.
The origin of the issue seems to be in the AccessPanel's freezing / thawing too rapidly.
Process¶
After long debugging, I finally identified a way to reproduce the bug. Opening two different tabs in the development version (running with Twisted) seemed to increase the likelihood of the issue occurring. With a way to reproduce the issue, I played with locks which seemed a fair assertion, seeing Twisted was running on its own, asynchronous loop, but the GUI was still running using wxPython threads. This didn't prevent the issue from happening, however. I then removed all locks, except at the top-level (keeping a single lock for the window, not one per MUDPanel). I also removed the freezing/thawing of the panel, which had been added for sighted users, to prevent the window to "blink" too rapidly. The issue was fixed at once. It seems the origin of the problem is that screen readers don't really appreciate a text to freeze and thaw too often. As pointed out, it could happen 1000 times without causing any error, but sometimes, it would crash and the screen reader would react badly.
Please register to edit this issue
Also available in: Atom
PDF
Tracking page
.
Fix #96 with AccessPanel 0.15