Gecko (not specs) has a concept of writable [Replaceable] attributes. It uses them for these properties:
window.innerWidth window.innerHeight window.outerWidth window.outerHeight window.screenX window.screenY window.opener window.status window.name In our implementation, a writable [Replaceable] property lives on the [[Prototype]] and has getter/setter-ish semantics associated with it, although (bug) you can't use Object.getOwnPropertyDescriptor to tell, as they use the old bindings code. Getting such a property gets a value. Setting it creates a shadowing property on window itself, using the exact value passed in. // Current Gecko alert(typeof window.screenX); // number window.screenX = "123"; alert(typeof window.screenX); // string, not number I'm making some changes near the code that implements this. These are very desirable changes, but they make it complicated to preserve these bizarre semantics. The easiest change is to get rid of writable [Replaceable] entirely, and make all these accessor-y properties: getting them gets whatever, setting them invokes the setter, getting them again gets whatever value the setter coerced it to. // Proposed Gecko alert(typeof window.screenX); // number window.screenX = "123"; alert(typeof window.screenX); // number (setter coerces string->number, or the setter silently did nothing) This is compatible with IE9 (standards or quirks mode -- and not in IE9 compat mode, and it seems not in older IE modes; I don't have IE10 to test) and Opera behaviors. IE9 puts the accessor on Window.prototype, and Opera puts it on window, but there's no visible difference in behavior for getting or setting. But there's still a supposed compatibility bugaboo to changing, because sites might have relied on the old behavior (notwithstanding that browsers are all over the map here), and other browsers aren't quite the same. WebKit gives the old behavior, but only for some of the listed properties -- it doesn't for status or name. (And it provides writable-[Replaceable] behavior for other properties beyond these: window.locationbar/menubar/personalbar/scrollbars/statusbar/toolbar/navigator/clientInformation/screenLeft/screenTop/scrollX/scrollY/devicePixelRatio/console/performance definitely. It might also for window.event/length/self/window/frames/opener/parent/top, but there's some extra complexity to these, so I'm unsure how they look.) Anyway. I think the compatibility bugaboo is just that -- we have no hard evidence of dependence on our current bizarre semantics, and we have other-implementation evidence that the proposed behavior is web-shippable. Thus I think we clearly should switch as proposed, aligning us with IE going forward and with Opera, and with the specs as well. Thoughts? Jeff P.S. -- The SunSpider test that used an undeclared "name" variable no longer does in SunSpider 1.0, so concerns about window.name particularly are unfounded. (Not to mention SunSpider is increasingly obsolete as a benchmark, and all the JS engines are doing their best to kill/ignore it.) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
