> The reason this is occurring is because in the mootools framework(core) it > defines it defines a function off of document called id.. open up your core > file and search for "id:(function()" you will notice that it is grouped by > several other handy sounding functions.. it just a shortcut to > document.getElementById..
Surely anyone who uses the latest Moo knows about this function. http://mootools.net/blog/2009/06/22/the-dollar-safe-mode/ > So why does .net get tangled up in this? because when a click event occurs > anywhere on the page, .net is enumerating elements looking for particular > ones in a list it keeps... and it looks at element.id (as you would expect > to look for an id of an element) document.id != Element.id The bug is in Microsoft's code, where they frequently have a var named `element` actually be set to either an Element object or to document. (While document.documentElement is an Element, document by itself is not.) They are stupidly duck-typing `element`, relying on `element.id` == undefined whenever element is really a document and thus gracefully avoiding some code sections. When `element.id` turns out to exist even when element = document, they have a problem. They wouldn't have this problem if they just checked the type of `element`, which in turn would be easier if they used a not-completely-misleading variable name. > So what do you do? Stop blaming MooTools and dare to report/bugfix the MS code instead? -- Sandy
