4 Replies Latest reply on Jun 6, 2009 4:55 AM by DreamTimer

    Inconsistent behavior of preventDefault with KeyboardEvent

    DreamTimer

      The Adobe specification is clear about one issue: the keyboard events KEY_UP and KEY_DOWN are not cancelable and therefore preventDefault() does not work in that case:

       

      KEY_UP

      ...

      cancelable: false; there is no default behavior to cancel.

       

      However there is quite obviously default behavior once a KeyboardEvent is dispatched to a TextField. For example backshift and arrow keys have well defined default behaviour and it is quite relevant to prevent dispatching those events along with other text input captured by a TextEvent.

       

      The behaviour of Flex is actually ambiguous in this case: it depends on how you start an application. Here is an example

       


      PrevDefTest.mxml

       

      <?xml version="1.0" encoding="UTF-8" ?>
      <mx:Application horizontalAlign="left"
           width="100%"
           height="100%"
           xmlns:mx="http://www.adobe.com/2006/mxml">
        <mx:Script>
         <![CDATA[


              private function keyDownListener(event:KeyboardEvent):void
               {
                   textout.text = event.cancelable.toString();
                   if(event.keyCode == Keyboard.BACKSPACE)
                       event.preventDefault();
               }
         ]]>
        </mx:Script>
        <mx:Panel width="300" height="250" title="Prevent Default Test">
         <mx:TextInput width="80" id="textin" keyDown="keyDownListener(event)"/>
         <mx:Label width="80" id="textout"/>
        </mx:Panel>
      </mx:Application>

       


      PrevDefTest-AIR-app.xml

      <?xml version="1.0" encoding="UTF-8" ?>
      <application xmlns="http://ns.adobe.com/air/application/1.5">
        <id>prevdeftest</id>
        <name>prevdeftest</name>
        <filename>prevdeftest</filename>
        <version>0.1</version>
        <initialWindow>
         <content>prevdeftest.swf</content>
         <visible>true</visible>
        </initialWindow>
      </application>

       

      Now compile prevDefTest.mxml with mxmlc. The result will be a prevDefTest.swf. On Windows you can either double-click on this file and and load it in the Flash player or type

       

      <your-flex3-sdk-path>flex3sdk\runtimes\player\win\FlashPlayer  prevDefTest.swf

       

      The label will display "false" i.e.  the event is not cancelable just as the documentation says.

       

      But now launch your application using the AIR launcher and type:


      <your-flex3-sdk-path>flex3sdk\bin\adl  prevDefTest-AIR-app.xml

       

      Now the label will display "true" i.e. the even is cancelable and when you hit the BACKSPACE key text will not be deleted.

       

      What is going on here?

        • 1. Re: Inconsistent behavior of preventDefault with KeyboardEvent
          CoreyRLucier Adobe Employee

          I was able to confirm with the AIR team that AIR made keyboard events cancelable, essentially recognizing that keyboard events *do* have a default behavior. The behavior depends on the actual keys pressed. Ctrl-C will by default do a copy; normal keys just insert themselves into the focused textfield if not cancelled.

           

          I have yet to find this documented anywhere though - it should be.  I'll follow up with the team to ensure it's addressed.

           

          Regards,

           

          Corey Lucier

          Flex SDK Team

          • 2. Re: Inconsistent behavior of preventDefault with KeyboardEvent
            DreamTimer Level 1

            CoreyRLucier schrieb:

            I was able to confirm with the AIR team that AIR made keyboard events cancelable, essentially recognizing that keyboard events do have a default behavior. The behavior depends on the actual keys pressed. Ctrl-C will by default do a copy; normal keys just insert themselves into the focused textfield if not cancelled.

             

            I have yet to find this documented anywhere though - it should be.  I'll follow up with the team to ensure it's addressed.

             

            Regards,

             

            Corey Lucier

            Flex SDK Team

               

            Hi Corey,

             

            thanks for your reply. Please also note the part of my posting where I

            described that preventDefault() behavior in TextFields got lost when the

            app was not started with adl.exe. As long as I relied on undocumented

            behavior I didn't considered that as a bug. Once it is documented it is

            a feature and it becomes one.

             

            Regards

            • 3. Re: Inconsistent behavior of preventDefault with KeyboardEvent
              CoreyRLucier Adobe Employee

              So here is what I understand:

               

              1. The Flash Player clearly documents that keyDown events are not cancellable. And they in fact are not.

              2. In the AIR runtime keyDown events are cancellable, but this is not well documented (and should be).

               

              Your issue is that the standalone player does not allow key events to be cancelled via preventDefault, and should, given the fact that there are clear use cases.

               

              If this is the case I can file a player bug for you to this effect.

               

              -C

              • 4. Re: Inconsistent behavior of preventDefault with KeyboardEvent
                DreamTimer Level 1

                CoreyRLucier schrieb:

                So here is what I understand:

                 

                1. The Flash Player clearly documents that keyDown events are not cancellable. And they in fact are not.

                2. In the AIR runtime keyDown events are cancellable, but this is not well documented (and should be).

                 

                Your issue is that the standalone player does not allow key events to be cancelled via preventDefault, and should, given the fact that there are clear use cases.

                 

                If this is the case I can file a player bug for you to this effect.

                   

                Yes, exactly.

                 

                Thanks a lot!