[BATIK-676] NumLock causes MouseEvent to report wrong modifiers

• Type: Bug
• Status: In Progress
• Resolution: Unresolved
• Affects Version/s: 1.6
• Component/s: SVG DOM
• Environment: Operating System: Windows XP; Platform: PC
• Assignee: Batik Developer's Mailing list
• Reporter: Owen Rees
• Created: 28/Nov/06 05:01
• Updated: 21/Jan/07 19:07

Description

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".