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: this appears to have been fixed in the april 30 ajax toolkit release with new code in the point constructor
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: this appears to have been fixed in the april 30 ajax toolkit release with new code in the point constructor