cwells@ - Thanks for filing the issue...!!

After unzipping the wwwroot.zip, was unable to find any website to launch. Hence, requesting you to please provide the website details in which the issue is observed. This will help us in triaging the issue further.

Thanks...!!

krajshree@ - My apologies for confusing you...!!

To simplify the issue I have deleted the "wwwroot.zip" file, as the only file of significance to my bug report is the "site.js" file mentioned and attached above.  The HTML/website context in which the script is run is unimportant.

I was hoping someone could investigate the difference in behavior between the different versions of Chrome (as shown in the attached screenshot), specifically regarding the population of the local variable "this" inside the multiply-recursive call around line 128 in site.js.

Thanks so much for your help triaging...!!

Thank you for providing more feedback. Adding requester "krajshree@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on Windows 10, Ubuntu 14.04 and Mac 10.12.6 with chrome Dev #64.0.3253.3, Canary #64.0.3260.0
Issue broken in M-64

Bisect Info:
===========
Good build : 64.0.3248.0,  Revision Range -510988
Bad build  : 64.0.3249.0,  Revision Range -511318

After executing the per-revision bisect script , i got the following CL's between good and bad build versions
===========================================
https://chromium.googlesource.com/chromium/src/+log/f34c0ec7e1bae02695666d69135b1c6cce65ed46..8db1dff254d91155d679bfdded4360519c1a8932

The suspecting Change Log is :
-----------
https://chromium.googlesource.com/v8/v8/+/eff39bbb70e92dd8115f1ac8e3b48b5c53ad0a35


cbruni@- Could you please look into this issue, if it's related to your change?  if not could you please help us to reassign this issue to the right owner.

Probably the following CL caused the change in DevTools:

a11b0d9 [inspector] improve this value for arrow function in scopes by Alexey Kozyatinskiy · 2 weeks ago

Can you have a look at it, Alexey?

This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone.

All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This value in your arrow function should be undefined. You can check it by adding console.log(this) in your finalMethod. Arrow function gets this value when it is defined, so it gets this value from top level function which have no this value.
Before we show incorrect information.
I am not sure why this in you IIFE is undefined, I think it should be window.

This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone.

All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Well, that's a bummer, and a very unsatisfying resolution.

This issue was marked as a "release blocker", and today get's resolved "Won't Fix" with no explanation?

Should I take this as meaning that the behavior change was intentional, and that you will be rolling this change into future version of stable Chrome?
Or just that you don't have the time or bandwidth to fix the problem now?

I would appreciate some additional explanation.

Thanks for your time,
Chris

I am not sure but by #11: it looks to me like previous behavior was incorrect. Arrow function should capture this when it is defined. If you put console.log(this) into your arrow function you can see that real this value is not OtherClass.

Okay, thanks Kozy!
We'll take the new behavior as correct, update our test automation accordingly, and expect to see the same behavior in all versions of Chrome in the future.