Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Page.registerKey fails to fire certain keys in Firefox on Vista & Win7

    Code:
    Page.registerKey({keyName:"O",ctrlKey:true,altKey:true},"isc.say('Damp squib')");
    This is an observation of different behaviours across different browser / OS combo's. Expected behaviour is that pressing CTRL+ALT+O whilst browser has focus should pop up window saying 'Damp squib'.

    All done with SmartClient 7.0rc2

    Win XP SP3 32bit:
    IE8: works
    FF 3.6.10: works

    OSX 10.6.4 64bit kernel:
    Safari 5.0.2: works
    FF 3.6.10: works

    Vista SP2 32bit:
    IE8: works
    FF 3.5.9: fails
    FF 3.6.10: fails

    I believe Win7 + FF 3.6.10 failed, too, but don't have the test machine spec's at the mo.

    Further observations:

    In a blank notepad document:
    On WinXP, CTRL+ALT+vowel does nothing
    On Vista, CTRL+ALT+vowel gives the vowel with an acute accent on it

    Puzzled as to why IE works on Vista but FF fails I then made the following change to ISC_Core.js, changing:

    Code:
    isc.A.handleKeyPress=function(){var _1=isc.EH,_2=_1.getKey(),_3=this.$iu;
    to

    Code:
    isc.A.handleKeyPress=function(){var _1=isc.EH,_2=_1.getKey(),_3=this.$iu;isc.say(_2);
    Pressing CTRL+ALT+O surprisingly popped up a note saying 'O'

    However when I changed the code to:

    Code:
    isc.A.handleKeyPress=function(){var _1=isc.EH,_2=_1.getKey(),_3=this.$iu;alert(_2);
    I saw a different behaviour. Two alert boxes would pop up, the first one with just an acute accent in it and the second with the letter O.

    I haven't dived any further into the code.

    It strikes me that with a slightly more involved handleKeyPress function it would be possible for FF on Vista/Win7 to exhibit the same behaviour as all the other browsers.

    Thanks in advance.

    Thoughts?

    PS There were no other controls on the page that had focus for this test

    #2
    Try it with 8.0, we've made it possible to intercept more keyboard events and override the default browser behavior.

    But be careful doing so. Until you're hiding most of the browser chrome and really want the application to feel like a standalone application, you probably don't want to break browser shortcuts that users are familiar with - and these differ by browser and by OS.

    Comment


      #3
      Thanks for the suggestion. I have just opened the feature explorer using SC_SNAPSHOT-2010-09-20 and the following code:

      Code:
      Page.registerKey({keyName:"O",ctrlKey:true,altKey:true},"isc.say('Damp squib O')");
      Page.registerKey({keyName:"F",ctrlKey:true,altKey:true},"isc.say('Damp squib F')");
      Exactly the same combinations of IE/FF on Vista/XP/OSX pass and fail.

      I'm pretty sure it's because Vista automatically converts ctrl+alt+vowel into vowel with an acute accent. I think that the conversion is independent of the program that you are running. I have also checked that ctrl+alt+o is not a shortcut in Firefox.

      Finally, based on my mod of the handleKeyPress function, it is seems that the accent and the letter are coming through into the function but as two separate events, whereas in IE they come through in one event that appears as an 'O' character.

      I reckon I could patch the handleKeyPress function to work based on the events that I've seen firing.

      Before I do, are there any other functions than Page.registerKey that I should look at in the nightly?

      Comment


        #4
        If you can patch handleKeyPress you'll be affecting all upstream key event handling (FormItems, etc), so that should be all you have to worry about.

        Comment


          #5
          I have been trying to fix this issue in SC8, but the obfuscated code is harder to follow.

          You can reproduce the problem by:

          Code:
          Page.registerKey({keyName:"O",ctrlKey:true,altKey:true},"doSomeAction()");
          If you use Vista or Win7, set the keyboard map to United Kingdom English and try the shortcut. It won't work.

          Then set the keyboard map to United States English and it will work.

          In the United Kingdom map, ctrl+alt+vowel gets converted to αινσϊ.

          Using simple event handling on the onkeyup event, you can capture the event:

          Code:
          function handleEvent(evt) {
              evt = (evt) ? evt : ((window.event) ? event : null);
              if (evt) {
                  console.warn(evt.ctrlKey);
                  console.warn(evt.altKey);
                  console.warn(evt.keyCode);
              }
          }
          
          document.onkeyup = handleEvent;
          So, it looks like it's something to do with the way EventHandler abstracts this event. When you intercept the EventHandler lastEvent, ctrlKey and altKey are showing as false even though they are physically pressed at the time.

          I love the concept of the abstracted and consistent EventHandler and I would love it even more if you could make it consistent in this unusual case.

          Many thanks

          Comment


            #6
            Grab the LGPL build and you can run from unobfuscated source code (see smartclientSDK/source).

            Comment


              #7
              From my observations of the different browsers handling of onkeyup, onkeydown and onkeypress, it seems that the ctrl and alt flags are correct on the up and down but not on the press events.

              NB This is only when you have a United Kingdom layout keyboard and locale on Win7 or Vista.

              So, I store the state of ctrl and alt on the EventHandler during up and down events. Then override it on the press event *before* SmartClient does the rest of its processing.

              The fix works in my case. Please let me know your thoughts:

              Code:
              _handleNativeKeyDown : function (DOMevent, fromOnHelp) {
              .
              .
              .
              
                  } else {
                      returnVal = EH.handleKeyDown(DOMevent);
                  }
                  
                  EH._keyDownKeyName = lastEvent.keyName;
                  
                  // ----------- Save state   
                  EH._ctrlKeyOnLastUpDown = lastEvent.ctrlKey
                  EH._altKeyOnLastUpDown = lastEvent.altKey
                  // -----------
                  
                  if (returnVal != false && 
                      ((isc.Browser.isIE && !syntheticKeypressFired && 
                          EH._nonCharacterKeyMap[lastEvent.keyName] != null) ||
              .
              .
              .
              Code:
              _handleNativeKeyUp : function (DOMevent) {
              .
              .
              .
              
                  EH.getKeyEventProperties(DOMevent);
                  
                  // ----------- Save state   
                  EH._ctrlKeyOnLastUpDown = lastEvent.ctrlKey
                  EH._altKeyOnLastUpDown = lastEvent.altKey
                  // ----------- Save state   
                  
                  if (EH._keyDownKeyName == EH.lastEvent.keyName) {
              .
              .
              .
              Code:
              _handleNativeKeyPress : function (DOMevent) {
              .
              .
              .
                  EH.getKeyEventProperties(DOMevent);
                  
                  lastEvent.eventType = eventType;
                  
                  // ----------- Overwrite ctrlKey and altKey from saved state
                  lastEvent.ctrlKey = EH._ctrlKeyOnLastUpDown;
                  lastEvent.altKey = EH._altKeyOnLastUpDown;
                  // ----------- 
                  
                  if (isc.Browser.isMoz && lastEvent.keyName == this._$f10 && this.shiftKeyDown()) return;
                  
                  var returnVal = EH.handleKeyPress(DOMevent);
              .
              .
              .

              Comment


                #8
                This seems like it would have side-effects such as treating A-down, ctrl-down, A-up as pressing Ctrl-A, which should not happen.

                Comment


                  #9
                  I tried your example below and it seems to work correctly.

                  The actual _handleNativeKeyPress is called immediately after my finger hits the A key and before it hits the CTRL key.

                  There are no further calls to _handleNativeKeyPress as I then push down the CTRL key, release the A key, then release the CTRL key. See my console log.

                  Code:
                  Nativekeydown A ctrl false alt false
                  NativekeyPress A ctrl false alt false ctrlKeyOnLastUpDown false altKeyOnLastUpDown false
                  Nativekeydown Ctrl ctrl true alt false
                  NativekeyUp A ctrl true alt false
                  NativekeyUp Ctrl ctrl false alt false

                  Comment


                    #10
                    We've applied this patch to our mainline codebase - it'll show up in nightlies going forward. Please let us know if it doesn't work as expected for you, and thanks for your help.

                    Isomorphic Software

                    Comment


                      #11
                      I have migrated our app to the 2011-18-10 8.1 Power nightly and I the behaviour is just as I would expect.

                      Many thanks.

                      Comment

                      Working...
                      X