Opened 13 years ago

Closed 10 years ago

Last modified 10 years ago

#5479 closed bug (invalid)

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.

Change History (12)

comment:1 Changed 13 years ago by Jörn Zaefferer

Component: ui.coreui.datepicker
Milestone: TBD1.next
Type: bugfeature

comment:2 Changed 12 years ago by seb

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
)

comment:3 Changed 11 years ago by nicklevett

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

comment:4 Changed 11 years ago by Fordiman

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;
		};
	}());
Last edited 10 years ago by mikesherov (previous) (diff)

comment:5 Changed 11 years ago by Scott González

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

comment:6 Changed 10 years ago by Scott González

Milestone: 1.next1.11.0

comment:7 Changed 10 years ago by mikesherov

#6254 is a duplicate of this ticket.

comment:8 Changed 10 years ago by mikesherov

Keywords: haspatch added
Status: newopen
Type: featurebug

comment:9 Changed 10 years ago by Scott González

Owner: set to 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?

Last edited 10 years ago by Scott González (previous) (diff)

comment:10 Changed 10 years ago by trac-o-bot

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!

comment:11 Changed 10 years ago by bjrubble

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.

comment:12 Changed 10 years ago by Scott González

See #9013.

Note: See TracTickets for help on using tickets.