Skip to main content

Search and Top Navigation

#5479 closed bug (invalid)

Opened April 02, 2010 11:20PM UTC

Closed March 30, 2013 08:52AM UTC

Last modified May 13, 2013 10:49PM UTC

Cannot override z-index on datepicker

Reported by: kwooda Owned by: kwooda
Priority: major Milestone: 1.11.0
Component: ui.datepicker Version: 1.8
Keywords: zindex datepicker haspatch Cc:
Blocked by: Blocking:
Description

I use a custom z-index manager to control stacking of dynamic elements on the screen. I need to be able to specify the z-index of the date picker box before it opens. However, if I attempt to do so in the beforeShow event, the setting gets overwritten after beforeShow exits. The default z-index needs to be set before the beforeShow handler gets called so custom scripts can change it before it opens.

Attachments (0)
Change History (12)

Changed July 30, 2010 10:26AM UTC by jzaefferer comment:1

component: ui.coreui.datepicker
milestone: TBD1.next
type: bugfeature

Changed October 06, 2010 01:47PM UTC by seb comment:2

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
)

Changed November 30, 2011 09:56AM UTC by nicklevett comment:3

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);
});

Changed May 24, 2012 05:38PM UTC by mikesherov comment:4

_comment0: 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; \ }; \ }()); \ \ 1350680803196543

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;
		};
	}());

Changed May 24, 2012 05:43PM UTC by scottgonzalez comment:5

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

Changed October 03, 2012 03:45PM UTC by scottgonzalez comment:6

milestone: 1.next1.11.0

Changed October 19, 2012 09:08PM UTC by mikesherov comment:7

#6254 is a duplicate of this ticket.

Changed October 19, 2012 09:08PM UTC by mikesherov comment:8

keywords: zindex datepickerzindex datepicker haspatch
status: newopen
type: featurebug

Changed March 15, 2013 11:22AM UTC by scottgonzalez comment:9

_comment0: You can set the z-index on the input or any parent and the datepicker will use that. Is that sufficient for you?1363346557500734
owner: → kwooda
status: openpending

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

Changed March 30, 2013 08:52AM UTC by trac-o-bot comment:10

resolution: → invalid
status: pendingclosed

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!

Changed May 13, 2013 10:02PM UTC by bjrubble comment:11

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.

Changed May 13, 2013 10:49PM UTC by scottgonzalez comment:12

See #9013.