Currently, the in-game Steam Overlay does not support games built using browser technology on Windows, macOS and Linux. This includes tools/frameworks like:

• Electron
  
• NW.js
  
• Chromium Embedded Framework (CEF)
  
• Microsoft Edge WebView2
  
• macOS WKWebView

The fundamental problem appears to be that browsers use a multi-process architecture. They use a separate GPU process for rendering, so no drawing is actually done in the main process, and the Steam Overlay seems to depend on drawing being done in the main process. A benefit of a multi-process architecture is that it can actually recover from a graphics driver crash, rather than leaving you on the desktop having lost progress.

Sometimes the limitation can be worked around (e.g. --in-process-gpu command-line flag, or adjusting rendering code), but sometimes not (e.g. Microsoft Edge WebView2, which always uses a separate process). Even where it can be worked around, often solutions are hacky: command-line flags are not officially supported, and sometimes have unexpected side-effects. In the case of Microsoft WebView2, we have gone to great lengths to try to try to support it, but due to various bugs/limitations we have concluded it is not feasible (see: https://www.construct.net/en/blogs/ashleys-blog-2/trying-show-steam-overlay-1861 ).

The Steam Overlay works fine on the Steam Deck. This appears to be because it draws over the game, rather than hooking into the game executable to intercept rendering and input, as the overlay appears to do on Windows/macOS/Linux. In an ideal world, the same approach would be used on Windows/macOS/Linux, and should remove the need to modify what the game executable does. Alternatively adding support for multi-process executables should then support browser-based games.

Web technology might not power the next Call of Duty title, but it is more than capable enough to handle a wide range of indie titles and 2D content like Stardew Valley. Construct ( https://www.construct.net ) is a popular game development tool that exclusively uses web technology, and games like Moonstone Island are made in Construct: https://psteamproxy.yuanyoumao.com/app/1658150/Moonstone_Island/
This issue with the overlay has come up as we are in the process of migrating from NW.js to Microsoft WebView2 for a variety of reasons (one of which is, ironically, better support for Steam integration with our own custom C++ integration - neither NW.js nor Electron make that easy).

People outside of web development often have impressions of it that are a decade out of date, so while I'm here I feel obliged to point out some of the strengths of modern web tech:

• WebGPU supports modern high-performance GPU rendering and compute
  
• WebAssembly supports multithreading, SIMD, GC and now 64-bit memory
  
• JavaScript performance is extraordinary - to illustrate that, it far outperforms GameMaker Language (GML): https://www.construct.net/en/blogs/construct-official-blog-1/javascript-beats-gamemaker-1570
  
• Excellent cross-platform compatibility, including for Linux, which the Steam Deck runs
  
• Easy integration of custom HTML content (which some AAA titles use for their UIs)
  
• Sophisticated, robust architecture - how many Steam games can survive a graphics driver crash?
  
• Good enough to use in space - web tech powers the displays in the SpaceX Dragon

I'd be very happy to co-operate with anyone at Valve on the technical details of supporting the Steam Overlay. Feel free to contact me at ashley@scirra.com.

Thanks for your consideration!