The initial observation was that if NumLock is on then the modifier observer methods of org.w3c.dom.events.MouseEvent such as getShiftKey() will give the wrong answers for the left mouse button but work for the right button. This was observed on Windows but not on Linux but that turns out to be because the NumLock state is not reported on Linux and so does not interfere with the reporting of the modifier key. The underlying problem is that if both a Lock and Modifier are on then DOMUtilities.getModifiersList will concatenate the strings naming the keys without an intervening separator so merging the last Lock and first Modifier into a single symbol such as "NumLockShift". The difference for the right mouse button is because right button reports that Meta is on so you get something like "NumLockMeta Shift".
Hi Owen. Half of this bug is now fixed in SVN: the space is now included in the string returned from DOMUtilities.getModifiersList. The problem that Meta is indicated as being pressed with the right mouse button is only partially fixed. Testing under JRE 1.6, I get the correct modifier list string when pressing down the right mouse button, but it has Meta in it when the button is released. Similarly for Alt and the middle mouse button. I tried reproducing this in a small standalone program and couldn't, so there is probably still a bug in there somewhere. (I'm pretty sure I only call getModifiersEx and never getModifiers, though.) I'm leaving this bug open to track the second part of the problem.