Able to reproduce the issue on Windows 10, Ubuntu 14.04 and Mac 10.12.6 using chrome reported version #60.0.3112.78 and latest canary #62.0.3176.0.

Bisect Information:
=====================
Good build: 59.0.3049.0	 Revision(425838)
Bad Build : 59.0.3050.0	 Revision(426105)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/f70d58032706670f094ed7ae73c2bb13259fc0b6..a94ee9eb38e2003712667dfe217a5cb1a1763dd0

From the above change log suspecting below change
Review URL: https://codereview.chromium.org/2760793002

dcheng@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Note:
In Chrome 62.0.3175.2 (canary) the output is different, but also wrong: (as per reporter)

    data
    data

Thanks...!!

Sathya, could you take a look at this issue?

I've verified that this is fixed on ToT. 

FWIW, Comment#2 seems to contradict the reporter though (who reported it to be working on Chrome 62.0.3175.2). 

The repro case (written in very first place of the original report) is still reproducible.  The repro case is as follows:

var map = new WeakMap();
var popup = window.open("https://google.com");
map.set(popup, "data");
window.setTimeout(function() {
  console.log(map.get(popup));
  map.set(popup, "modified");
  console.log(map.get(popup));
}, 3000);

The other case (map.has / map.get) seems working as expected, though.  The other case is as follows:

var map = new Map();
var popup = window.open("https://google.com");
map.set(popup, "data");
window.setTimeout(function() {
	console.log(map.has(popup));
  console.log(map.get(popup));
}, 3000);

Sathya, could you take another look?

FYI, I'm seeing the attached screenshot.

I've synched to git commit = e192006f532ff3a9a765098cbe0cbc2de008d514
chrome://chrome says "Version 62.0.3190.0 (Developer Build) (64-bit)"
Platform is GNU/Linux (Goobuntu)

-------- args.gn --------
is_debug = false
is_component_build = true
enable_nacl = false
use_goma = true
goma_dir = "(snip)"
-------------------------

Deleted: weakmap.png 43.0 KB

	weakmap.png 43.0 KB View Download

Ah, I was testing content_shell. content_shell seems to exhibit the correct behavior but not chrome. 

Do you know if there is any difference between chrome and content_shell in handling of the window object?

The issue in V8 seems to be that globals created for a remote context return an empty string for %_ClassOf(). This causes us to go down the wrong path when looking for hash codes for such objects.

In content_shell, %_ClassOf(popup) returns "global", as expected (I'm not yet clear on why chrome and content_shell differ here, hopefully dcheng can answer that)

From a chat with dcheng, if I pass "--site-per-process" to content_shell I get the chrome behavior. So it looks like this is always broken when NewRemoteContext is used.

Here's what's going on inside V8. First, note from the original stack overflow report that this used to be broken in Map, but isn't anymore. Map and WeakMap used to use exactly the same logic to get the hash code for an object. That code looks like this (it's written in internal v8 JS):

```
function GetExistingHash(key) {
  if (IS_RECEIVER(key) && !IS_PROXY(key) && !IS_GLOBAL(key)) {
    var hash = GET_PRIVATE(key, hashCodeSymbol);
    return hash;
  }
  return %GenericHash(key);
}
```

Note the "IS_GLOBAL(key)". That's a macro which expands to "%_ClassOf(key) == 'global'". Since the RemoteContext-created global object returns empty string, it fails this check and so we incorrectly try to use the normal object mechanism for dealing with hashcodes, rather than the Global-specific logic (which is handled in the C++ runtime function %GenericHash().

Over the last couple of months, v8 has moved its implementation of the Map methods out of JS, which means they're no longer sharing the above logic with WeakMap. In particular, the decision about how to find the hash code always goes directly to %GenericHash, which uses a different mechanism (an instance type check) on the key to see how to handle the hash code. This method gets the right answer for the RemoteContext case, and thus uses the special "hash" field on JSGlobalProxy (https://cs.chromium.org/chromium/src/v8/src/objects.h?rcl=07259a9ceafa078c9bb7f9ee1bb6f2d67256cc80&l=5351), as intended.

All that said, there's the question of what to do to fix the WeakMap case. There's ongoing work inside v8 that will eventually make this go away (analogous to how Map got fixed), but that's probably on the order of weeks until it's fixed. If we'd like a fix sooner, we could try to hack things to make %_ClassOf return "global", but it's not yet clear to me how much work that'd be.

Given that this has been broken for two stable releases already, I'm inclined to just wait for it to be fixed on the v8 side. I've tentatively lowered priority and marked this as blocked on the v8 bug, but I'm open to doing something sooner if it seems worthwhile.

Discussed offline with adamk@. I think this is just an oversight of the remote context initialization path.

This is one step closer to being fixed. Now all that should be required is to eliminate the IS_GLOBAL check in the code in the referenced V8 issue.

Actually this was fixed in 01c82f9cab010b390f9ad15de9edf1fee44b972e; local testing indicates that we now properly deal with the hash.

Still might be nice for someone to write a web platform test for it, but the actual fix is done.