New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 615638 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Jul 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug



Sign in to add a comment

Chrome Dev on Android - Calling super.splice(idx) from class extended from Array results in initialization of new instance of extended class instead of of an Array

Reported by e...@nordstroem.no, May 28 2016

Issue description

Steps to reproduce the problem:
1. Serve attached HTML file -- extend-array-splice.htm -- using a web server, which has a class extending Array and then attempts to splice on an instance of this extended class.
2. Visit the page in Chrome Dev on Android
3. Observe result

What is the expected behavior?
It should have been able to do this without trouble. Firefox on Android handles it fine. Firefox on Fedora 23 handles it fine. Chromium on Fedora 23 handles it fine.

What went wrong?
When splice is called on the object created from a class extending Array, and super.splice(idx) -- i.e. Array splice method -- is called by me from my splice method, the Array splice method will attempt to call the constructor of the class extending Array with an argument corresponding to the length of the spliced object. It is understandable that this happens since the Array constructor takes the length of the array to create as its first argument. It is, however, an error to think that a class extending Array will take the same constructor arguments. Instead of instantiating the extended class, the Array splice function should treat the object as a regular Array like implementations in Firefox for Android, Firefox on Fedora and Chromium on Fedora appear to do, and instantiate an Array, leaving the user to put other properties onto the result like what I attempt to do in the attached test case.

Did this work before? N/A 

Chrome version: 52.0.2743.8  Channel: dev
OS Version: Android 4.2.2
Flash Version: 

Attached a couple of screenshots in addition to the HTML file.
 
extend-array-splice.htm
702 bytes View Download
screenshot_chrome_dev_on_android.png
27.9 KB View Download
screenshot_chrome_dev_on_android_devtools.png
48.9 KB View Download
screenshot_ff_on_fedora.png
64.8 KB View Download
Components: -Blink Blink>JavaScript
Labels: Needs-Bisect
Please confirm that this works on which OS this behavior is present and try to narrow down the range when it first happened on Android.
C#2 is meant for Chrome-TE btw.
Labels: -Pri-2 Pri-1
Labels: Needs-TestConfirmation
So, a class extending Array gets Array[ @@species ] by default, which should return the class constructor, by default.

ArraySpeciesCreate derives the constructor to use based on the receiver of the splice call, which is an instance of the subclass. Getting `@@species` results in the subclass constructor, which is ultimately constructed at the end of the ArraySpeciesCreate algorithm.

Because of this, I believe this is working as intended, and compat concerns are just the result of unfinished implementations of ECMAScript 2015.

However, you can get your desired behaviour by overriding Symbol.species in your class, via `static get [Symbol.species]() { return null; }`, which would result in an Array being constructed.
Cc: littledan@chromium.org adamk@chromium.org
Components: -Blink>JavaScript Blink>JavaScript>Language
Status: Available (was: Unconfirmed)
Adam & Dan is this something which should be worked on spec-wise?
This was definitely the explicit design of Array subclassing. A subclass can avoid this by overriding @@species (e.g., in the class body, `static [Symbol.species] { return Array }`).

I see the logic in the design of ES2015 Array subclassing, however web compatibility could still be a concern. A question on my mind is, does this break existing websites somehow? We have been shipping the new Array subclassing semantics since 51, and other browsers have also begun shipping it around the same time; have we been breaking a lot of websites since that time?
Cc: rsgav...@chromium.org candr...@chromium.org
Looping in respective TE's for Android.
Cc: hablich@chromium.org
Labels: -Needs-TestConfirmation -Needs-Bisect
Able to repro on Nexus 6P / MTC19X

50.0.2661.89 - Pass
51.0.2662.0 - Pass
51.0.2663.0 - Fail

Logs @ http://go/chrome-androidlogs1/6/615638.

That is indeed when we implemented the specification. Is this causing problems for users? Should we raise these issues to the standards committee to revisit the design?

Comment 12 by adamk@chromium.org, Jul 29 2016

Labels: -OS-Android OS-All
Owner: adamk@chromium.org
Status: WontFix (was: Available)
See #6 and #8, this is working as intended.

Sign in to add a comment