Repository navigation
WindowProxy and violations of internal method invariants #672
Description
Basically, the problem raised by @bzbarsky in https://esdiscuss.org/topic/figuring-out-the-behavior-of-windowproxy-in-the-face-of-non-configurable-properties two years ago now was resolved, but the resolution could not be implemented per https://bugzilla.mozilla.org/show_bug.cgi?id=1197958#c4 and therefore the HTML Standard's WindowProxy object definition contradicts ECMAScript here after I discussed the situation with bz and @ajklein.
See https://html.spec.whatwg.org/multipage/browsers.html#windowproxy-getownproperty (step 3) and https://html.spec.whatwg.org/multipage/browsers.html#windowproxy-defineownproperty (also step 3) for the violations.
(I missed this when reporting the document.all violation as this one was not properly tagged in HTML.)
Activity
bzbarsky commentedon Aug 22, 2016
I think the other relevant links showing why this could not be implemented are https://bugzilla.mozilla.org/show_bug.cgi?id=1178638#c1 and https://bugzilla.mozilla.org/show_bug.cgi?id=1178638#c2 with the latter being a third-party library.
erights commentedon Sep 12, 2016
Regarding the proposal in the first bullet at https://bugzilla.mozilla.org/show_bug.cgi?id=1197958#c4 comment 4:
Do we agree that this would fix all reported breakages? On rereading this, I would be prepared to go even a bit further on weakening how Object.defineProperty reports failure, given that the Reflect.defineProperty and [[DefineOwnProperty]] contracts were not weakened, nor the invariants upheld by these contracts. From the reported breakages, I see no reason to weaken any of those. We need only weaken how Object.defineProperty reports failure.
bzbarsky commentedon Sep 12, 2016
I believe it would, yes. So, importantly, the magic would live in Object.defineProperty, and hence in the ES spec, not in the [[DefineOwnProperty]] of
WindowProxyobjects?erights commentedon Sep 12, 2016
yes, I think that's correct.
allenwb commentedon Sep 12, 2016
I think a cleaner way to allow for this behavior is to add a new paragraph to https://tc39.github.io/ecma262/#sec-error-handling-and-language-extensions that says something like:
"An implementation my define failure behavior other than throwing TypeError for Object.defineProperty when it's first argument is an implementation provided exotic object."
The HTML spec. would then state that Object.defineObject returns false rather than throwing when its first argument is a Windows Proxy object.
This would keep all of the details out of the ES spec. and put them back into the HTML spec, which is where they probably belong.
domenic commentedon Sep 12, 2016
@allenwb's version seems OK but I'd prefer to formalize it with something like a HostObjectDefinePropertyFailureBehavior abstract op which is called as part of the algorithm.
allenwb commentedon Sep 12, 2016
@domenic I think we should avoid adding attractive nuisance hooks the to the ES spec. that could be taken as a general invitation for hosts to do unanticipated bizarre things. In that light, I would further refine my proposed addition to clause 16 to says:
"An implementation my define failure behavior other than throwing TypeError for Object.defineProperty when it's first argument is an implementation provided exotic object and the throwing behavior would cause legacy code to fail."
The HTML spec. would not need to include any algorithmic specifications for this behavior. All it needs to say is: When a WindowProxy is passed as the first argument to Object.defineProperty failure is reported by returning false rather than throwing a TypeError exception.
domenic commentedon Sep 12, 2016
Sure. I think our proposals are equivalent except stylistically. I think it's much nicer to have the host-defined hooks called out by specific names and as explicit modifications to the algorithm steps, instead of hidden in paragraphs afterward.
domenic commentedon Sep 12, 2016
I'll put up a pull request that we can discuss more concretely, using much of your phrasing.
bzbarsky commentedon Sep 12, 2016
It totally would, because of the following two constraints:
to indicate failure (to make the property non-configurable) by returning false.
2. We want this code:
to throw.
ljharb commentedon Sep 12, 2016
bzbarsky commentedon Sep 12, 2016
annevk commentedon Mar 22, 2021
@shvaikalesh hey, we noticed you recently added tests to web-platform-tests to test for the current behavior specified in HTML. Is WebKit interested in experimenting with the variant that would not violate the internal method invariants?
cc @petervanderbeken
petervanderbeken commentedon Mar 22, 2021
We have been trying out making
GetOwnPropertyonWindowProxyreturn property descriptors withConfigurable: trueand makingDefineOwnPropertyonWindowProxyreturnfalseif the descriptor hasConfigurable: false(with exceptions for primitive values like NaN, undefined and Infinity). We haven't shipped it beyond Nightly, but we'd like to know if others are going to follow before we try to turn it on everywhere (https://bugzilla.mozilla.org/show_bug.cgi?id=1496510).annevk commentedon Apr 4, 2022
Given that it broke Google Analytics we stopped experimenting on Nightly. I think we're back to square one on this issue and have to adjust the invariants to account for
WindowProxy.ljharb commentedon Apr 4, 2022
@annevk do you have a link about that breakage?
petervanderbeken commentedon Apr 4, 2022
https://bugzilla.mozilla.org/show_bug.cgi?id=1758164
xcllv18-sketch commentedon Oct 7, 2026