Bug: Reflect.ownKeys(function() {}) differs in V8 strict mode than other cases

Alex Vincent ajvincent at gmail.com
Tue Sep 6 01:35:31 UTC 2016


Ugh!!  It's a trap!  (In the Star Wars sense, not the proxy sense.)

So if all my code is in strict mode, and I get a non-strict code function
to shadow as Tom and I were talking about in another thread... how do I
even test for that if my code is either consistently strict or consistently
non-strict?

On Mon, Sep 5, 2016 at 6:21 PM, Mark S. Miller <erights at google.com> wrote:

> Besides those two, the only other reference to
> AddRestrictedFunctionProperties is <http://www.ecma-
> international.org/ecma-262/7.0/#sec-createintrinsics> step 12:
>
> 12. Perform AddRestrictedFunctionProperties
> <http://www.ecma-international.org/ecma-262/7.0/#sec-addrestrictedfunctionproperties>
> (funcProto, realmRec).
>
> So .caller and .arguments must now exist as poisoned on (the intrinsic
> normally bound to) Function.prototype . So, besides Function.prototype,
> they may only appear on old-style sloppy functions; nowhere else.
>
>
>
> On Mon, Sep 5, 2016 at 6:09 PM, Caitlin Potter <caitpotter88 at gmail.com>
> wrote:
>
>> The part that matters here is in annex B: http://www.ecma-internation
>> al.org/ecma-262/7.0/#sec-forbidden-extensions
>>
>> This forbids functions in strict code from having own properties "caller"
>> or "arguments". Newer function kinds have these restrictions in sloppy mode.
>>
>> AddRestricted... adds the accessor which makes getting/setting "caller"
>> or "arguments" throw, but is per spec only performed on intrinsics (like
>> %FunctionPrototype%).
>>
>> So unfortunately, this is something your membrane would need to be aware
>> of and work around. Mozilla's approach violates ECMAScript's forbidden
>> extensions and can't be considered "correct"
>>
>
> This result by itself does not demonstrate that Mozilla or v8 are either
> conformant or non-conformant. By the spec, A must not have its own .caller
> and .arguments -- it must only inherit these from Function.prototype. B,
> being sloppy, may or may not.
>
>
>
>>
>>
>> Sent from my iPhone
>> On Sep 5, 2016, at 8:54 PM, Alex Vincent <ajvincent at gmail.com> wrote:
>>
>>     <script>
>> "use strict"
>> function A() {}
>>     </script>
>>     <script>
>> function B() {}
>>     </script>
>>     <script>
>> window.onload = function() {
>>     let a = Reflect.ownKeys(A);
>>     let b = Reflect.ownKeys(B);
>>     document.getElementById("output").value = (a.includes("arguments")
>> === b.includes("arguments"));
>> }
>>     </script>
>>
>> Mozilla Firefox reports true. Google Chrome and node.js report false.
>> Which one is correct?
>>
>> I looked through Mozilla's Bugzilla, Google Chrome's Monorail, and the
>> ES7 spec to try figuring this out.  The closest I could get was section
>> 9.2.7 of the ES7 spec. [1]
>>
>> Right now I have an inadvertent mix of strict code / non-strict code in
>> my membrane, and this difference is causing my most recent patch to fail
>> tests in nodejs and Google Chrome, and to pass in Mozilla Firefox.  In
>> Chrome and nodejs, I get:
>>
>> TypeError: 'ownKeys' on proxy: trap result did not include 'arguments'
>>
>> If it turns out Google & nodejs are correct, this could be an issue going
>> forward:  I can't control whether my membrane library's users are running
>> strict mode code or not... likewise, I don't know if my code should be
>> consistently strict mode or consistently non-strict.  (I feel that a mix is
>> not good, except for finding bugs like this...)
>>
>> My apologies for treating this list as a help forum, but I'm just not
>> sure where else to go...
>>
>> [1] http://www.ecma-international.org/ecma-262/7.0/#sec-addrestr
>> ictedfunctionproperties
>> --
>> "The first step in confirming there is a bug in someone else's work is
>> confirming there are no bugs in your own."
>> -- Alexander J. Vincent, June 30, 2001
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>



-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160905/144cbe0b/attachment-0001.html>


More information about the es-discuss mailing list