The above issue, for the WebAssembly application is only for Windows and not for Mac

@Reporter: Please provide sample test file/URL to test this issue from TE end. Any further information on reproducing the issue would help in better triaging.

Thanks!

Thank you for providing more feedback. Adding the requester to the cc list.

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

Please try loading with the below URL, once it loads .wasm would get cached, on second load the game will not load, this happens only on Chrome 66 on Windows only.
https://apps.facebook.com/farmville-two/?sfgfx=1&cdncache=1

By not loading, we mean the bar gets stuck in the middle.

Unable to reproduce the issue on chrome reported version 66.0.3359.139 using Windows-10 with steps mentioned below:
1) Launched chrome reported version and navigated to URL: https://apps.facebook.com/farmville-two/?sfgfx=1&cdncache=1
2) Page got loaded, again loaded the page for the second time, page got loaded successfully

@Reporter: Please find the attached screencast for your reference and let us know if we missed anything in reproducing the issue, try to test this issue by creating new person with no apps and extensions in it or test this issue on latest chrome stable# 66.0.3359.170 and let us know if the issue still persists.

Thanks!

Deleted: 840795.mp4 9.2 MB

	840795.mp4 9.2 MB View Download

Ok,we did also confirm that the issue takes place if and only if you also have the following set to true
1.)Flash should be allowed for https://apps.facebook.com:443 . You can do this by going to chrome://settings/content/flash and apply https://apps.facebook.com:443 under the allow section

On verbose debugging we get the following error once a while as well
pzUiVkaK5EOq2e7QaGGDwHz8J5yAbw&__pc=PHASED%3ADEFAULT&__req=i&__rev=3897644&__spin_b=trunk&__spin_r=3897644&__spin_t=1526036968&__user=100004207776818&asyncSignal=8303&fb_dtsg=AQFiweHrHL18%3AAQFQw5LAGa4i&jazoest=265817010511910172114727649565865817081119537665719752105

[29875:29699:0511/164458.609993:VERBOSE1:ppapi_plugin_process_host.cc(480)] PpapiPluginProcessHost::OnChannelError()

Thank you for providing more feedback. Adding the requester to the cc list.

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

The issue is reproducible on Mac as well with the above steps

RESULTS OF BISECTION ON MAC 
 python bisect-builds.py -a mac -g 530958     -b 531255  --use-local-cache

Downloading list of known revisions...

Loaded revisions 15734-558213 from /Users/snavelkar/Documents/workspace/.bisect-builds-cache.json

Downloading revision 531169...

Received 78782539 of 78782539 bytes, 100.00%

Bisecting range [530958 (good), 531255 (bad)], roughly 6 steps left.

Trying revision 531169...

Revision 531169 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g

Downloading revision 531204...

Bisecting range [531169 (good), 531255 (bad)], roughly 5 steps left.

Trying revision 531204...

Revision 531204 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g

Downloading revision 531218...

Bisecting range [531204 (good), 531255 (bad)], roughly 4 steps left.

Trying revision 531218...

Revision 531218 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g

Downloading revision 531234...

Bisecting range [531218 (good), 531255 (bad)], roughly 3 steps left.

Trying revision 531234...

Revision 531234 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b

Downloading revision 531225...

Bisecting range [531218 (good), 531234 (bad)], roughly 2 steps left.

Trying revision 531225...

Revision 531225 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b

You are probably looking for a change made after 531218 (known good), but no later than 531225 (first known bad).

CHANGELOG URL:

  https://chromium.googlesource.com/chromium/src/+log/8b084c0832974592b5fdb639b1d2558b4f5549ac..33b359b348b8111680e621e6ba9a505092bddbce

^^^^
The issue is reproducible on Mac as well with the above steps

RESULTS OF BISECTION ON MAC 

The issue is reproducible on Windows as well, below are the bisection results on Windows

C:\Python27>python bisect-builds.py -g 531208 -b 531234 -a win64 --use-local-cache
Downloading list of known revisions...
Loaded revisions 389148-558218 from C:\Python27\.bisect-builds-cache.json
Downloading revision 531217...
Received 126082593 of 126082593 bytes, 100.00%
Bisecting range [531208 (good), 531230 (bad)], roughly 3 steps left.
Trying revision 531217...
Revision 531217 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g
Downloading revision 531225...
Bisecting range [531217 (good), 531230 (bad)], roughly 2 steps left.
Trying revision 531225...
Revision 531225 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b
You are probably looking for a change made after 531217 (known good), but no later than 531225 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/3179df153a9913dc20e569f005640334c22690d5..33b359b348b8111680e621e6ba9a505092bddbce

^^^^^Results of bisection on Mac and Windows are above, it is reproducible on both Mac and Windows 10, 
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/3179df153a9913dc20e569f005640334c22690d5..33b359b348b8111680e621e6ba9a505092bddbce

I can see the below commit for Flash in the change log which could have caused this issue?

https://chromium.googlesource.com/chromium/src/+/6f58eaae3afd90cb96f1f2b8a5beaee9d6e4f640

Note that to reproduce the issue you need to follow two steps, first

1.)Flash should be allowed for https://apps.facebook.com:443 . You can do this by going to chrome://settings/content/flash and apply https://apps.facebook.com:443 under the allow section

2.)Load https://apps.facebook.com/farmville-two/?sfgfx=1&cdncache=1  (add the query parameters, which ensure that the .wasm is loaded from cdn cache, the issue is reproducible only when we load the .wasm for the cache)

sarvesh.n@ Thanks for the update.

Able to reproduce the issue on Windows 10 and Mac OS 10.12.6 on the reported version 66.0.3359.139 and the latest Canary 68.0.3430.0 as per comment #15.
Issue is not observed on Ubuntu 14.04.

Bisect Information:
===================
Good Build: 66.0.3328.0  (Revision - 530801)
Bad Build : 66.0.3329.0  (Revision - 531127)

As per comment #14, the Changelog URL is :
https://chromium.googlesource.com/chromium/src/+log/3179df153a9913dc20e569f005640334c22690d5..33b359b348b8111680e621e6ba9a505092bddbce

From the above Changelog, suspecting the below change:
Reviewed-on: https://chromium-review.googlesource.com/881041

dullweber@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.

Adding ReleaseBlock-Stable as this is a recent regression. Please feel to remove if it is not applicable.

Thanks

I have trouble reproducing the issue. Do you have a screencast of the required steps?

The changelog url in #16 is not for revision 530801..531127, that would be a much bigger set of changes:
https://chromium.googlesource.com/chromium/src/+log/1629a284e7c7c2ea5e562d9f242a84992cab5ed7..cc7ddcb128b5ed469bf44edf34790804066871ce

sarvesh: A simpler reproduction case that doesn't require facebook login and waiting for this huge thing to load would also be a great help.

Actually you dont need the whole game to be loaded, just the wait for the .wasm file i.e. scaleform-shipping-wasm.wasm to be downloaded, that happens within the first 15 seconds and the game gets stuck there itself when the file is loaded from cache

After bisecting on Chrome and Windows, we got just this set of commits, 

CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/3179df153a9913dc20e569f005640334c22690d5..33b359b348b8111680e621e6ba9a505092bddbce

I can see the below commit for Flash in the change log which could have caused this issue?

https://chromium.googlesource.com/chromium/src/+/6f58eaae3afd90cb96f1f2b8a5beaee9d6e4f640

+ Anthony, in case if it's related to Flash.

The affected game is the one loaded in WebAssembly (.wasm) not flash, I'm not sure how flash is affecting the same, however none of the methods in the Webassembly module (like prerun) gets called in this particular bug, we did check that the Module is properly constructed though. 

As this is regressed in M66 stable and we're very close to M67 stable promotion,  we won't consider this as M67 Stable blocker. Pls let us know ASAP if there is any concern here. Thank you.

There is no Wasm change in the suspected changelist. https://chromium.googlesource.com/chromium/src/+/e1d09725275d8bf7607a411c764bff503110a149 looks interesting though.

Max, can you please have a look?

Creating a facebook account requires accepting terms and such, so I'd rather not. I guess the app doesn't use microphone input? In that case, my change will not affect it. This bug report needs a smaller repro case.

I don't really see what I can do here. Putting myself on the CC list while awaiting a self-contained repro case.

Even if you have a FB account you need to give the app permissions to access your account. @reporter: We need a repro use case that does not require the investment of PII. Can you please provide something?

Per email discussion with hablich@, this is not a blocker for M67 as it exists on M66 and so far we only got one report. Moving to M-68.

sarvesh.n@, Could you please update the bug as per C#30 to proceed further.
Thanks in advance..!

For now , we are working around this issue by adding the Flash SWF to the DOM only post WASM Module initialization. 

hablich@,
Could you please take a look into it as per C#33?
Thanks..!

Re #34: I am not sure what you mean.

The request in #30 still stands. @Test: Do we have a FB test account?

I am afraid we wont be able to reproduce the issue using the initial steps given because we have patched it using the method in #33....meanwhile I will check if we can arrange for a seperate unit test, thanks

 sarvesh.n@,
Friendly ping to get an update on this issue as per C#35 & 36 as it is marked as stable blocker and stable release is coming very soon.

Please provide us exact repro steps If still issue is reproducable from your end.
Thanks..

Hi jmukthavaram,  
it is somewhat hard to recreate this for us in unit tests, so as of now its not a blocker for us as we have resolved it using the workaround from #33
Thanks

Adding abdul@ to update the thread as per C#38.
Thanks..!

Removing RBS.

No update since a while, probably irrelevant by now.