ComboBox in Grid edit popup in Chrome

[Cezary]

Hi,

Using Q2 2013 I encountered a strange bug using Chome browser, it's also occurring in your newest Q2 2014. I prepared the simple project to show this, available here: http://www57.zippyshare.com/v/59083421/file.html

The problem occurs in following conditions:
 - in Chrome browser (currently in newest version 38.0.2125.104 m)
 - RadGrid has setting ClientSettings-Scrolling-AllowScroll="true", so it gets internal scrollbar when there are quite few rows
 - RadGrid has EditMode="PopUp", and one of the columns has ComboBox in its EditItemTemplate
 - the PopUp is quite tall and that ComboBox is located somewhere on the bottom, visually beneath the RadGrid and on the bottom of the screen, so it expands to the top (I'm not sure whether expanding to the top is necessary to reproduce this, but location below the grid is).

Now when the popup is shown, clicking on the ComboBox arrow to expand the combo works, but combo is immediately closed. In the same time RadGrid below the popup scrolls down a bit. Situation is occuring until the grid scrolls itself to the bottom - then expanding the combo using the arrow works OK. What is interesting - expanding it by clicking in its text area works from the beginning.

What I also noticed - typing in the text fields above the combo also scrolls the grid with every character that is typed. Selecting the static text like one of the fields header (eg. "Field 5") also scrolls down the grid, but this also behaves the same in IE 9 (selecting text, not typing in text fields).

I'm not sure whether this is RadGrid, RadComboBox or maybe Chrome bug - it seems that Chrome wants to scroll the overflow container to the element that received the focus. Hopefully someone here will have something smart to say about this.

Thanks for help

[Cezary]

I added a screenshot to show what I'm talking about.

[Mateusz]

I have the same problem. I am still not able to solve this one :(

[Nencho]

Hello,

The experienced behavior is a bug related with the RadGrid, which I have already logged for further inspection. As a workaround, I would suggest you to set the  UseStaticHeaders property of the ClientSetttings of the RadGrid to true.

<ClientSettings>
     <Scrolling UseStaticHeaders="true" />
</ClientSettings>

Regards,
Nencho
Telerik

 

 

[Cezary]

Hi,

Thank you for answer, however this renders two separate tables, which columns have width set explicitly. This blocks the radgrid from adjusting its width when resizing, also doesn't look well when radgrid is rendered in a bit more complicated stack of controls, that has width=auto, are nested in overflow containers etc. So it's not acceptable for my project.
Hopefully you will fix this soon.

Thanks,
Cezary

[Mateusz]

Nencho,

Thanks for the workaround but unfortunatelly it is no good for me too. This option makes the grid very hard to use when you have them nested in a template of a parent grid. When both the grids have a lot of columns and you have to scroll horizontally, it just doesnt work nice from a usability standpoint.

[Eyup]

Hi,

The problem is caused by the fact that Chrome scrolls automatically to the active element and since it considers the elements inside the PopUp window as they were in the actual grid data container, it tries to scroll down to the selected element.

Although the bug is already logged in our system, you can open a formal support ticket about that matter and our developers will see whether there may be some viable workaround.

Regards,
Eyup
Telerik

 

 

[Cezary]

The only workaround I have found is to move the popUp edit form out of the table row and place it in the RadGrid root riv. This takes it out of the scrollable area, so it doesn't force browser to scroll it and comboboxes work as expected.
I handle this by adding to the ClientSettings.ClientEvents.OnPopUpShowing such simple handler:

function PopUpShowing(s, e) {
    $(e.get_popUp()).detach().appendTo(s.get_element());
}

I tested it a bit and everything seems to work correctly, however maybe I'm not aware of something.

Nencho or other Telerik guys - do you know any drawbacks of my workaround? Can it break something?

Thanks,
Cezary

[Eyup]

Hi Cezary,

Thank you for sharing your solution with our community. At first glance the approach seems fine, however, we cannot guarantee whether it will not lead to some styling or script glitch when used on more complex scenario. In any case, I'm glad you've managed to come up with a viable solution for your case.

Regards,
Eyup
Telerik