That does not excuse Apple’s cavalier attitude towards bugs, but many of the APIs they refuse to implement deserve to die, like WebUSB or Bluetooth access, because of the privacy or security risks of weakening the browser sandbox. Has Google not learnt from the ActiveX fiasco?
For most people this stuff is unnecessary, which is why there's permission prompts to these APIs, bbut for certain use cases they're very convenient. Google made a tool that allows flashing firmware onto their Pixel devices directly from websites instead of requiring admin permissions to install some kind of one-off binary tool, for example. Then there's the ESPHome flasher which is very convenient.
ActiveX allowed for breaking out of the web sandbox and running native code, these new APIs don't. They allow more direct communication with devices, but only with permissions and even then with limitations.
If I want a website to communicate with a device, I'd prefer it if they'd stick to the web sandbox instead of requiring a native tool. These APIs help prevent an ActiveX world where everything needs an app that runs native code, with all security implications that comes with, and help people stick to the web sandbox.
Perhaps that's why Apple refuses to implement certain APIs, they make billions from the ActiveX world that has come out of the app store.
How? Because last I checked Web Workers are only active when there is an active tab. Service Workers live a little longer than that but only around 30 seconds or so last time I looked in Chrome (and that’s an implementation detail, not something in the spec), unless the user has enabled push events and you send one.
The typical concern is that a phisher will use to make a page that looks like Google's sign-in page and display it in fullscreen mode. This would let them collect credentials while mirroring the input in a real form that'd be filled in the background.
The new iOS 15 safari is full screen (and you’ve always been able to add to home screen to make a website really fullscreen)…