Processing revision: 0126
Operating system: Windows XP

When looping, key and mouse events are queued and only delivered at the end
of each frame. Mouse events are kept in one queue and key events in
another and all the mouse events are dequeued before the key events. If
you press a key and then press a mouse button both in the same frame you'll
see the mouse click before the key press.

I would suggest keeping a single queue of InputEvents and adding both
KeyEvents and MouseEvents to it. Then, when dequeuing, do a runtime check
to see if you have a KeyEvent or a MouseEvent and call handleKeyEvent() or
handleMouseEvent() as appropriate.

edit]
Test case

Here's a test case. Press and hold shift and then quickly press and hold the
left mouse button. You will see "click" instead of the expected "shift-click".
If you wait a frame between pressing shift and the left mouse button you get
the expected output.

that's the wrong way to detect shift clicks (or other modifiers)...use the
mouseEvent object that's built-in. the mouseEvent object (of type
MouseEvent) has the latest mouse event stored in it for these situations.

technically we could merge the mouse and key events, but what you're seeing
is a real corner case, and i think we'd make more of a mess than necessary
(having to keep track of event type, or use instanceof, and do a lot of
casting).

edit]
Proposed patch

I'd like to ask that you reconsider the WONTFIX resolution for this bug. The
shift-click example has a workaround but that doesn't work in the general case.
Imagine a game where you press the space bar to jump and click the mouse to
fire and shooting works differently depending on whether you are on the ground
or not.

I don't think that keeping everything in one queue will be as much of a mess as
you think. Since code speaks louder than words, I've tried my hand at making a
patch. There's actually net decrease of 22 lines of code due to not having two
nearly identical queue implementations. The only complications are two
instanceof checks and two downcasts.

I've tried it against the above test case and it seems to work properly.

k, i still think we're looking at a corner case, but of course code is the
way to get me to listen ;) i'll see about incorporating it for 0128.

This patch has probably bitrotted a bit in the last 2 years, but is there
any chance of getting it incorporated?

I'll try to take a look.