Atlas Safari compatibility layer considered harmful

Not wanting to rehash discussions in the wider community about the use of Object.prototype to extend the native JS objects (see: ), I have found the following inconsitency between the Firefox and Safari compatibility layers that I do not think is intended.

The _loadSafariCompatLayer() function appears to add 'getElementById', 'attachEvent' and 'deleteEvent' functions to every native Object of the window rather than just the HTMLElement prototype Object that it intends.

To replicate:

1. Go to http://atlas.asp.net/atlastoolkit/Accordion/Accordion.aspx in Safari and Firefox (or other Atlas using site)

2. In each enter to following in the address bar to create a new Object and then iterate through its properties:

javascript:var mytest = new Object();mytest.myprop = 'prop';for (var key in mytest){alert(key+' = '+typeof(mytest[key]))}

3. In Firefox there will be one alert with a value of 'myprop = prop'. In Safari there will be 4 alerts, including the extra function names (Tested in Safari 2.0.4 and Firefox 1.5.0.7)

I believe that this manipulation of Objects (in Safari only) is one of the reasons why developers have been having problems integrating custom code or other OS libraries (e.g. Prototype) with Atlas in Safari, and changing this will greatly simplify things.

This may be a Safari JS bug so this is cross-posted to the Surfin' Safari bug tracker here - http://bugs.webkit.org/

However I am aware that there design decisions in the compatibiility layers and I'd like to understand the reasons for adding these functions to every Object. (I'm not an ASP.NET developer, but rather supporting a commercial JS library which will probably be more commonly deployed along with Atlas/Prototype/etc.)

Liam,I have followed up on the bug you reported at <http://bugs.webkit.org/show_bug.cgi?id=11315>. My testing indicates that the issue you observed is most likely caused by the Safari "compatibility" layer in Atlas. When Safari is set to spoof as a Mozilla-based browser in its user-agent string the behaviour is as expected. Changing back to the default user-agent string causes the issue to reappear. I'm not sure where the appropriate place is to file bug reports on the Atlas JS toolkit, but I would appreciate it if you could do so. I would love to see this resolved so it doesn't negatively affect users of Safari.
We have completely redesigned the compat layer so this problem should disappear with the next release, which is imminent. Thanks for reporting this.