Update to CEF 124 / Fix Linux & macOS Compiles / Enable (partial) GPU / Enable WebGL / Decrease Log Severity

[WinterPhoenix]

This is a pull request that reflects the internal version of gmod-html that @solsticegamestudios has been maintaining for GModCEFCodecFix.

There are several improvements:

• Update CEF to 124.3.5 (Chromium 124.0.6367.119)
• Fix compiling for Linux and macOS
• Fix running GMod CEF in Steam Flatpak/Snap/AppImage under Linux
• Fix GMod Proton support for most scenarios
• Re-enable Site Isolation (security feature; some sites require it to function, BREAKING CHANGE for some addons!)
• Fix/Finish included example_host app
• Add gmod_launcher (as part of chromium_process)
  • Enables you to compile the Windows EXE for GMod, so that any newer version of CEF will actually work when recompiling html_chromium outside of Facepunch
  • Only needed for Windows
• Enable GPU, but NOT GPU Compositing (only partial GPU acceleration)
  • OnAcceleratedPaint is available as of CEF 124, but we still need GMod support for exchanging textures with gmod-html to leverage it properly
• More performant texture updates
• Enable WebGL
• Disable Hardware Media Keys control of media
• Change Log Severity from VERBOSE to DEFAULT
• Update README with new info about where to get current CEF distributions, missing build instructions, and more

Please consider merging this into the main game so everyone can enjoy these changes!

Please note that this does not include proprietary codecs or other things specific to GModCEFCodecFix's CEF build. That is determined entirely by the CEF build options you choose.

Special thanks to @willox, @osiris-plus, @JohnPeel, and @AkikoKumagara for helping us get CEF working after version 98.

[WinterPhoenix]

We're now up to date with the current stable version of CEF again, CEF 124.

This update has a couple of important changes coming with it:

• OnAcceleratedPaint now works again, thanks to some truly heroic efforts by a single person named Reito and some input/connections from the Open Broadcaster Software (OBS) team
  • With this CEF is able to share texture/framebuffer handles with "offscreen" applications like GMod, which means FULL GPU Acceleration!
  • However to do it properly, there needs to be support on GMod's side via IHtmlClient and some sort of way to synchronize the rendering context of CEF's texture with GMod's. On Windows, this would be D3D11<->D3D9.
• On Linux, gmod-html now detects if you're running GMod under Flatpak/Snap/AppImage, and will disable CEF's sandboxing so it'll work in that configuration. It's not ideal, but Steam's own steamwebhelper (which is CEF) does this as well, so...we're just going to deal with it for now. Those container technologies provide their own sandboxing, so it shouldn't be too bad.

[WinterPhoenix]

Thanks to @Davilarek, Flatpak/Snap/AppImage should actually work now on Linux! 🎉

While we disabled the CEF sandbox in the last update if it detects it's running in a container of some sort, GMod still checks if user_namespaces are available and will refuse to even attempt to load CEF if it thinks we don't.

@Davilarek solved this by reverse-engineering the gmod executable on Linux and creating a replacement which simply lies, saying we have namespace support, if it detects the executable is running in a container (with the same check we're using to disable sandboxing).

If you wanna review the code for the replacement executable, it's here:
https://github.com/solsticegamestudios/gmod-html/blob/master/gmod_launcher/Linux.cpp

[WinterPhoenix]

I figured out why keycodes and modifiers are broken in GMod CEF, and why players keep reporting it "typing the wrong keys!"

In GMod, there's IHtmlClient.h, which is also in gmod-html. In the KeyEvent struct, there's native_key_code, except it doesn't exist on Windows, and is being given wrong data on Linux (and maybe macOS?).

https://github.com/Facepunch/gmod-html/blob/master/html/html/IHtmlClient.h#L40-L42

Apparently during initial implementation, there was a misunderstanding for what exactly native_key_code is for, causing all kinds of weird issues with key mapping.

There's also issues with windows_key_code just being, wrong, for modifiers.

Test Website

https://dvcs.w3.org/hg/d4e/raw-file/tip/key-event-test.html

GMod CEF on Windows

GMod CEF on Linux

Chrome

How do we fix it?

Well! I've written a RIDICULOUS HACK that's mostly able to work around it by working "in reverse," using the windows_key_code/key_char to figure out the correct native_key_code for a key press. However it's not perfect.

Issues still remaining with the workaround:

• Key repeat detection is broken. Holding down a key isn't treated as holding it down according to DOM3.
• Symbol-only keys like ;'[]\-= etc, fire EMPTY KeyDown/KeyUp events from IHtmlClient. KeyChar works for them, but we can't synthesize key data for the other events from nothing!
• Key "location" is broken more often than not, due to us not being able to tell key presses that have the same character output apart
• Numpad codes AND locations are totally wrong, because of the aforementioned issues of not being able to tell the same key in multiple places apart

How does Facepunch PROPERLY fix it?

⚠ At its core, this a problem that needs to be fixed in Garry's Mod!

native_key_code is being treated as a character from UTF, where in reality it's the USB scancode from the keyboard, which is presented in platform-specific ways.

CEF/Chromium handles all the scancode transformation itself, don't worry about trying to do any of that yourself!

In IHtmlClient.h:

• Remove #ifndef _WIN32 from native_key_code so you can set that field on Windows

On Windows:

• When you call IHtmlClient->SendKeyEvent, set keyEvent.native_key_code = lParam from WM_KEYUP/WM_KEYDOWN/WM_KEYCHAR
• Currently, you're only setting keyEvent.windows_key_code = wParam, which is only half of what's needed
• Docs: https://learn.microsoft.com/en-us/windows/win32/inputdev/wm-keydown
• Reference example: https://github.com/chromiumembedded/cef/blob/9e9ba2c543c2de8c8636d9811df9e36abc600b17/tests/cefclient/browser/osr_window_win.cc#L793

On Linux:

• When you call IHtmlClient->SendKeyEvent, set keyEvent.native_key_code = hardware_keycode from whatever gives you it, whether it be SDL, X11, GTK, etc
• GTK/X11 Reference example: https://github.com/chromiumembedded/cef/blob/9e9ba2c543c2de8c8636d9811df9e36abc600b17/tests/cefclient/browser/browser_window_osr_gtk.cc#L1526

On macOS:

• When you call IHtmlClient->SendKeyEvent, set keyEvent.native_key_code = keyCode from NSEvent
• Reference example: https://github.com/chromiumembedded/cef/blob/9e9ba2c543c2de8c8636d9811df9e36abc600b17/tests/cefclient/browser/browser_window_osr_mac.mm#L605

How does this practically cause issues? Why should I bother?

• You know how Arrow Keys, Page Up, shortcuts like CTRL+A, and more all don't work in GMod CEF? This is why.
• This is also probably why players have reported CEF "typing the wrong keys" in the past
• Anything that uses keydown/keyup events in JavaScript is exposed to this wrong data, creating the potential for just about every keyboard-related issue imaginable
• Coolmathgames' keyboard games don't work!