Remove legacy support for polyfilling Math.clz32, imul, trunc

[kripken]

These have been present in modern browsers for quite some time, see compatibility sections in

• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/clz32
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/imul
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/trunc

There is some risk in removing these polyfills, though, as IE doesn't support them (Edge of course does), and possibly very old mobile browsers don't (I couldn't find an online resource on that). If there are concerns, this could be behind a flag.

[kripken]

Added a test fix, and verified this passes all the tests locally, should be good to go.

[bvibber]

These are needed for IE11, which we still support at Wikipedia for ogv.js media playback. I could package the polyfills separately in a pinch though.

[kripken]

I see, thanks. Well, we could easily add an option for this, LEGACY_BROWSER_SUPPORT, how does that sound? I suspect we'll have other stuff to put behind that flag, like BlobBuilder #5724

[bvibber]

A LEGACY_BROWSER_SUPPORT flag would be perfect for us. :)

[kripken]

Ok, added LEGACY_VM_SUPPORT (VM seems better since it's also for older node.js etc.). Also added an ASSERTION runtime warning if a polyfill is needed and that option isn't set.

[Jaifroid]

We're interested in using this option for Kiwix JS. But enabling this flag disables the output of a wasm binary when building with "BINARYEN_METHOD='native-wasm,asmjs'" for fallback support. The binary simply isn't produced, and there is no warning about it on the command line. Not sure if that's a bug/omission, or just lack of documentation on what's possible.

We ideally want a single compile that will support Firefox, Chrome, Edge and IE11 with this flag set, where the browsers that are capable of loading the binary will do so, and the others (which may include versions running in browser extensions) will load asm. Obviously we can work around this with browser capability detection, but that seems to mean having two different compiles.

[bvibber]

Ah yes, the LEGACY_VM_SUPPORT option now forces WASM off (now that it's default) whereas previously it didn't affect it... might be better to make it agnostic again. @kripken what do you think?

@Jaifroid, beware that the single-build binaryen fallback method is a little flaky and is officially not recommended; I bit the bullet and went with two separate builds and runtime detection for ogv.js. It's a bit unsatisfying and complicates the build and deployment process, though.

[Jaifroid]

Thanks, @Brion , at the moment a dual build may be our only option if we want the extra speed of wasm on the latest browsers while still supporting the widest range of browsers in a single app. Like Wikipedia, Kiwix can't fully drop IE11 yet given the number of Windows 7 boxes still around, especially as Kiwix generally targets areas of the world where internet access may be flakey, expensive or controlled. I can't see an obvious reason why the legacy support option should stop the wasm side from building (especially with no warning about it): the math polyfill should only need to apply to the fallback, so shouldn't affect browsers which support wasm, no?

[kripken]

Yeah, a dual build is best for this, see https://kripken.github.io/emscripten-site/docs/compiling/WebAssembly.html#codegen-effects - a single build with fallbacks has big compromises.

@Brion Perhaps it makes sense to allow legacy support in a dual build, yeah... In other words, in a dual build it would not force wasm off. That seems reasonable, although I worry about the extra complexity somewhat. Thoughts?

[Jaifroid]

Many thanks @kripken . We're leaning towards dual build over at Kiwix JS. What I would suggest at least is that emcc should spit out a message if using the LEGACY_VM_SUPPORT flag together with a set of wasm options (e.g. WASM=1) to say that it's reverting to asm only. It does this in other instances of such conflict.

[kripken]

Good point @Jaifroid . Actually thinking more on this, I believe we should go even further - a warning would not be shown for people not specifying wasm and just assuming they'd get it by default, as it is the default now, and that is even more confusing... so I suggest that we just throw an error if wasm is on and legacy support is enabled, and the error can explain that it must be used without wasm. I opened #6635 for discussion.