[2.2.0rc1] bootstrap modal dialog

[krikunts]

When I use autocomplete input with bootstrap modal dialog, choices are displayed behind the dialog.
However, it is just fine in previous release (2.1.1).

[jpic]

Try changing z-index. Does it work ?

[krikunts]

I've traced this issue to the 61e54ee. The cause is new version of fixPosition function in autocomplete.js.
The old one appended span with choices just after the input, so I suppose it was z-ordered automatically just like its parents.
The new function appends this span at the end of the body section. It looks ok in most cases but it's not when you use autocomplete in z-ordered elements like dialogs.

[krikunts]

Oh, and yes, for modal dialog it is rendered ok when z-index > 1050, but I think this is not the thing to be hardcoded in css because we don't know what maximum z-index could be enough.

[jpic]

Ok so what if we set z-index of the autocomplete to be equal to the one calculated for the input, would that work ?

[krikunts]

The z-index may be set not for the input but for one of its parents. If you get input's z-index, it will get you "auto" so this won't help.

[jpic]

Could you try with fix/zindex branch ?

I don't have a bootstrap project with an autocomplete in a modal window, there is none in test_project, I don't have time to make one for the moment, maybe after Djangocon. So your help is welcome on this.

[krikunts]

Ok, with this fix it works in Firefox. But I've discovered that Chrome and Opera adds some random 0 z-indexes in addition to "auto" values. So this code will do the trick:

var zIndex = this.input.parents().filter(function() {
    return $(this).css('z-index') != 'auto' && $(this).css('z-index') != 0;
}).first().css('z-index');

[jpic]

Didn't see your reply and was about to ping you about this heh

Pretty awesome, I'm packing that with a couple of bugfixes in rc3 ASAP.

[jpic]

Please could you try with 2.2.0rc4 ? I've included your fix and credited you in CHANGELOG.

Thanks

[krikunts]

The problem with z-index is fixed with 2.2.0rc4. Thank you for your time.
I added bootstrap_modal example in my fork https://github.com/lucky-user/django-autocomplete-light

During the tests I found another issue #431 related to the absolute positioning.

[jpic]

Yes, thanks for the example !

[marianobianchi]

I'm having this problem with jquery ui dialog. I can't see autocomplete options when writing things on the autocomplete input. Nevertheless, if i hit "enter" i get the expected result (one option selected and correctly displayed instead of the text input). I'm using django-autocomplete-light==2.2.3, jquery-ui==1.9.2, and jquery==1.10.2.

I tried using django-autocomplete-light==2.1.1 and it works fine. Do you know what the problem could be?

[jpic]

The problem with the way 2.1.1 works is that it's not supported in some cases in django admin.

Ideally, we'd support both methods, using the overflow: hidden method for django admin and using the clearfix method for modern css integration.

Pull requests would be welcome.

[marianobianchi]

I don't understand: is this still an issue in versions >= 2.2? If it is, is there any open issue for this bug?

[jpic]

Details in the CHANGELOG would help ?

[marianobianchi]

There is a comment in CHANGELOG that says:

2.2.0rc3

• modelform raises IntegrityError instead of ValidationError #429: handle required=True in form fields again, regression introduced
  in rc1's python BC break.
• [2.2.0rc1] bootstrap modal dialog #426: handle z-index since we're absolutely-positioning in 2.2.x

What i understand is that this bug was fixed in version 2.2.0rc3. But with version 2.2.3 i'm still getting this bug. So i don't understand if it is this bug that wasn't fixed or if it is a problem with my code.

[jpic]

I was talking about:

2.2.0rc1

CSS BREAK

We've moved back to pre-1.1.10 CSS positioning. This means appending the
autocomplete box to an arbitrary DOM element (body by default) and using
calculating the ``top`` and ``bottom`` attribute in javascript with
``yourlabs.Autocomplete.fixPosition()`` pretty much like Django admin's
calendar widget does. While blunt, this change should help the widget

being
more compatible across Django admin themes.

While this positioning system has been used since around 2005 in Django
when Adrian Holovaty open sourced admin media in commit dd5320d, it has
never been documented that's it's a good system that works well and

there's
no reason to break backward compatibility in Django admin for that
- note to Django admin template customizers.

[jpic]

Note, there might be more info, please consider reading the whole 2.2.0rc1 CHANGELOG :)