Firefox document.all caveat
document.all is a proprietary feature of Microsoft Internet Explorer; a JavaScript-accessible collection of all page elements and precursor to the W3C document.getElementById() method.
Firefox doesn't support document.all. Or does it?
Beware: Firefox does sport a document.all when a page is in quirks mode. In fact, you can see it with the DOM Inspector tool. It doesn't have any child elements so I suspect it's some sort of wrapper for getElementById. Try referencing it from code and you may get this friendly warning:
Warning: Non-standard document.all property was used. Use W3C standard document.getElementById() instead.
Switch to a standards-compliant page and document.all is undefined, as expected.
Obviously this puts code that employs quick old-school browser checking with Updated: see below.document.all at risk — especially if your code is meant to be portable or drop-in.
Update: looks like support for document.all was introduced in Moz 1.7.5 back in December 2004.
Update #2 Confusion. The Mozillazine note says the document.all is "undetectable", but the way I discovered this was because FF was taking an IE code path based on the existence of document.all, exactly what shouldn't be happening. So I dunno.
Update #3 I haven't been able to reproduce the case that led me to discover Firefox's document.all implementation, so I think the bug must have been in my code. (Shocking, I know!) In any case, it does look like a test for document.all in Firefox should return false.
6 Comments:
Actually, it doesn't (or shouldn't) put old-school code at risk: that's the "undetectable" that Asa mentioned. If you say "if (document.all)", then there is no document.all for you from then on, but if you say "document.all.foo = bar" without checking first then document.all exists. The goal (and I have to admit I've never tested how well it's met) is to not break anything that does any testing whatsoever, while unbreaking at least some things which don't test, they just assume that everything is IE.
I typically use ((document.getElementById)&&(!document.all)) to check for not-Opera, not-IE. Is it not readily apparent that using an if-else block hinged on documentall is asking for trouble, anyhow?
Finally, it occurs to me that checking for defined filter style properties might just be one way to perform effective detection, since the various popular rendering engines support non-css3 platform specific attributes.
Pardon my blubbering.
Strange, the way I discovered this was because FF was taking an IE code path based on the existence of document.all, exactly what you describe shouldn't be happening. I wonder if there's some weird inconsistency I haven't been able to reproduce yet.
If you can narrow it down, but don't feel like filing a bug, just send me the reduced version, and I'll chase it through. But, was this at $job? The way I understand it, a single undetected use then makes it available whether or not you detect later, so you might be feeling the fallout of someone's undetected use 5K lines and three includes before you.
This comment has been removed by the author.
I'm using IE7 and got problems with
document.all
AND
window.external.AddFavorite(url, title)
both give error on page
Post a Comment
<< Home