A DOM use case that can't be emulated with direct proxies
Mark S. Miller
erights at google.com
Thu Dec 13 10:21:53 PST 2012
On Thu, Dec 13, 2012 at 1:12 AM, David Bruant <bruant.d at gmail.com> wrote:
>> I think this is the only viable solution.
> Ok. What do you think of the idea of different handlers based on context?
>  Last point of
Only if these different way of obtaining the object actually obtain
>> The current behavior violates ES5 in an unintended way.
> Just to clarify, invariants described in ES5.1 - 8.6.2 are violated.
>> As you say, to remain viable, it
>> must be done quickly. From previous experience, I suggest that there's
>> exactly one way to get quick universal deployment: add a test to
>> test262 that fails when a browser's WindowProxy object violates this
>> normative part of the ES5 spec.
> I feel such a test would rather belong to the HTML DOM. But either way, I
The spec that it violates is ES5.1. Therefore it will be
uncontroversial to put such tests into test262. The modern versions of
all major browsers (IE, Chrome, FF, Safari, Opera) all do so close to
perfect on test262 that even adding one additional test failure
creates a significant incentive to fix it -- especially since the
Of course, it would also be good to get the HTML5 spec fixed and to
get such tests into HTML/DOM test suites. But I'm not holding my
breath. Your observation about needing to get this fixed soon in
right, so let's move on test262 first.
> I'll reach out to public-script-coord to re-explain the issue and the
> suggested changes. I'll write a test case, submit it to the webapps
> directory  (I'll ask first to be sure it's the right one) and file bugs
> in different browsers.
>  http://dvcs.w3.org/hg/webapps/
More information about the es-discuss