Tested this issue on Windows-10 using chrome latest stable #60.0.3112.101 by using the test case provided in the original comment. Clicked on choose file button, observed windows dialog box opens and uploaded a sample text file. After uploading observed below behavior.

From FileReader, instanceof ArrayBuffer: true
From FileReader, instanceof $wnd.ArrayBuffer: false
From $wnd.FileReader, instanceof ArrayBuffer: true
From $wnd.FileReader, instanceof $wnd.ArrayBuffer: false

Reporter@ Could you please let us know what's the expected behavior for this issue? There should be any changes in the above results?

Thanks!

$wnd.FileReader expected to create an ArrayBuffer of type (instance of) $wnd.ArrayBuffer. 

Thank you for providing more feedback. Adding requester "brajkumar@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

Expected result is:

From FileReader, instanceof ArrayBuffer: true
From FileReader, instanceof $wnd.ArrayBuffer: false
From $wnd.FileReader, instanceof ArrayBuffer: false
From $wnd.FileReader, instanceof $wnd.ArrayBuffer: true

(last two results switched)

I.e. currently, the ArrayBuffer returned is always from the current browsing context / global environment, whichever browsing context / global environment the FileReader is coming from. According to WebIDL (if I read it correctly), the ArrayBuffer should be from the same browser context / global environment as the FileReader that created it.

In this specific case, this breaks type-checking in GWT JsInterop [1]: GWT code runs in a different browsing context / global environment (namely, a hidden iframe), and expects everything to come from the parent browsing context (accessible through $wnd, which is equivalent to window.parent in this case). GWT thus type-checks using "instanceof $wnd.FileReader" and "instanceof $wnd.ArrayBuffer", but while the former is true, the latter is (unexpectedly) false!

[1] https://groups.google.com/d/msg/google-web-toolkit/jiHnLPfUQhc/aE1rsbX9CAAJ

BTW, I reproduce the issue on Linux too; this is not Windows-specific:

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36

Able to reproduce the issue on Windows 7,10 , Mac 10.12.6 & Ubuntu 14.04 using chrome latest stable#60.0.3112.113 & beta#61.0.3163.71 . No issue observed on Dev#62.0.3198.0 & Canary#63.0.3205.0 as per c#0 & C#4.Hence it is a reverse bisect issue.

Manual bisect info:
------------------
Good-62.0.3196.0 -Revision-497279
Bad-62.0.3194.0 -Revision-496533

Reverse bisect:
Per revision bisect info:
-----------------------
You are probably looking for a change made after 497124 (known good), but no later than 497125 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspectas some perf builds might get missing due to failure.
https://chromium.googlesource.com/chromium/src/+log/16529d0e49a3c1e4219d71620e749f06188627c6..84604e72d1ff9dd965957a53981e5635ac0bf01b

Possible suspect from the above auto roll:
----------------
https://chromium.googlesource.com/v8/v8/+/46fc2af0bdeacad08880c3033532bac0007f04ce

cbruni@could you please take a look and reassign to the right owner if it is not related to your change.

Thanks...!

If anything the following CL will be the culprit:

25decc6 Set the current context to the function's context when entering to LAP. by Yuki Shiino · 11 days ago

I'll have to double check with spec again to fully understand what's required here.

My CL mentioned at #7 has nothing to do with this issue.  Note that this issue was reported on Aug 23.

This issue is a case of "Should we use the Current realm or the Relevant realm of the receiver object?", and this specific case is already fixed.

Now the result is:
From FileReader, instanceof ArrayBuffer: true
From FileReader, instanceof $wnd.ArrayBuffer: false
From $wnd.FileReader, instanceof ArrayBuffer: false
From $wnd.FileReader, instanceof $wnd.ArrayBuffer: true