Re: Removing writable [Replaceable] properties
On 12/20/12 12:14 PM, Jeff Walden wrote: WebKit gives the old behavior, but only for some of the listed properties -- it doesn't for status or name. OK. Given that, I think we should just go ahead and make these non-replaceable. Given WebKit doesn't make status and name replaceable, the only place I'd expect possible compat problems is opener, and I think it should be ok even there. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Removing writable [Replaceable] properties
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
Re: Removing writable [Replaceable] properties
On 12/20/12 12:14 PM, Jeff Walden wrote: 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 Er... no. If you do that, you get number for the second alert, because you did a qualified set. That's the whole complication with these properties: they behave differently for qualified and unqualified sets. // 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) So specifically, for unqualified sets right now Gecko and WebKit reconfigure the property to a data property, as do older IE, but not newer IE or Opera, right? And the proposal here is to align with new IE and Opera? -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing writable [Replaceable] properties
Seems like a reasonable change to me, for the inner*, outer* and screen* properties. I don't know about the others. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Removing writable [Replaceable] properties
On 12/20/2012 03:38 PM, Boris Zbarsky wrote: On 12/20/12 12:14 PM, Jeff Walden wrote: 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 Er... no. If you do that, you get number for the second alert, because you did a qualified set. That's the whole complication with these properties: they behave differently for qualified and unqualified sets. Oops, sorry, you're right. I suppose I should mention for clarity that what I'm doing is trying to remove this difference. There is no spec way to distinguish between a qualified and an unqualified access to a variable, to get or set it. The [[GetP]] and [[SetP]] hooks that are part of ES6 (which is slightly reformulating this), and the [[GetOwnProperty]] and [[DefineOwnProperty]] hooks that are part of ES5, do not allow passing along qualification. In the case of getting a property, all you get is the object, and the property name being looked up. In the case of setting, you also get the value that goes along. And if you're defining, you get a descriptor with a value and some set of property attributes. The other operations, like [[HasProperty]] and [[HasOwnProperty]], also all take just the object and a property name/key. And the proposal here is to align with new IE and Opera? Yes. Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
