BugsBunny
2026.09.09
On a related note, hope can make inventory, quests and shop scrollable by dragging the scrollbar (chat is already scrollable by dragging the scrollbar)
#299
Contents no longer scroll with mouse scroll wheel
FIXED
As title, unable to scroll everything that are scrollable, e.g., inventory, quests, shop, chat
🍅 ME TOO · 0
Sign in to confirm this bug.
COMMENTS
3 replies
Admin ADMIN
2026.09.09
AdminBug reports 23Suggestions 4Exploits 0Root-caused and fixed. This was a real regression, and a nasty one — the defect is inside Phaser itself, triggered by a change we made on the 8th.
When the engine shuts down it removes the mouse listeners it installed — except one. It never removes the WHEEL listener. On its own that would be harmless, because the dead listener refuses to do any work. But the very last thing it does, before refusing, is tell the browser "this wheel event has been handled" — and it keeps doing that forever. The NEW game's wheel listener starts by checking whether the event has already been handled, sees that it has, and bails. So the wheel event never reaches the input system at all, and every window listening for it goes dead at the same instant. That is why it was inventory AND quests AND shop AND chat, why clicking and dragging still worked, and why there was nothing in the console.
Why the corpse's listener was still on your canvas: the login screen and the game are two separate engine instances, and the engine recycles canvas elements between them. On the 8th we split the game code out of the login screen so the login page loads fast — which put a gap of a few frames between the login engine shutting down and the game engine starting up. That gap is exactly long enough for the freed canvas, dead listener and all, to be handed straight back to the game.
Fixed by removing that listener properly on shutdown, and by disarming the flag that makes it cancel events, so even if the removal ever misses, the leftover is inert. There is a test that reads Phaser's own source, so if a future engine version fixes this upstream we get told rather than silently doing the work twice.
Two things found alongside, both of which are why this needed a source audit rather than a glance at the console: one of our error guards was swallowing every exception in the input path without a word (it logs now), and the inventory window was leaking one wheel listener every time you closed it.
On your second note — dragging the scrollbar in inventory, quests and shop: that is a fair ask and not a bug, so I have deliberately not folded it into this fix. Worth filing on its own so it does not get lost behind this one.
On the dev branch, live at the next publish.
When the engine shuts down it removes the mouse listeners it installed — except one. It never removes the WHEEL listener. On its own that would be harmless, because the dead listener refuses to do any work. But the very last thing it does, before refusing, is tell the browser "this wheel event has been handled" — and it keeps doing that forever. The NEW game's wheel listener starts by checking whether the event has already been handled, sees that it has, and bails. So the wheel event never reaches the input system at all, and every window listening for it goes dead at the same instant. That is why it was inventory AND quests AND shop AND chat, why clicking and dragging still worked, and why there was nothing in the console.
Why the corpse's listener was still on your canvas: the login screen and the game are two separate engine instances, and the engine recycles canvas elements between them. On the 8th we split the game code out of the login screen so the login page loads fast — which put a gap of a few frames between the login engine shutting down and the game engine starting up. That gap is exactly long enough for the freed canvas, dead listener and all, to be handed straight back to the game.
Fixed by removing that listener properly on shutdown, and by disarming the flag that makes it cancel events, so even if the removal ever misses, the leftover is inert. There is a test that reads Phaser's own source, so if a future engine version fixes this upstream we get told rather than silently doing the work twice.
Two things found alongside, both of which are why this needed a source audit rather than a glance at the console: one of our error guards was swallowing every exception in the input path without a word (it logs now), and the inventory window was leaking one wheel listener every time you closed it.
On your second note — dragging the scrollbar in inventory, quests and shop: that is a fair ask and not a bug, so I have deliberately not folded it into this fix. Worth filing on its own so it does not get lost behind this one.
On the dev branch, live at the next publish.
Admin ADMIN
2026.09.10
AdminBug reports 23Suggestions 4Exploits 0Your second note is done too — you can drag the scrollbar in the inventory, the quest log, both shop columns and both storage columns now, not just in chat.
Why chat was the only one, because it explains why this was not simply a missing setting: the drag was attached to the scrollbar's grip itself. Chat updates its list in place, so the grip survives. Every other window rebuilds its entire list on each scroll step, which destroys the grip you are holding — so the drag ended on the very first pixel of movement. The code even carried a note saying dragging was "only safe for in-place windows", and the quest log had a to-do to switch it on once its list stopped being rebuilt.
Rather than rewrite four windows, the drag no longer belongs to the grip. It is tracked against the scrollbar's position on screen instead, which does not change when the window redraws — so the rebuilt bar picks the gesture back up and carries on. It also holds where you grabbed it rather than snapping the grip's middle to your cursor, the way a normal scrollbar does.
Two edge cases are handled, both of which would otherwise leave the bar stuck to your cursor: closing a window mid-drag, and dragging off the edge of the window and releasing outside it.
While in there I checked your rule the other way round — anything that scrolls by any means should also take the mouse wheel. One gap turned up: the mobile bottom sheet (stats, skills, inventory on a phone layout) could be dragged and had a scrollbar drawn on it, but ignored the wheel. That layout also appears on a laptop with a narrow window, so it takes the wheel now as well.
Thank you for both halves of this one — the first turned out to be a bug in the game engine itself, and the second was a real gap rather than a preference.
On the dev branch, live at the next publish.
Why chat was the only one, because it explains why this was not simply a missing setting: the drag was attached to the scrollbar's grip itself. Chat updates its list in place, so the grip survives. Every other window rebuilds its entire list on each scroll step, which destroys the grip you are holding — so the drag ended on the very first pixel of movement. The code even carried a note saying dragging was "only safe for in-place windows", and the quest log had a to-do to switch it on once its list stopped being rebuilt.
Rather than rewrite four windows, the drag no longer belongs to the grip. It is tracked against the scrollbar's position on screen instead, which does not change when the window redraws — so the rebuilt bar picks the gesture back up and carries on. It also holds where you grabbed it rather than snapping the grip's middle to your cursor, the way a normal scrollbar does.
Two edge cases are handled, both of which would otherwise leave the bar stuck to your cursor: closing a window mid-drag, and dragging off the edge of the window and releasing outside it.
While in there I checked your rule the other way round — anything that scrolls by any means should also take the mouse wheel. One gap turned up: the mobile bottom sheet (stats, skills, inventory on a phone layout) could be dragged and had a scrollbar drawn on it, but ignored the wheel. That layout also appears on a laptop with a narrow window, so it takes the wheel now as well.
Thank you for both halves of this one — the first turned out to be a bug in the game engine itself, and the second was a real gap rather than a preference.
On the dev branch, live at the next publish.
Sign in with MSU to comment.