DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=41053>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=41053
Summary: NumLock causes MouseEvent to report wrong modifiers
Product: Batik
Version: 1.6
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: SVG DOM
AssignedTo: batik-dev@xxxxxxxxxxxxxxxxxxxxxx
ReportedBy: owen.rees@xxxxxx
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".
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|
