
<html>

  <head>


    <meta http-equiv="content-type" content="text/html; charset=UTF-8">

  </head>

  <body>

    <p>In light of a possible future Behavior API, I took a close look

      at the "complicated" behaviors surrounding TextFields and

      TextAreas.</p>

    <p>One thing that came out of this is that caret animation is

      controlled by the behaviors by looking at key presses and keys

      typed. It is a very convoluted way of doing this as there is a

      much simpler rule that governs caret animation:</p>

    <p>    <b>when the caret moves, animation should be reset</b></p>

    <p> This is how controls do it in browsers and on Windows, and it

      makes much more sense. The caret only needs highlighting when it

      actually changed position, and can remain animated when it

      doesn't.<br>

    </p>

    <p>This also means that caret blinking can simply be a concern of

      the Skin, as it can listen for caret position changes.  This also

      makes more sense.  Replacing the Behavior but keeping the same

      Skin should not break caret blinking.<br>

    </p>

    <p>Currently, the behaviors will wrap all possible key pressed/typed

      events to stop the blinking, but it gets it wrong in many

      situations (when the caret didn't actually move, or when a key

      press was not consumed or didn't do anything, or using keypad

      navigation which "forgets" to wrap it in the start/stop animation

      logic). It feels like a big hack when there is such an obvious

      alternative.</p>

    <p>I've created this ticket to address this:

      <a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/JDK-8322748">https://bugs.openjdk.org/browse/JDK-8322748</a></p>

    <p>One of the immediate benefits (aside from solving all caret

      animation bugs) is probably a memory reduction as it removes a

      wrapper around every key press/type mapping...<br>

    </p>

    <p>--John<br>

    </p>

    <p><br>

    </p>

  </body>

</html>