I'm creating this landing page that's supposed to be triggered by a captive portal. on my landing page there's a button to trigger open a <video> element which is then used to scan qr code. By default, upon accessing webcam or device's camera the browser would ask user's permission first. So basically everything is working fine and all on browser.
Upon lodging it as a landing page triggered by captive portal, some inconsistencies arose. On most android phones my colleagues have, they simply deny the permission by default. On some android devices, the popup message asking for permission is showed, and working as expected just like the browser version. On IOS devices, the popup simply gets blocked (not denied, but ignored) I know it is ignored on IOS because the error message is not even showing, as if no action is given to the popup by the captive portal.
I've read several forums on captive portals, all led me to believe that captive portals by nature are simply a lighter version of build-in browser that simply doesn't have the capacity to run window.alert() and window.confirm() nor the ability to keep cookies. My "research" also led me to believe that captive portals have different set of behaviours unique to the OS, not the browser installed on that OS per se.
1 blog I read today, specifically the comment section, mentioned that from IOS 11.2 on, captive portals should already be able to run window.alert() and window.confirm(). However, upon testing it, this simply isn't the case.
So my question is, is there any way to work around this limitation, by still allowing user to decide whether to allow or deny camera access?
My "research" shows that it is impossible to redirect a captive portal to open on browser programmatically and only a handful of phones have a captive portal that comes with "open in browser" option.
Does anyone know any way to, say, intercept the permission popup in action and display it as just a normal html element then pass back the user response programmatically?
Thanks in advance! :)