alt Hacker NewsFor the kind of things needed by Firefox, the Linux APIs have been stable for decades.
The problem is not stability, but the fact that there are multiple APIs, and it is unknown which of them will be available on the user system, so a browser may need to support all of them.
For instance, for video decoding on a GPU, the Linux APIs differ depending on the GPU vendor, unless you use Vulkan, but Vulkan video decoding is not available in old computers. Even so, Firefox could have used some higher-level API that takes care of the low-level GPU-dependent details (e.g. ffmpeg).
More baffling is the failure of Firefox to use OpenGL or Vulkan for implementing WebGL, depending on the GPU vendor, because at least the OpenGL API has not changed in a very long time. I have no idea which is the reason (because Firefox does not provide adequate error messages), unless they depend on some vendor-specific OpenGL extensions. I use an NVIDIA GPU, on which I cannot enable WebGL in Firefox, despite the fact that WebGL works fine in Vivaldi and Chromium/Chrome and I use a very great number of OpenGL and Vulkan applications, including some written by myself, all of which work perfectly, with no problems whatsoever.
The usual explanation by Firefox team is that the drivers are not uniformly compliant and/or working well. There had been progress, though.
For your specific system, you can open about:support and search the page for the word "Blocklisted" - that section of the page includes failure codes that can be then passed to web search (or interpreted by name).
I don't know all the details of what works well or not, but the Chrome team logically should have more manpower to implement workarounds for driver problems, and Vivaldi reuses the engine.
Speaking of the other applications though, most of them don't have to use the dma-buf subsystem, to embed hardware rendered content inside a "regular" application. That imposes a certain limitation on the driver capabilities.