ReferenceErrors with --harmony sounds a lot like it's related to sloppy scoping.

Thanks for the bug report. We aren't planning on shipping any of these features in 47, so I don't think this means we have to roll back anything with sloppy scoping, but still, this will block shipping those features. I'm looking into it.

I haven't been able to reproduce this bug (loading inbox works just fine for me under these conditions), but I bet it's related to v8:4441, which also causes ReferenceErrors under harmony starting recently.

FWIW, I'm able to reproduce by activating chrome://flags/#enable-javascript-harmony
I'm running 47.0.2521.0

Well, it just doesn't work for me, whether I use my corp or personal account, on a ToT build. Maybe I'm somehow getting at a different version of Inbox.

Within a week, I should have a patch for the other ReferenceError issue (which I can reproduce, and I have an idea for a fix). I'll let you know when I have that, and maybe it'll fix the issue.

I misunderstood the bug report. Indeed, when I open inbox, a loading icon stays in the bottom left corner, and clicking on emails doesn't work. I see ReferenceErrors like "Uncaught ReferenceError: _B_err is not defined". Thanks for the bug report; when I have a fix I'll be able to test it here.

I tried a quick-and-dirty patch to fix what I thought was the underlying issue at https://codereview.chromium.org/1376623002 . Indeed, this seems to get rid of the ReferenceErrors, but still, loading Inbox leaves the loading icon just spinning (and it doesn't keep spinning without this flag). I would be really surprised if this is due to the subtleties that I haven't gotten right in that patch; there's probably more going on here.

 Issue 537437  has been merged into this issue.

can we please prioritize this? we're scaring off our alpha testers...

Fixing these sloppy-mode issues in staging is my top priority. I'm glad I turned it on because I'm getting these great bug reports, but do you think I should switch it off while I work on fixes? I hope to have a fix within a few days.

no, that's fine :)

I'm more worried about what else might be broken (cf your comment #8)

 Issue 537360  has been merged into this issue.

This needn't be a P1 if we just turn off staging for this flag. We probably want to do that in the M47 branch anyway.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/bab3b5508280e7a58720f701f9dbec96f81a16d8

commit bab3b5508280e7a58720f701f9dbec96f81a16d8
Author: adamk <adamk@chromium.org>
Date: Wed Sep 30 19:17:23 2015

Revert "Stage sloppy block-scoped functions (Annex B 3.3)"

The current implemention breaks sloppy mode code that uses function
declarations inside blocks at top-level. Work is ongoing on a patch
to fix this issue, but in the meantime it seems reasonable to move
the feature out of staging.

Manual revert of commit 6e07f5a75ba2c949ac96efabd5248c76b9957112.

R=littledan@chromium.org
BUG= chromium:535836 
LOG=y

Review URL: https://codereview.chromium.org/1375213005

Cr-Commit-Position: refs/heads/master@{#31029}

[modify] http://crrev.com/bab3b5508280e7a58720f701f9dbec96f81a16d8/src/flag-definitions.h
[modify] http://crrev.com/bab3b5508280e7a58720f701f9dbec96f81a16d8/test/test262/test262.status

 Issue 535977  has been merged into this issue.

(Dropping self from CC as this is quite far from my expertise at this point. :-) )

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/5e8d5de29948e1692cac630d4169a137fd7897d4

commit 5e8d5de29948e1692cac630d4169a137fd7897d4
Author: Michael Hablich <hablich@chromium.org>
Date: Fri Oct 02 12:34:17 2015

Revert "Stage sloppy block-scoped functions (Annex B 3.3)"

The current implemention breaks sloppy mode code that uses function
declarations inside blocks at top-level. Work is ongoing on a patch
to fix this issue, but in the meantime it seems reasonable to move
the feature out of staging.

Manual revert of commit 6e07f5a75ba2c949ac96efabd5248c76b9957112.

Cherry-picked of bab3b5508280e7a58720f701f9dbec96f81a16d8

TBR=littledan@chromium.org,adamk@chromium.org
BUG= chromium:535836 
LOG=y

Review URL: https://codereview.chromium.org/1375213005

Cr-Commit-Position: refs/heads/master@{#31029}

Review URL: https://codereview.chromium.org/1387563002 .

Cr-Commit-Position: refs/branch-heads/4.7@{#5}
Cr-Branched-From: f3c89267db0fc6120d95046c3ff35a35ca34614f-refs/heads/master@{#31014}

[modify] http://crrev.com/5e8d5de29948e1692cac630d4169a137fd7897d4/src/flag-definitions.h
[modify] http://crrev.com/5e8d5de29948e1692cac630d4169a137fd7897d4/test/test262/test262.status

At first, I thought it might have to do with the semantics changes in sloppy-mode block-scoped functions. The most likely case seemed to be that a function was called before its definition was reached. I wrote https://codereview.chromium.org/1400973002 to test that--this throws an exception if a function is called when it's undefined (for example, f(); { function f() {} } will throw this exception).

However, that didn't seem to hit. I ran through Inbox with pausing at caught exceptions. Previously, I just noticed that exceptions were thrown and caught either way, but now I noticed that a different exception was thrown with the flag turned on compared to when it's turned off. Namely this one: https://cs.corp.google.com/#piper///depot/google3/java/com/google/apps/bigtop/sync/client/system/client/gwt/GwtSharedAndDedicatedWorkerProxy.java&sq=package:piper%20file://depot/google3%20-file:google3/(experimental%7Cobsolete)&l=32 . I haven't figured out yet why that is thrown, though.

Thanks to help from the Inbox team, the issue was narrowed down to something like this:

dehrenberg@littledan:~/v8/v8$ out/Debug/d8 --harmony-sloppy-function
V8 version 4.8.0 (candidate)
d8> { function f() { print("hi"); f = () => undefined; } } f(); f();
hi
hi
undefined
d8> ^C
dehrenberg@littledan:~/v8/v8$ out/Debug/d8
V8 version 4.8.0 (candidate)
d8> { function f() { print("hi"); f = () => undefined; } } f(); f();
hi
undefined

Inbox expects to be able to overwrite the function binding, even though the function was defined in a block, which seems reasonable to me. Brian Terlson reports that this "fell outside the intersection somehow" that Annex B 3.3 was designed for.

It remains to be seen whether the spec will change for this case, but one form of semantics suggested by Adam Klein was that we would abandon function bindings being lexical in sloppy mode, and instead make them var bindings which are set (for the second time--initialized to undefined) at the top of the block where they are defined. This would appear to fix that idiom while defining something that will work with functions that close over lexically scoped variables, but it doesn't end up making function bindings "look more lexical" as Annex B 3.3 does.

Inbox was fixed, and then Chrome shipped the language feature to Canary with no known issues.