shader.yang@ if possible please provide a test url for further traige. 

That is strange, that should work. Thomas, as you wanted to ramp up on this, are you open to try this workflow and evaluate? If not, please re-assign back to me.

@pbomm..., my test case package has been attached, you can decompress it and set a http server to reproduce my env, hope it is helpful. :)

Deleted: webgl-r.tgz 6.1 MB

webgl-r.tgz 6.1 MB Download

I've download your package and run it. When I run it I do hit the debugger statements that you put into the index in _JS_Log_Dump and other places, though I realize that is not the issue and that you want to activate the breakdpoint in wasm. Can you specify more where you tried to put the breakpoint and when you'd expect it to be activated? There are hundreds of wasm files and my knowledge of the unity export system is not significant enough to say which files would get executed when. 

I do realize that this setup of hundreds of wasm files makes it very hard to debug the wasm code output of Unity in general and it is actually something we are taking more of a look at whether we need more support for. If you have any input around what should be required there I am eager to hear :) 

I added debugger in _JS_Log_Dump, because WASM code couldn't be broken directly, I think when code break at _JS_Log_Dump, and you can follow the call stacks back and set some breakpoints in WASM code, then you continue to run, you will find WASM code cannot be broken normally. 

Hope it is helpful, thanks! :)

Dear All,
Any update for this issue?
Thanks!

We've looked into the problem and believe it to be connected to how we split apart different wasm functions in dev tools. This works well for smaller sized apps but the complexity of Unity exports tends to blow it up. Unfortunately there is not simple fix to this but we hope to tackle it as part of a large debugging improvement task. 

This problem is new to me. Can you tell more about what "blows up" here?

Apologies, "blows up" was not the most descriptive. The behavior I observed was that when you went to inspect the wasm code in the sources tab, it showed up as hundreds of folders, each with around a hundred wasm sources within each. 
I downloaded the sample linked in this bug and hit the debugger line breakpoint set within it. From there I went and set some breakpoints in wasm files. At first it ran as expected, breaking on the wasm breakpoints, but after continuing just once or twice, it would start to break on lines with no breakpoints and skip over breakpoints as well. After around a minute of continuing with some breakpoints misfiring, the page gave an "aww, snap" error (which is what I meant by "blows up"). Hope that helps. 

Any update for it?
Thanks!