Datepicker: do not double focus input

That moves focus to the input field in case the datepicker is shown programmatically.

Please stop filing bugs with a version of git; that is for code that has not been released.

Why is this causing problems for you?

Scott,

I'm using the currently git version, that's the reason why I'm using the git version to report the bugs.

If it's not intended to report bugs, you should remove that from tracker and tell users about that.

I this warning already exists, I didn't see, sorry.

It's there for users to report bugs against code that is broken in git, but not in a release. This is not the case for the stuff you're reporting.

I see

Can you please answer the question of why this is causing problems for you?

Scott,

This is causing another issue related to poltergeist and phantom.js

I don't know why this causes the issue because I'm not a C++ developer to debug that inside the phantom.js but reason is call to focus inside intercepted focus event.

Browsers may deal with that (instead of being a infinite loop) but I guess we should not call the intercepted event itself again.

What do you think?

Sounds like a bug in a UA that we don't support.

Scott,

I would to suggest something, take a look: https://gist.github.com/2721846

This will not break anything and solves this issue.

What you think?

Yes, that will solve this one specific case, but the input may still get many focus events per "focus".

Yep, but currently who's buggy is jQuery Datepicker.

Currently, user callbacks is called twice when date picker input receives focus.

Using jsFiddle like suggested: http://jsfiddle.net/aCgJh/

That could be considered a date picker issue?

A long time ago I would've said yes, but as I've said over and over, there's nothing we can do about that. You'll get focus events for anything you do that removes focus when we want to maintain focus. I'll accept a patch that prevents this, but I can't consider native events being triggered when they're not expected or not being triggered when they are expected as bugs because it's just impossible to build this type of advanced functionality without changing the native behavior.

Scott,

Are you talking about #8330?

If so, these problems are not related to each other.

No, I'm talking about focus. You will get many focus events per interaction. Just try clicking anywhere on the calendar that won't cause a date selection.

Scott,

Nothing happens, take a look on fiddle: http://jsfiddle.net/aCgJh/1/

The focus event is only triggered when user clicks on month navigation that not makes any sense, by the way.

Anyway, this is an another issue on date picker, not related to this one.

Would you accept a pull request covering my proposal on gist?

I don't know how you can say "nothing happens" and follow it up with "the focus event is only triggered when user clicks on month navigation."

Yes, I will accept a check against document.activeElement, I already said that.

Scott,

Talking about focus on month navigation, what's the reason for that?

This is the last time I'll explain this: Clicking on the navigation controls moves focus, therefore we move focus back to the text field. We can prevent this by calling event.preventDefault() in mousedown, but that won't work in IE.

I already understand it, isn't necessary to repeat.

The question is why return the focus to the input since it already didn't happen if user click on date picker except for month navigation or date, that's what I don't understand the reason.

The only case that makes sense to return the focus is clicking in a specific date, not in month navigation.

Maybe I'm not being clear in my questions.

It should always go back to the text field, it's the element that manages all key handling.

Scott,

Could you take a look?

https://github.com/sobrinho/jquery-ui/commit/b30c863fb16a4e4a146ea5868cc02e0508368d8d

I guess it's fine but I want to be sure before submitting a pull request :)

No, that's not ok. You should not be defining a focused selector; the implementation is not even correct as it doesn't handle cross-window references. Just do the check inline.

Scott,

What you mean with cross-window references? frames?

Take a look about activeElement here: https://developer.mozilla.org/en/DOM/document.activeElement

Seems like it's present in all supported browsers by jQuery UI.

Frames, iframes, tabs, whatever. There are plenty of ways to create multiple windows. This has nothing to do with cross-browser support.

Scott,

Sorry, I do not get yet.

What window.activeElement (the :focused selector) has to do with tabs and frames?

window.activeElement "Returns the currently focused element, that is, the element that will get keystroke events if the user types any." (reference: https://developer.mozilla.org/en/DOM/document.activeElement)

It's not a big deal to check that inline on date picker but this could be useful for others widgets and others users of jQuery UI if it get documented.

1) It's document.activeElement not window.activeElement

2) elem === document.activeElement breaks cross-window references between elem may not exist in document, so the check may not be valid.

3) A proper focus selector already exists in Sizzle.

4) There's already documentation: http://api.jquery.com/focus-selector/

Scott,

1) Sorry, typo.

2) If element no longer exists in document, it can't receive focus. Am I wrong?

3 and 4) Take a look: https://github.com/sobrinho/jquery-ui/commit/b7ba15784256d4b5977012c7a7c918ddb3a296d2

I don't know the reason but using is(:focus) didn't worked.

Scott,

I'm removing the proposal from github because seems like you aren't interested in this fix.

Thanks!