I downloaded your example and loaded it up. First thing I noticed was that you were using .net4 and a newer version of the controls, .2055 (I was using .net35 and .2025). I downloaded the newest controls and while it was installing, I read the PDF included discussing the changes. One caught my eye that said for the dropdown "dropdown editor provider value list displays in an offset location on the page". It also said the "verified in version" was 11.1 so I wasn't sure if that means it has already been fixed for 11.2.

Either way, I was excited because I was thinking the new 2055 version would fix my issue. It didn't. It's the exact same issue (using either your .net4 sample you gave me or my original .net35 version).

This still happens in IE9 and Chrome but just like before, it works fine in firefox. You can see the attached screenshot showing your example, using .NET4 11.2 with the .2055 version controls and the version of IE9 I'm using.

Any recommendations?

Oh, and we were able to get the issue using a Blackberry as well.

Hello Ian

I confiurm that I am able to reproduce the issue in the link you have provided via Chrome. I created a sample on my own based on what I inspected in the browser that your code is. I tested the sample with last two service releases 11.2.20112.2055 and  11.2.20112.2086 and could not reproduce the issue with mine sample. I am attaching the sample. Can you please modify it or probably attach an archive containing aspx, cs and web.config files of the sample with which the issue is reproduced.

I downloaded your sample and I want to make sure you understand what has to happen for the problem to occur. The issue DOESN'T happen unless you can and have scrolled your browser down (even the slightest bit). Your example you provided doesn't have any bottom margins or line breaks at the end so the web page never has to scroll, thereby making it so you never encounter the issue.

I was able to reproduce the issue using your example. To do this I had to set my monitor's resolution to the lowest it would go (800x600). This still wasn't enough as the site's height still wasn't high enough to activate Internet Explorers scroll bar. Although if I expanded the bottom drop down, that would expand the site beyond the 800x600 resolution of the monitor thus activating IE's scroll bars. I then scrolled down a bit (any amount) and then expanded the second drop down within the tab group. Bingo! Issue reproducted. 

Again, I'm not trying to be harsh in my words but based on the example you provided (that doesn't allow scrolling), I want to make sure you understand when the issue happens. It's only after you've scrolled down on the page and of course the site height and screen resolution have to be set to the point where you CAN scroll otherwise you'd never experience the issue.

Thanks. 

Just so you know that you're not going crazy - I'm having this exact same issue, and it works the same way:

* Works in IE9 without compatibility mode

* Does not work in IE9 with compatibility mode

For what it's worth, I went poking through the JavaScript looking for spots where the coordinates are set, and there is a fix in the Infragistics code that looks like it must fix some issues, but can screw this up... at least in some cases.

In igDropDown.js:

There's a code spot that says:

//I.I.: 87265, scrolling offset is being taken in account
x += p0.absX - p1.absX - p1.scrollX;
y += p0.absY - p1.absY - p1.scrollY;

What it USED to say is:

x += p0.x - p1.x;
y += p0.y - p1.y;

I've debugged the page and set x back to what the old code would have given, and it comes out correctly.

I'm sure that I.I. (Internal Issue?) is a real concern, but we might need a:

if ((Sys.Browser.agent == Sys.Browser.InternetExplorer) && (Sys.Browser.version == 7))
{
  x += p0.x - p1.x;
  y += p0.y - p1.y;
}
else
{
  //I.I.: 87265, scrolling offset is being taken in account
  x += p0.absX - p1.absX - p1.scrollX;
  y += p0.absY - p1.absY - p1.scrollY;
}

...check in there to branch to the old code.

(I checked: compatibility mode sets Sys.Browser.version to 7 whereas turning it off gives 9)

I wish I had a minimal example to give, but I don't :/

I think if you're desperate, you can put in a patch by copying the code, putting in that modification and assigning $IG.DropDownBehavior.prototype.__showDropDown = function() { ...all the code for that function with the patch included }

Cheers,

-- Ritchie Annand

I didn't get around to downloading the 2086 version of the controls as you've said they have addressed that issue however I did download the 12.1 control released today and the issue does in fact appear to be fixed.

Thank you for your time.

Hello Ian,

After modification of my sample I was able to reproduce the issue. I tested it with the latest service release 11.2.20112.2086 and I was not able to reproduce it. I Checked and it occurs a development issue “DropDownItems’ container is not displayed in correct position under Chrome and Safari” was logged with ID 101028 and it was resolved in the latest service release. Please  upgrade to the latest build and let me know that you verify the resolved issue.

I just tried subbing in the prototype, turned on compatibility mode in IE9, and it worked.

I don't like the copy-modify-override technique, especially when upgrading versions, but it's a much lighter touch than some techniques.

(Just make sure to copy the contents of __showDropDown into the function() { ... } - if you accidentally put function __showDropDown() { } inside there like I did the first time, you will click and nothing will happen because it's defining a function with every click instead of running the function ;) )

-- Ritchie Annand