Can't change beacon number and module at the same time

[super-aardvark]

1. Focus the Beacon text input
2. Type a number (don't change focus)
3. Hover any module selector
4. Click to change the module selection

Actual result: The module selection is ignored (though the number is updated). Expected result: The module I clicked should be selected.

[KirkMcDonald]

Fixing this is possible, but will be somewhat annoying.

In the current implementation, the entire tree of nodes that displays the solution is recreated from scratch each time it changes. It turns out that this can interfere with event handling: The event triggered when the beacon count changes prompts the entire window to be destroyed and re-created, which prevents the second event, which changes the module, from being triggered. (By the time it goes to handle that event, the entity has been destroyed and replaced, and is no longer present to be clicked on.)

Fixing this essentially requires re-writing display.js to use persistent objects representing the solution, and only deleting nodes from the DOM when they are actually no longer needed. (In other words, making it more similar to how target.js works.)

This is actually not a terrible idea, and may be worth exploring for the performance benefits alone. (Although these performance benefits will still largely be dwarfed by the cost of computing solutions in the first place.) It may also result in simpler code. display.js is basically one enormous function that draws everything. This hypothetical new design would consist of a tree of objects that communicate changes only as needed.

TL;DR: I'll probably fix this eventually, but it isn't simple.

[super-aardvark]

What if the mouse-over event that displays the module options were to pull focus? That (I think) would trigger the text input's onChange event, and re-draw everything before the user got around to clicking.

And, in fact, now that I'm fiddling around with it, it seems that (in Chrome at least) the little up/down arrows of the text input field have this effect on mouse-out (unintentionally, I assume) -- I think it would work pretty well as a mouse-over effect on the modules, as long as the re-build didn't prevent the module selection from opening.

[KirkMcDonald]

There is no mouseover event handler that pops up the module dropdowns. That is done through pure CSS :hover trickery. Adding a mouseover handler would be possible, but a hack.

The destroy/rebuild thing does indeed interfere with the little arrows on the number-input field, too, though I'm not clear on what, precisely, the behavior there is. All I know is that when you destroy and replace a number-input field out from under the mouse like that, the little arrow buttons get very confused.

The re-write I'm thinking of would correct this issue, as well.

[KirkMcDonald]

I have substantially rewritten display.js in 336b83076ea57748729a608d28a7f6ad0c2c025f to operate in retained mode, rather than immediate mode. This improves the performance of many operations, simplifies the organization of the code, and incidentally fixes this bug.