I just read your last comment, and realized I synced your commit right before I changed it to trigger handler, so I have no idea if it is an actual solution or not.

Okay, so I reverted your commit because I wanted to see if mine was even an appropriate solution, and it is, it still works. So if you want to double check, or use which ever solution you feel is best, that's cool.

@amsul I really appreciate you being responsive and working quickly to help resolve this.

Oh, that's awesome! .triggerHandler never occurred to me. I'm going to give this a shot. Thanks :)

Hmm I get the feeling this is breaking the keyboard accessibility since the input doesn't actually receive the browser focus.

On IE 10 for Windows 8, I am able to tab into it, move around with the arrow keys, escape, delete, all that good stuff. Using the developer tools it appears to work in lesser versions of IE, however if that is that actual case, I'm not sure since I don't have the actual lesser binaries?

Try doing this: Focus into the input, then click on the calendar. Not on any date - just an empty space so it doesn't close. And then try to use your keyboard for navigation.

Or even changing the month recreates that issue..

It also seems to cause the tabindex flow to break.

Mmm yeah, gotcha. I can reproduce that. The keyboard events are bound to the input ELEMENT right?

Yes, sort of. They're actually handled at the document level because there are keyboard events for the drop-downs and buttons as well. The keyboard events can be un-bound from the input - but I think the bigger issue becomes the tabindex flow since it gets reset to the body.

Yeah, I looked through the source a couple times, and I don't see any way to quickly fix it without introducing some kind of global var for tracking state or doing what would probably be considered a major code rewrite. I tried playing around with a couple things near line 168 ( the if ( !$HOLDER.find( event.target ).length && event.target != ELEMENT ) code) but everything I tried causes a stack overflow, which is NOT a good solution. I'll keep looking at it, but off the bat, my solution doesn't work if you have to ensure the ability to maintain keyboard input under all conditions. :/

The first thing that comes to mind is that when you click something, like next month for example, focus is being set to not what it was when you opened the calendar, which is what is disabling keyboard input, so in my mind, the solution is to kill the click event on anything that isn't overridden while the calendar is open. Not sure where that would go though. I'm reading through some doc's right now.