PDA

View Full Version : 3.1.1 - Combo List z index



TopKatz
14 Feb 2010, 10:01 AM
Since upgrading to 3.1.1 most of my combos are having issues with there z index. Its typically when I have a combo in a window. The list will appear behind the window, and make the list not visible to the user.

I saw this post:

http://www.extjs.com/forum/showthread.php?t=91781

However there is no override or fix available in the thread. This is a large issue in my app right now. Maybe someone can post one for this bug for those of us that do not have svn access.

astor
1 Mar 2010, 9:56 AM
I'm having a similar problem here.

One particular combo is inside a formPanel, which is inside a tabPanel, which is inside a window. The first time I load the form, the z-index of the combo's list is fine. If I load the form subsequent times, the z-index is still fine. However, once I save the form, the list's z-index no longer works properly.

Using firebug I can see that the list is behind the window. I tried manually editing the source (using Firebug) and set the z-index to 20000 and suddenly the list was viewable (and was on top as it should be).

I was unable to find much information about what's goin on here. This seems like a bug to me, because this was not happening in ext-3.0.0 (AFAIK).

In the meantime I've hacked up the ext-all.js file to always instantiate the combo's list with zindex: 12000 and this works as a temporary solution

You can search ext-all.js for the number 12000 ... it only occurs in a few places. Replace (b||12000)+5 with 12000 and it should work for you until there is an official fix.

Animal
1 Mar 2010, 10:33 AM
http://www.extjs.com/deploy/dev/docs/?class=Ext.form.ComboBox&member=getListParent()

Poke a implementation in. By default it returns document.body. Make it return what's best for you.

astor
1 Mar 2010, 11:18 AM
http://www.extjs.com/deploy/dev/docs/?class=Ext.form.ComboBox&member=getListParent( (http://www.extjs.com/deploy/dev/docs/?class=Ext.form.ComboBox&member=getListParent%28))

Poke a implementation in. By default it returns document.body. Make it return what's best for you.I guess I don't quite understand why document.body isn't a correct parent element for the list. I don't want any special behavior: I just want the list to always render at the correct z-index (this used to work).

TopKatz
1 Mar 2010, 11:32 AM
check out this guys hack/fix

http://www.extjs.com/forum/showthread.php?t=91781&page=2

Animal
1 Mar 2010, 12:09 PM
I guess I don't quite understand why document.body isn't a correct parent element for the list. I don't want any special behavior: I just want the list to always render at the correct z-index (this used to work).


Well it's inside a Window isn't it? So I thought it might be better to render it to the Window. Then there'll be no z-index issues.

TopKatz
1 Mar 2010, 12:13 PM
What Animal is pointing out is a good way to fix a single combo. Problem is I was seeing this in the bulk of mine, so that would be very tedious.

This issue is actually fixed out in svn, so I have tried to avoid applying the getListParent stuff to all my combos that are in windows.

astor
1 Mar 2010, 12:15 PM
Well it's inside a Window isn't it? So I thought it might be better to render it to the Window. Then there'll be no z-index issues.Hmm, perhaps, but then I would have to do a specific implementation of that on every combo that exhibited the problem and then verify that it actually fixes the problem. That would take a very long time in my app, as it is spread over many pages and has many combos.

Am I correct in understanding that this issue is fixed in 3.1.2?
What Animal is pointing out is a good way to fix a single combo. Problem is I was seeing this in the bulk of mine, so that would be very tedious.

This issue is actually fixed out in svn, so I have tried to avoid applying the getListParent stuff to all my combos that are in windows.Ok. I'm gonna just leave my z-index hack in there if this is fixed in svn. When 3.1.2 becomes publicly available, I'll update stop using the copy with the hack. :)

TopKatz
1 Mar 2010, 12:17 PM
...Am I correct in understanding that this issue is fixed in 3.1.2?

I can not say. I know its fixed in svn, but what gets released in 3.1.2 I dont know.