Wrong basic z-index

[JelmerD]

Great plugin and way better than the default TWBS 2.x modal. But there appears to be a small error in the getzIndex function.

The default TWBS modal has a backdrop z-index of 1040 and the modal is has value of 1050. Content within this modal will get a z-index of 1051 (modal + 1).

Your plugin however returns a backdrop z-index value of 1050 and a modal z-index of 1060 which is caused by the multiplication of the zIndexFactor with the pos variable on line 756. But the content inside still has a z-index value of 1051. So, that has to be updated as well.

Because of this bug I can not properly use a jQuery datepicker which works just fine in the TWBS Modal.

My temporary fix:

I changed line 756 to return baseIndex[type] + (zIndexFactor * pos) - 10; (note the -10).

I did not test it with all this plugins features, but for me that works since I am only using this plugin because the default TWBS modal does not scale in height when extra content is added. You get a stupid scrollbar inside the modal body instead (lame).

So the actual issue is:

This plugin does not properly update the z-index of child elements inside the modal cause these elements (for example a jQuery datepicker) to be behind the modal itself.

[saalaa]

Your patch is essentially offsetting both the backdrop and the modal's z-index by -10 which makes me think that the child elements are rendered with a z-index too low. Another thing that may be an issue is the order of the jquery datepicker container and the modal container in the DOM. They'll both appear at the end of the DOM and swapping them (without altering their z-index) may fix the problem.

[JelmerD]

Yeah exactly, but I never set the z-index of that datepicker, so I believe the bootstrap modal is setting the z-index of child elements. Since the default modal is set to 1050 and my datepicker is at 1051. So I believe the modal has to do something with it, but I think you can verify this?

[saalaa]

The modal is only managing the z-index for itself. The datepicker however is trying to find out the z-index of its container (ie. the modal) and adds 1 to that z-index.

The behavior is highlighted in the following jsfiddle: http://jsfiddle.net/Fa8Xx/1767/

What I think may be happening: the element holding the datepicker is created before the element holding the modal which messes the z-index up. I advise you to override the z-index of the datepicker and set it forcefully:

.ui-datepicker { z-index: 10000 !important }

It's far from an elegant solution but without further details, I doubt I can do better.

[JelmerD]

Thanks for doing the research :+1: I solved it by offsetting the z-index of your plugin with -10 so that it matches the original z-indexes. I think the jQuery ui datepicker uses the z-index of the original modal, but then you increment it with 10 which I think causes the jump in z-index of the parent. So I am wondering, is offsetting that z-index with -10 of any harm to the rest of the functionality of your plugin?