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 descriptionSteps 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.
,
Jun 2 2016
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.
,
Jun 2 2016
C#2 is meant for Chrome-TE btw.
,
Jun 8 2016
,
Jun 9 2016
,
Jun 26 2016
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.
,
Jul 5 2016
Adam & Dan is this something which should be worked on spec-wise?
,
Jul 6 2016
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?
,
Jul 25 2016
Looping in respective TE's for Android.
,
Jul 29 2016
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.
,
Jul 29 2016
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?
,
Jul 29 2016
See #6 and #8, this is working as intended. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by cbiesin...@chromium.org
, May 28 2016