Revisit issue #75

[shelfos]

Regarding issue #75:

I too thought the problem was fixed because it does work okay in Chrome, but in IE9 it continues to persist. In other words, when the preview window pops up due to a click (openOn is set to 'click') or focus, the preview window shows (having usePreview set to 'true'), and any text that was previously entered is selected. But when I hover over a keyboard button and move the mouse away from that button the text ceases to be selected. Or if I hover over the button and click on it the same thing happens and the new key pressed gets inserted at the front of the text instead of replacing it. The desired outcome is that the text stays selected so that if the user starts to type or click on the keys the entry is immediately replaced. It's confusing to see the text selected because you assume the text will be replaced with any new keystrokes.

I hope this makes sense. The old example in issue 75 needs to be updated with the latest files so I wouldn't depend on it. I also know you are very busy and I will try to see if I can muddle through to find a solution, but I know you'd be much, much faster at it. Despite some of the issues the Mottie keyboard is amazing! Keep up the great work.

Thanks!

[Mottie]

Hi shelfos!

Hmm, yeah, I can't reproduce the issue you're having in IE9 because well, the caret stays in the original input until I mouse over the keyboard.... and it's not selecting anything.

Ugh, switching inputs is causing problems again as well... at least for me.

I'll have to take a look at this when I get some time. Sorry for the inconvenience!

[shelfos]

Thanks for looking into it. If I change the value of base.checkCaret to always be false it seems to "fix" my issue. I assume then it has something to do with calling base.$preview.caret(), but I haven't delved into it enough. There will probably be unintended consequences to leaving this value false so I don't consider it a fix. As soon as I have a few minutes to mock up what I have on jsfiddle I'll post again. Thanks.

[shelfos]

To be more precise:
In the code below (from jquery.keyboard.js) you can see I've commented out the conditional code based on the value of base.checkCaret(). When I do this the value in the preview window stays selected even if I hover over the keys of the keyboard which is what I want it to do. base.checkCaret is definitely getting set to true on initialization (not due to lockInput set to false, but due to the test of caret position). If I leave the code intact, and because base.checkCaret is set to true, the base.$preview.caret() function runs whenever any of the buttons have a mouseleave event and causes the selection of the text to go away. I hope that makes sense. Maybe you can help me understand what could potentially go wrong if I comment out this section of the code so I know better what to look for. Thanks.

// using "kb" namespace for mouse repeat functionality to keep it separate
// I need to trigger a "repeater.keyboard" to make it work
.bind('mouseup.keyboard mouseleave.kb touchend.kb touchmove.kb touchcancel.kb', function(){
    if (base.isVisible && base.isCurrent) { base.$preview.focus(); }
    base.mouseRepeat = [false,''];
    clearTimeout(base.repeater); // make sure key repeat stops!
    if (base.checkCaret) { /*base.$preview.caret( base.lastCaret.start, base.lastCaret.end ); */}
    return false;
})

[Mottie]

Hi @shelfos!

Wow, sorry I haven't responded in so long. It's been a busy holiday season... and I forgot about this issue =(.

Commenting out that line would prevent the caret from being in the correct position in IE and I think some older versions of Opera. So if you're not worried about that, commenting out that line wouldn't hurt anything.

If you are worried about IE, maybe change that code to use keyboard.preview.select(); to select all of the text within the preview window.

Also, in the latest version of the plugin, I've added a line to the above code to remove the key hover class because of touch devices.

$(this).removeClass(o.css.buttonHover); // needed for touch devices

[Mottie]

Hopefully this issue has also been resolved along with issue #147. So, I'm going to go ahead and close it.

Thanks and sorry for taking so long!