Cannot override z-index on datepicker

I think this is a bug. It was possible to change z-index in beforeShow in previous jQuery UI versions.

Now, after this fix:

http://github.com/jquery/jquery-ui/commit/bae22fb74aa46fa7b59883a09b9987f7e6b27678

it is impossible to set z-index in the beforeShow because beforeShow is invoked earlier then datepicker's div z-index is changed by the code:

_showDatepicker: function(input) {
    ...
    var beforeShow = $.datepicker._get(inst, 'beforeShow');
    extendRemove(inst.settings, (beforeShow ? beforeShow.apply(input, [input, inst]) : {}));

    ...
    if (!inst.inline) {
        ...
        inst.dpDiv.zIndex($(input).zIndex()+1);
    }
},

Current code also makes is impossible to set z-index manually via css.

Also setting z-index for input element to which datepicker is attached gives no result, because zIndex() ignores z-index value if it should be ignored by the browser and returns 0 for input element.

In my case I have input with attached datepicker and input with attached MCDropDown plugin below it.

MCDropDown sets z-index = 2 for it's div and as a result datepicker is displayed under it.

The only solution I found is to set z-index in the beforeShow, using setTimeout:

setTimeout(
   function() {
     $('#ui-datepicker-div').css('z-index',10);
   },  500
)

You can extend the datepicker to get around this:

jQuery.extend(jQuery.datepicker, { afterShow: function(event) {
	jQuery.datepicker._getInst(event.target).dpDiv.css('z-index', 6);
}});
jQuery('.element').datepicker({
..
...
}).focus(function (event) {
	jQuery.datepicker.afterShow(event);
});

So, a significant portion of this issue is based on the fact that in the above-mentioned line in _showDatepicker, as well as in _dialogDatepicker, which (stupidly) creates a false input with a zIndex of -10 (?!) on which to base the datepicker's zIndex.

I propose the following solution, stated in the form of a patch/enhancement to existing jQuery UI versions:

	(function () {
		var ddp = $.datepicker._dialogDatepicker,
			odp = $.fn.datepicker,
			sdp = $.datepicker._showDatepicker;
		/**
			Extends the original to support custom zIndex and to trigger an "afterShow" event
		*/
		$.datepicker._showDatepicker = function (input) {
			input = input.target || input;
			var ret = sdp.apply(this, arguments),
				inst = $.datepicker._getInst(input),
				zIndex = $.datepicker._get(inst, 'zIndex'),
				afterShow = $.datepicker._get(inst, 'afterShow'),
				afterShowSettings;
				
			if (!inst.inline) {
				inst.dpDiv.zIndex(zIndex || ($(input).zIndex()+1));
			}
			inst.dpDiv.fadeIn(1, function () {
				 if (afterShow) afterShow.apply(input, [input, inst]);
			});
			return ret;
		};
		/**
			Extends the original to force a zIndex, thereby getting around the hardcoded zIndex of -10 on the syntehesized <input>
		*/
		$.datepicker._dialogDatepicker = function (collection, dateText, onSelect, options, position) {
			var inst = this._dialogInst,
				args = [].slice.apply(arguments);
			args[3] = $.extend({ zIndex : $(collection).zIndex()+1 }, args[3] || {});
			return ddp.apply(this, args);
		};
		/**
			Extends the original to permit an empty collection call
		*/
		$.fn.datepicker = function (options) {
			var ret;
			if (options === 'dialog' && this.length === 0) {
				odp.apply($('<div>'), arguments);
				return this;
			} 
			return odp.apply(this, arguments);
		};
		/**
			Adds the convenience function jQuery.datepicker.dialog, to skip dependence on a DOM collection.
		*/
		$.datepicker.dialog = function (dateText, onSelect, options, position) {
			$([]).datepicker('dialog', dateText, onSelect, options, position);
			return $.datepicker._dialogInst.input;
		};
	}());

@Fordiman I propose you use GitHub to suggest code changes instead of pasting large blocks of code with no context into the bug tracker.

#6254 is a duplicate of this ticket.

You can set the z-index on the input or any ancestor and the datepicker will use that. Is that sufficient for you?

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

I'm not the original author, but I feel like setting the z-index on the datepicker container is a workaround, not a solution. Considering the number of tickets filed on this issue in Trac (I found at least 4) and the number of postings on StackOverflow and other sites about it -- not to mention the wide variety of solutions proposed -- it seems like something that really should either not appear at all when using the default CSS, or have some more obvious workaround.

See #9013.