getBoundingClientRect problem in IE

[guest]

Hi there,

I'm getting an intermittent (but frequent) problem in IE resulting from calls to getBoundingClientRect in dojo.html.getAbsolutePosition. I've monkey-patched it using:

dojo.html.getAbsolutePosition = dojo.html.abs = function(node, includeScroll, boxType){ ...

if(h.ie){

try {

with(node.getBoundingClientRect()){

ret.x = left-2; ret.y = top-2;

}

} catch (e) {}

}else if(document.getBoxObjectFor){

... }

which seems to do the trick (although I'm not exactly sure why :-). I've been in touch with a couple of other people who have had this same problem, hence the bug report.

Cheers, Andrew.

[liucougar]

a test case would be helpful

[Tom Trenka]

Note: the current method being used in IE is really aimed at dealing with text selections, and not positioning; it'd be a good idea to rewrite this method as far as IE is concerned.

[guest]

This can really kill!

My app was working fine with Dojo 0.4.1.rc1. I moved to Dojo 0.4.1.rc2 and I started getting this problem on IE. I looked at the dojo.html.abs method and nothing had changed between rc1 and rc2. But somehow the getBoundingClientRect had stopped working when I moved to rc2! :(

After lots of hits and misses, by sheer luck, I noticed that the parent of the node on which I am calling getBoundingClientRect had just gone past a dojo.dom.replaceChildren. I commented out the replaceChildren API call, implemented it myself and voila, things started working fine again! I went and looked at what changed in dojo dom apis, and ha, a dojo.dom.removeNode call is replaced with a dojo.dom.destroyNode! I don't know the details, but I am assuming that destroyNode does something more damaging than the removeNode.

​This user also might have been facing something similar.

[sjmiles]

These systems are rebuilt for 0.9, don't believe this exact situation is relevant to the new code.