Issue metadata
Sign in to add a comment
|
Canary 60 ES6 arrow function within async function wrong this context
Reported by
ja...@onesignal.com,
May 15 2017
|
||||||||||||||||||||||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3100.0 Safari/537.36
Steps to reproduce the problem:
1. Open Chrome Dev Tools -> Sources -> Snippets (left toolbar, you may have to click >> to see the menu) -> New Snippet. Paste the following code for your snippet.
var Car = class {
async drive() {
// Uncomment the line below to "fix" the issue
// console.warn("[Car.drive] First line of function:", this);
(() => {
console.warn("[Car.drive] Inside Promise: this:", this); // this -> Window
})();
}
navigate() {
console.info("[Car.navigate] this:", this); // this -> Car
this.drive();
}
}
var car = new Car();
car.navigate();
2. Run the snippet.
3. Observe line 6 (The console.warn() statement "[Car.drive] Inside Promise: this") outputs:
Window
for this.
Screenshot of Incorrect Result: http://i.imgur.com/yNwvcA6.png
What is the expected behavior?
"this" in line 6 above should be "Car".
Strangely enough, by uncommenting line 4, "this" is assigned correctly.
Screenshot of Correct Result, after using this in the first line of the function: http://i.imgur.com/n4afaA1.png
What went wrong?
This seems to only affect Chrome Canary 60:
Chrome Beta 59, and Chrome Stable 58 are not affected by this issue.
Did this work before? Yes 59
Chrome version: 60.0.3100.0 Channel: canary
OS Version: OS X 10.11.6
Flash Version:
Version Info
------------
Google Chrome 60.0.3100.0 (Official Build) canary (64-bit)
Revision f472642fd6c20b63b0f1a2f62564f2aad56f4be3-refs/heads/master@{#471639}
Google Chrome 59.0.3071.47 (Official Build) beta (64-bit)
Revision 11e144fef00160b11b4149197763e8c4387791fb-refs/branch-heads/3071@{#475}
,
May 16 2017
,
May 17 2017
Able to reproduce the issue on Windows 10, Ubuntu 14.04 and Mac 10.12.4 with chrome dev #60.0.3100.0 and Canary #60.0.3101.0 Issue broken in M-60 Bisect Info: =========== Good build : 60.0.3098.0, Revision Range - 471507 Bad build : 60.0.3099.0, Revision Range - 471588 Note : Per-revision bisect script is not invoking chrome builds After executing the old bisect script , i got the following CL's between good and bad build versions =========================================== https://chromium.googlesource.com/chromium/src/+log/0b6b35f669cfd191e369832a9385d939650c244b..e6a66337552cfd9a9af9471775ad5b67ee588b88 Unable to find the culprit CL which caused the issue. Untriaging this issue, requesting dev team to look into this issue and assign it to the concern owner. Thank You...
,
May 17 2017
Adam, your CL is in the bisect range. Can you have a look? commit 68f0a47b28a96a4966e7b747bfa304b555e726d1 [log] [tgz] author Adam Klein <adamk@chromium.org> Fri May 12 17:29:53 2017 committer Commit Bot <commit-bot@chromium.org> Fri May 12 18:07:02 2017 tree cd357329d49149281c5477a4aabe97791b30a6e7 parent fc5765ce7901767ba9298241454f736c17b4f9b3 [diff] [ignition] Move generator object creation to BytecodeGenerator This lets us avoid allocating the "this" variable for every generator, since the BytecodeGenerator can directly read the receiver via BytecodeArrayBuilder::Receive() when passing it into %_CreateJSGeneratorObject.
,
May 17 2017
,
May 17 2017
Proposed fix up for review at https://chromium-review.googlesource.com/c/508055/ |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by manoranj...@chromium.org
, May 15 2017