Uploaded image for project: 'Batik'
  1. Batik
  2. BATIK-676

NumLock causes MouseEvent to report wrong modifiers

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: In Progress
    • Resolution: Unresolved
    • Affects Version/s: 1.6
    • Fix Version/s: None
    • Component/s: SVG DOM
    • Labels:
      None
    • Environment:
      Operating System: Windows XP
      Platform: PC

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

        Attachments

          Activity

            People

            • Assignee:
              batik-dev@xmlgraphics.apache.org Batik Developer's Mailing list
              Reporter:
              owen.rees@hp.com Owen Rees
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated: