Bug #111


Problem with the historywindow

Added by Moritz Wolfart over 6 years ago. Updated over 4 years ago.

User interface
% Done:


Contact person:
Additional contact persons:


Hi again!
Sometimes i cant read out the history. The up arrow is giving me a list of typed commands and not the output of the mud.
And sometimes the up arrow gives me an early part of the history.
Am i doing something wrong?

Actions #1

Updated by Vincent Le Goff over 6 years ago

This is probably two different bugs, or I might say, two strange behavior that are not really bugs.

The first is that CocoMUD works in two modes: the whole window as the output window (this is the default) or the selection of typed commands. If you press escape, you will go through one mode to another. So if you connect to a game, type some stuff, then press escape and up arrow, you will see the commands you just typed. And up again to see the one-before last command. And so on. You can press escape again to go back to the output window. This has been set because some users don't really appreciate the alternative of command history CocoMUD offers.

The best way to use command history (as far as I'm concerned, anyway) is to use the CTRL + up and down arrow keys. This will bring the commands that were typed, just like up and down arrow in lock mode, but it won't lock anything. You can still use the arrow keys to browse the output field. Personally I find it more comfortable to use, but it requires some adaptation when you come from MUSHclient or another client that uses arrow keys for command browsing. This is explained in CocoMUD basics.

Regarding the second bug, I believe, if I understand correctly, this is another freeze of the window. It happens because (AGAIN!) of rich text. Sadly it often happens with Jaws. I never had the issue with NVDA, but some users have told me they sometimes had it. The behavior is that you play for awhile, then when you go to the end of the file with CTRL + end, instead of showing you the last line of output, it shows you a line much earlier in the history, often almost at the top, and going down with the down arrow key doesn't change anything. This is what I call window-freezing: the window is correctly updated, but screen readers are lost. The way to fix it is to disable rich text altogether. This can be done in the preferences window, accessibility tab. Uncheck the rich text box and make sure the support for screen readers (next box) is checked. You will have to restart your client but this should improve your navigation and shouldn't do anything noticeable, except reduce errors and lags.


Actions #2

Updated by Moritz Wolfart over 6 years ago

Yeah, i see. I will observe this a little bit closer and tell you later.
I especially like cocomud cause in most cases you don't get this what you called window-freezing.

Maybe you could add some messages for the screenreade when you press escape so that you know to which mode you changed. But that's only a little little idea.

Actions #3

Updated by Vincent Le Goff over 6 years ago

Displaying a little message (or making some sound) when going through lock mode to output mode should be done, it would be much better. For the time being I haven't been able to figure it out, since it's done in another project, but I will find a solution!

Actions #4

Updated by Moritz Wolfart over 6 years ago

Oh, thats strange. The RTF-Option is disabled but sometimes i got this window-freezing.
Maaaaaybe this problem could be based on the fact that this is a console-aplication?

Oh! while i am typing this i maybe got an idea how to fix it in NVDA. I think it depends on how many lines are on the screen.
Sorry, i am allready too tired to explain it in the wright way!:-)
But i will try some changings in the NVDA-configuration.
Maybe this will fix it!
Have you thought about to get in contact with the developers or the community of NVDA? Maybe they could help you with this window-freezing.

I also got another little idea for a workarround. Maybe you could add an option to export the hole history to a TXT-File?
I would like it cause sometimes i keep my history for checking some stuff about recipes or other lists.

I will tell you tomorrow if my configuration experiments will have any effects.

Best wishes from Germany!

Actions #5

Updated by Moritz Wolfart over 6 years ago

Sorry to tell you this, but i often got the freezing-bug. RTF is disabled so this doesnt change anything.
I think one time i overcome the freezing but i am not sure.

Have you thought about getting in contact with the NVDA-Community? Maybe they can give you some notes what you can try to fix this strange behaviour.

What makes it realy realy strange is, that after the freezing i still can work with the special Screenreader-cursor to read out all new stuff. It is only a problem when i want to use the arrow keys.

I will contact the german NVDA-Community to ask them one thing wich maybe will give a little workarround.
I let you know if it works.

Best wishes and let me say again, that even with this little bugs i love Cocomud very much!

Actions #6

Updated by Vincent Le Goff over 6 years ago

It's definitely a sad news. I thought I had fixed this issue and I don't get it at all. Do you have a way to always reproduce it? A game and a command that always freezes the application? I looked at my notes and it has nothing to do with rich-text actually, although rich-text enforces it somehow. The next box should be checked, to activate screen-reader support. This box is a bit generic in name, but when checked, it should avoid freezing... in theory.

I haven't contacted NVDA yet, because the first thing they will ask is a clear step-by-step process to reproduce the issue, and so far, I haven't been able to find one. I could say that it seems to happen most on some games, but at other times, I was able to play to these games for hours without any trouble. And sometimes it froze the window when I opened the game. But nothing seemed to trigger the problem at all times (and as you noticed, the freezing is only in the screen reader window, the screen is updated as expected).

Actions #7

Updated by Moritz Wolfart over 6 years ago

Hey hey!
I think it had something to do with the Beta-Version. I am updating very often so maybe this caused the freezing. Since my last update i did not have any freezing till now. So i will keep this Beta-Version of the Screenreader and lets see what will happen!
So dont be sad!

Actions #8

Updated by Vincent Le Goff over 5 years ago

  • Tracker changed from Feature to Bug
  • Category set to User interface
  • Assignee set to Vincent Le Goff
  • Priority changed from Normal to High


Are you still experiencing issue with freezing? I asked several users and they tell me it seems stable so far, and CocoMUD hasn't been updated in awhile. I'm planning on a new, long-term sprint (which doesn't make it a real sprint) so I would investigate more this issue if it's still active.

Actions #9

Updated by Moritz Wolfart over 5 years ago

Hey hey!

Let me first say, i am absolutely glad you are still working on this so
very nice client!

The history-problem themes to be gone.

But i encountered another one.

Shall i open a topic or send you another Mail about it?

Best wishes!


Am 08.10.2018 um 13:43 schrieb CocoMUD Planio:

Actions #10

Updated by Vincent Le Goff over 5 years ago

After a long pause I'll be working on CocoMUD again, but I'll be focusing on optimization first, as there are major fixes here that would speed the client up in the end, though I noticed no one complained too loudly (perhaps because I don't have thousands of users just yet). It might be best to post a new issue, that way I will be able to track it independently. Thanks!

Actions #11

Updated by Vincent Le Goff over 4 years ago

  • Status changed from Open to Closed
  • Sprint/Milestone set to 17
  • % Done changed from 0 to 100

Closing this, as it seems to be fixed.

Please register to edit this issue

Also available in: Atom PDF Tracking page