I believe why it works in some instances is because there are two sets of event handler setups:
$("movetop") && e.connect($("movetop"), "onclick", this, "onMoveTop");
$("moveleft") && e.connect($("moveleft"), "onclick", this, "onMoveLeft");
$("moveright") && e.connect($("moveright"), "onclick", this, "onMoveRight");
$("movedown") && e.connect($("movedown"), "onclick", this, "
onMoveDown");
e.query("#" + this.container_div.id + " .movetop").connect("onclick", this, "onMoveTop").style("cursor", "pointer");
e.query("#" + this.container_div.id + " .movedown").connect("onclick", this, "
onMouseDown").style("cursor", "pointer");
e.query("#" + this.container_div.id + " .moveleft").connect("onclick", this, "onMoveLeft").style("cursor", "pointer");
e.query("#" + this.container_div.id + " .moveright").connect("onclick", this, "onMoveRight").style("cursor", "pointer")
In the first case, the correct
onMoveDown event handler is called which does a scroll by a fixed amount and prevents bubbling up to the handler that causes mouse move scrolling as expected. But when the second set ends up being used (which happens in some alpha games like Rallyman Dirt or Nova Luna), pressing the down arrow ends up calling
onMouseDown instead, after which the maps keeps scrolling on mouse move, since there's no corresponding call to
onMouseUp being made.
Granted, I don't have access to developer docs, so maybe they didn't setup the scrollmap properly, but the intent in the implementation appeared to be quite clear.