A more interesting Web UI problem....

On experimenting a little further, I’ve encountered a very odd problem. In attempting to trouble-shoot it, I’m pretty sure I’ve restored cmdwin.css, cmdwin.htm, and cmdwin.js to their original state (by commenting out or simply deleting my new code).

What I’m seeing is that in the game interpreter (running as an adjunct to Workbench), a bunch of command-line inputs at the start of the game are being ignored. The carriage return is read, but the command line is empty. No letters appear when you type. Before too long the game starts responding normally. Here is a transcript. (I’m using the introductory game, which is definitely in an unedited state.)

Once we reach that point, the command line starts working normally.

This could be related to the function called setInterval(), near the top of cmdwin.js, which Mike describes in the comments as “a workaround for an annoying IE bug.” Or not. The comment for that function suggests that IE is putting the input focus in the wrong place, and that certainly seems to be similar to what’s happening here.

Hitting the escape key causes the blinking text input cursor to reappear at the command prompt, thus allowing a new keyboard input.

Can anyone confirm this behavior? My next step is to go back to the default cmdwin files and double-check…

Can you try applying the fix from this issue to your main.js?
bugdb.tads.org/view.php?id=136

The first part of the quoted code (desc.keyBufferedInMain) is at line 1718 in the 3.1 copy of main.js. The second part is the fix: discard ‘\r’ keys from the buffer.

Your input makes it look like some other issue may be at work; even with the spurious carriage returns, you should see your commands with blanks interleaved, not all the blanks followed by all the commands.

Applying your patch to main.js didn’t help, but I’ve found the source of the problem, and I think it’s something MJR needs to be aware of.

I had not upgraded from IE 8, because I never use IE. I use Firefox (and occasionally Chrome). It occurred to me that Workbench was quietly accessing IE in order to run the interpreter, so I downloaded and installed IE 9.

Presto – the problem vanished.

What this means is that somewhere in the Javascript (most likely in the area that reads the input from the command line) there’s a compatibility problem with respect to older versions of IE. This would not be at all surprising, given how eccentric (and that’s a charitable term) Microsoft’s engineers are about their implementation of Javascript in IE.

In any event, IE 8 is probably still in wide use, so the T3 Web UI needs to support it. I haven’t tested whether this problem shows up in online play with IE 8, but it’s something that needs to be looked into.

Thanks for tracking this down. I’ll fire up a virtual machine running IE8 next week and see if I can find a fix.