#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
Component: | ui.core → ui.datepicker |
---|---|
Milestone: | TBD → 1.next |
Type: | bug → feature |
comment:2 Changed 12 years ago by
comment:3 Changed 11 years ago by
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
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; }; }());
comment:5 Changed 11 years ago by
@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
Milestone: | 1.next → 1.11.0 |
---|
comment:8 Changed 10 years ago by
Keywords: | haspatch added |
---|---|
Status: | new → open |
Type: | feature → bug |
comment:9 Changed 10 years ago by
Owner: | set to kwooda |
---|---|
Status: | open → pending |
You can set the z-index on the input or any ancestor and the datepicker will use that. Is that sufficient for you?
comment:10 Changed 10 years ago by
Resolution: | → invalid |
---|---|
Status: | pending → closed |
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
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.
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:
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: