[Webkit-unassigned] [Bug 253186] REGRESSION iOS 16.4 beta selects ultra-wide for facingMode: environment

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=253186

--- Comment #10 from Simon Taylor <simontaylor1 at ntlworld.com> ---
Thanks for asking.

https://web.zappar.com shows one of our "WebAR" runtimes built on getUserMedia, motion sensor data, and web assembly. Once you tap launch you'll see the `facingMode: environment` camera by default which is now equivalent to the ultra-wide on my iPhone 14 Pro on the current 16.4 beta.

There's a "switch camera" button in the toolbar to switch to the user-facing one and back. That's the "simple UI" I mentioned in the original report rather than offering the full enumerated drop down (which now lists no less than 7 devices with the latest beta on the iPhone 14 Pro).

I think that's enough to see this as a regression - the toggle doesn't do the same thing as in the native camera app, which starts up by default with the "1x / Wide" camera FOV. It means you've got to be twice as close to objects in the web now to view them at the same size, and there's a more extreme and unusual perspective effect on the images.

In terms of the actual impact on our sites, it causes a regression in tracking quality as our computer vision algorithms assume a standard field-of-view. You can open the site at https://docs.zap.works/app-embed/regression-tests/ on a laptop screen and scan the #3 code, then point towards the target image at the top of the page. When viewing from non-straight on angles you can see the green background plane should align with the image on the screen but the perspective is significantly different, and the content doesn't feel properly "anchored" in the camera view (as the virtual camera field-of-view is very different from the camera one).

To avoid this regression, we would need to manually enumerate and select the "correct" rear facing camera (Connell covered the challenges of doing this with localized names in a previous comment - we'd likely rely on enumeration order for now, but that's not guaranteed in any spec so we'd need to check webkit code to see if it is at least a short-term solution).

As well as needing to figure out the "right" workaround for for our camera selection code, we'd also need to deploy updated sites. We have some "shared" runtime sites like web.zappar.com, but also hundreds of domains with white-labelled versions. Alongside that we have SDKs for common WebGL engines like three.js distributed as npm packages, which customers can bundle whatever versions of into their independent builds. To get those updated we'd need to give an advisory to customers along with a reasonable time for them to update their dependencies (which they may be unwilling or unable to do for various reasons).

Hopefully that gives some insight into the level of disruption and difficulty this change would cause for us.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230315/5d9c4706/attachment.htm>