when autocompleteextender is laid out static in ie 10, it fails when you type into the text box.
Webpage error details
User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET4.0C; .NET4.0E; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Zune 4.7; InfoPath.3)
Timestamp: Fri, 26 Apr 2013 19:12:52 UTC
Message: Sys.ArgumentOutOfRangeException: Value must be an integer.
Parameter name: y
Actual value was 338.6099853515625.
Line: 2810
Char: 12
Code: 0
URI: http://www.uwmedicine.org/Bios/ScriptResource.axd?d=qGm3zxDfwn1juEkPO8dBwQ6OH2t8Zii-W3aCuTNgEapRrHbTn60X89P3Y75_QUVDKrEJF8BIT9-U0ZcLqFd9j6lWLKJ6ayOPdn1fbYPyLDx0jb5cmp6jHfKbA4MOvNqBYvTlaZZkUwNZFRHXciVvQJ_kCy0sGXG7RMdaxk2st02fRRzt0&t=fffffffff1955e1c
This is because IE has implemented floating point element positions, instead of integer pixel dimensions.
http://blogs.msdn.com/b/ie/archive/2012/02/17/sub-pixel-rendering-and-the-css-object-model.aspx
In AjaxControlToolkit._CommonToolkitScripts.getLocation, we invoke Sys.UI.DomElement.getLocation, which throws because it takes floating point coordinates and uses them to construct a Point, construction of which requires integers
\ case Sys.Browser.InternetExplorer:
Sys.UI.DomElement.getLocation = function Sys$UI$DomElement$getLocation(element) {
..
var clientRect = element.getBoundingClientRect();
..
var offsetX = clientRect.left - 2 + documentElement.scrollLeft,
.. offsetY = clientRect.top - 2 + documentElement.scrollTop;
return new Sys.UI.Point(offsetX, offsetY);
}
the point ctor fails. So, either send this along to Microsoft, or work around in AjaxControlToolkit._CommonToolkitScripts.getLocation
I worked around on one instance of this by nudging the text box onto an integer point, and snagging the showing event to prevent zIndex problems once the text box was positioned relative.
$(document).ready(function () {
var el = $("#txtSearch");
var clientRect = el[0].getBoundingClientRect();
$('#txtSearch').css({
position: 'relative',
top: (el.offset().top - el.offset().top.toFixed()) * -1 + 'px',
left: (el.offset().left - el.offset().left.toFixed()) * -1 + 'px'
});
});
function autocompleteShowing(a, b) {
a._completionListElement.style.zIndex = 1;
}
A similar workaround could be genericized and applied to all statically positioned autocompletes, tho I would prefer a microsoft ajax fix.
You can also work around by forcing ie9 document mode, but I don't want to leave something like that in my codebase.
<meta http-equiv="x-ua-compatible" content="IE=9" />
Please update this issue when you have either opted to work around or to link to ms issue.
Comments: actually this was fixed in System.Web.Extensions with a change to the Point ctor. It is pulled from the GAC, so different sites will either work or not, depending on whether their Framework/Ajax? install is current. I think it was fixed in an update, but am not sure. When deployed to a sharepoint site with .net framework 2.0, we still see failure, which we are addressing now with the metadata fix. <meta http-equiv="x-ua-compatible" content="IE=9" />
Webpage error details
User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET4.0C; .NET4.0E; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Zune 4.7; InfoPath.3)
Timestamp: Fri, 26 Apr 2013 19:12:52 UTC
Message: Sys.ArgumentOutOfRangeException: Value must be an integer.
Parameter name: y
Actual value was 338.6099853515625.
Line: 2810
Char: 12
Code: 0
URI: http://www.uwmedicine.org/Bios/ScriptResource.axd?d=qGm3zxDfwn1juEkPO8dBwQ6OH2t8Zii-W3aCuTNgEapRrHbTn60X89P3Y75_QUVDKrEJF8BIT9-U0ZcLqFd9j6lWLKJ6ayOPdn1fbYPyLDx0jb5cmp6jHfKbA4MOvNqBYvTlaZZkUwNZFRHXciVvQJ_kCy0sGXG7RMdaxk2st02fRRzt0&t=fffffffff1955e1c
This is because IE has implemented floating point element positions, instead of integer pixel dimensions.
http://blogs.msdn.com/b/ie/archive/2012/02/17/sub-pixel-rendering-and-the-css-object-model.aspx
In AjaxControlToolkit._CommonToolkitScripts.getLocation, we invoke Sys.UI.DomElement.getLocation, which throws because it takes floating point coordinates and uses them to construct a Point, construction of which requires integers
\ case Sys.Browser.InternetExplorer:
Sys.UI.DomElement.getLocation = function Sys$UI$DomElement$getLocation(element) {
..
var clientRect = element.getBoundingClientRect();
..
var offsetX = clientRect.left - 2 + documentElement.scrollLeft,
.. offsetY = clientRect.top - 2 + documentElement.scrollTop;
return new Sys.UI.Point(offsetX, offsetY);
}
the point ctor fails. So, either send this along to Microsoft, or work around in AjaxControlToolkit._CommonToolkitScripts.getLocation
I worked around on one instance of this by nudging the text box onto an integer point, and snagging the showing event to prevent zIndex problems once the text box was positioned relative.
$(document).ready(function () {
var el = $("#txtSearch");
var clientRect = el[0].getBoundingClientRect();
$('#txtSearch').css({
position: 'relative',
top: (el.offset().top - el.offset().top.toFixed()) * -1 + 'px',
left: (el.offset().left - el.offset().left.toFixed()) * -1 + 'px'
});
});
function autocompleteShowing(a, b) {
a._completionListElement.style.zIndex = 1;
}
A similar workaround could be genericized and applied to all statically positioned autocompletes, tho I would prefer a microsoft ajax fix.
You can also work around by forcing ie9 document mode, but I don't want to leave something like that in my codebase.
<meta http-equiv="x-ua-compatible" content="IE=9" />
Please update this issue when you have either opted to work around or to link to ms issue.
Comments: actually this was fixed in System.Web.Extensions with a change to the Point ctor. It is pulled from the GAC, so different sites will either work or not, depending on whether their Framework/Ajax? install is current. I think it was fixed in an update, but am not sure. When deployed to a sharepoint site with .net framework 2.0, we still see failure, which we are addressing now with the metadata fix. <meta http-equiv="x-ua-compatible" content="IE=9" />