BYOND Version:494.1129
Operating System:Windows 7 Pro 64-bit
Web Browser:Chrome 18.0.1025.142
Applies to:Dream Seeker
Status: Unverified

Thus far we've been unable to verify or reproduce this bug. Or, it has been observed but it cannot be triggered with a reliable test case. You can help us out by editing your report or adding a comment with more information.
Descriptive Problem Summary:
As far as I can remember back in 493 I never had this problem: when messing with a browser control sometimes the focus is reset to the input element of the skin.

This seems to happen when there's a piece of Javascript which is taking up time.

Numbered Steps to Reproduce Problem:
1. Download this source code and put it somewhere on your system.
2. Goto config/admins.txt and give yourself "Game Master" access.
3. Host the game with DreamDaemon (it does not have to be hosted publicly) and connect to it.
4. The game will take some time to load. Once geometry has finished processing click the "Declare Ready" button.
5. You can use the "edit ticker variables" verb to modify a global datum. Set it's "pregame_timeleft" to "1" to start the game early.
6. Use the "game panel" verb. It will bring up a browser window. Click "create object".
7. This brings up another browser window. For me the issue occurs when you start typing in the "filter" tab. This takes quite awhile because it uses Javascript to check a huge list and repopulates the select multiple tag below. Needless to say when typing something in (like "effect") the browser screen will freeze up.
8. After this the screen inexplicably sets focus to the input element even when you do nothing but type in the browser screen. If you type "effect" then it might put the first two letters ("ef") in the <input> element of the browser and the remainder ("fect") in the input element of the skin.

I hope I've been clear enough in its reproduction. If I wasn't, I'll elaborate with a screenshot.

Expected Results:
Even when some (poorly written) Javascript causes a browser control to freeze up the focus shouldn't be reset to the main skin unless I actually click on it.

Actual Results:
The focus is inadvertently reset to the main skin, making the process of filtering to a specific type even more tedious.

Does the problem occur:
Every time? Or how often?
Every time.
In other games?
In other user accounts?
On other computers?

When does the problem NOT occur?
The problem does not occur when the amount of items that is shown in the select list is below a certain amount. So: it does not occur when the Javascript does not cause the browser control/window to freeze.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit to download old versions for testing.)
To the best of my knowledge it did not occur in 493. In 493 if you start typing something in the field it will still freeze the browser control but it won't reset the focus unless you click outside of the browser element.

I could go back to 493, but I'd be missing out on the fix for the mousewheel (great job by the way!) that is probably causing this issue (which is much less of an annoyance than the mousewheel issue was, so again thanks).
This is ridiculously untestable, so I'm going to try with something simpler. Compiling the project took ages, and the startup was equally glacial. Once the startup died down and DD was responsive again, I tried to join in DS and DD started sucking up the CPU again, not stopping till I eventually closed down DS (which had yet to even load the skin) several minutes later. In addition, there must be several other config changes needed, because it was trying to access files in a /home dir that I don't have (not being on Unix).

I'll probably need a sample of something like the JS you're using in order to progress on this. One thing I can verify is that there is no particular new code that should be grabbing focus on behalf of an input control. However the input control does try to grab focus if a WM_CHAR message makes its way to the main window, and the macros in use don't contain any simple character macros (e.g., A). My analysis based on limited information suggests the problem is not new to 494. There was a change to the browser control's key handling some time ago, but only regarding the enter key, and the mouse wheel change doesn't disturb any of the existing keyboard code.
Lummox JR changed status to 'Unverified'