WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
146510
Inconsistent behaviour of enumerable flag of length property in arguments object
https://bugs.webkit.org/show_bug.cgi?id=146510
Summary
Inconsistent behaviour of enumerable flag of length property in arguments object
Erik Krogh Kristensen
Reported
2015-07-01 06:29:14 PDT
Created
attachment 255917
[details]
Demonstration of the problem There are two ways of accessing the arguments object in JavaScriptCore, with the arguments variable, and with Function.argument. Below is a function that accesses both these values: function example() { print(arguments); print(example.arguments); } The two objects both contains the arguments given to the function, but they disagree on the value of the enumerable flag on the length attribute. In "arguments" it is false, whereas in "example.arguments" it is true. This has the effect, among other things, that printing out the arguments with JSON.stringify will incorrectly include the length attribute when printing out the arguments object. According to the ECMAScript Language Specification, the correct behavior is that the enumerable flag is set to false. (Both SpiderMonkey and V8 agree with this). This was tested on a recently checked out version of WebKit, compiled on Ubuntu 15.04. A testcase has been attached that demonstrates the issue. --- Expected value --- { "length1": false, "length2": false, "funcArgs": { "0": "P", "1": "A", "2": "S", "3": "S" }, "args": { "0": "P", "1": "A", "2": "S", "3": "S" } } --- Actual value --- { "length1": true, "length2": false, "funcArgs": { "0": "P", "1": "A", "2": "S", "3": "S", "length": 4 }, "args": { "0": "P", "1": "A", "2": "S", "3": "S" } }
Attachments
Demonstration of the problem
(320 bytes, application/javascript)
2015-07-01 06:29 PDT
,
Erik Krogh Kristensen
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug