Issue 754357  has been merged into this issue.

sarvesh.n@, thank you for the report. Would be really great if you can provide a sample test case to reproduce this issue.

Hi ,we can see the impact on our app, but it is housed on vpn, we will try to recreate a unit test case, till then can you let us know the changes you did to wasm, and we could try bisecting with/without those changes if possible to isolate the commit

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

We are not able to pass the wasm enabled flag from command line of chromium bisect build, do you have idea how it could be passed?

We're trying with the approach below
python bisect-builds.py -a win64 -b 454471 -g 449892 --use-local-cac
he -- --no-first-run --user-data-dir=/tmp <FULL SITE URL> --flag-switches-begin --enable-features=AsmJsToWebAssembly --flag-switches-end

Here’s a test case for the flag ”Experimental Validate Asm.js and convert to WebAssembly when valid.”
Below is a link which uses the ASM.JS version of Flash VM.

Demo Link: http://farm2-production-bot.usw2.zynga.com/index.html
Note: Loading the first time might take a couple of minutes as it downloads the ASM.JS file

Observation with Chrome 60
Flag Enabled: The demo shows up only with a blue background (no fish appears)
Flag Default: The demo loads fine with the fish

Observation with Chrome 59
Flag Enabled: The demo loads fine with the fish
Flag Default: The demo loads fine with the fish

On Chrome 60, we can switch the build to flash by passing an additional flash=1 parameter (This requires to manually enable flash on this page by clicking on the info icon). The fish loads fine with flash with the flag enabled or default. (Link: http://farm2-production-bot.usw2.zynga.com/index.html?flash=1)

Let us know if you are having the same observations that we do.

^^
The links i provided on my previous comment aren't exposed outside of our VPN.

Please use this:

Demo Link: https://skypebot.farm2.zynga.com/

(Link to run with flash https://skypebot.farm2.zynga.com/?flash=1)

All the details regarding observations and steps are same as my previous comment!

Able to reproduce the issue on Windows 10, Mac 10.12.6 and Ubuntu 14.04 using reported version #60.0.3112.90 but the same is not reproducible in the latest canary #62.0.3191.0.

Reverse Bisect Information:
=====================
Good build: 61.0.3118.0  Revision(476500)
Bad Build : 61.0.3117.0  Revision(476123)

Change Log URL: 
https://chromium.googlesource.com/chromium/src/+log/2a192b8c579d1666bbe1fca1c5eda3ff9b6b3a32..882f2fb812ab66cf7b8dbdd11e896b2586ac7ddf

Blink Change log:
https://chromium.googlesource.com/v8/v8/+log/4bb4a24e..dccdc028

From the above change log possible CL that fixed this issue:
Change-Id: I6cc9f222769aa036275654286c9c6271ef2d1334
Reviewed-on: https://chromium-review.googlesource.com/520945

mstarzinger@ - Could you please check and merge the fix to M61 if it is a valid candidate.
Note: Adding label ReleaseBlock-Stable as it seems to be a recent regression.

Thanks...!!

@Krajshree....for our knowledge/info can you let us know how you bisected and simulataneously set the flag for experimental wasm conversion to true, we were not able to set this flag while bisecting

[Bulk Edit]
URGENT - PTAL.
M61 Stable promotion is coming soon and your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP. 

Know that this issue shouldn't block the release?  Remove the ReleaseBlock-Stable label or move to M62. Thank you!

Note: We will only have 2 beta releases before Stable promotion. Plan is to cut M61 Stable RC on 08/31/17.

I am able to eliminate the regressions we're seeing by delivering a straight WASM build to the browser (via emscripten binaryen).
In other words if we deliver a .WASM file (rather than ASM.js) presumably skipping the ASM.js->WASM translation, the regressions disappear.
We have some futher issues with running our full game with WASM but this does work in isolated tests, and I believe does isolate the issue to solely the conversion.

@mstarzinger: Gentle ping, request you to please take a look into it as per comment# 8. Issue is tagged with a blocker label and is tagged with M61. M61 is set to be pushed to stable soon.

Thanks for the report! I verified that this is the same as  issue 719866 , which is already fixed on M61, but was never backmerged to M60. I agree with the analysis in comment #8 (thanks for the bisect).

@hablich: Please advise whether is makes sense to backmerge the fix for  issue 719866  to V8's 6.0 branch or not. The fix should apply cleanly.

I don't think it makes sense. 61 will go stable soon and no other 60 push
is planned.

Updating milestone label per c#14.

Per comment #13, this is already fixed in M61. If so, please mark the bug as fixed. Thank you.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-61; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-61 label, otherwise remove Merge-TBD label. Thanks.

Re comment #18: As per comment #13, this has already made it into M61, no merge required for M61.