Context: I have a web app with a hash router. Once I am done analysing the camera stream and showing results my router changes the hash to a result route. When I come back to the camera view, I am prompted for the camera permissions again, even though I never left the web app. This behaviour does not happen in Safari for iOS. Current behaviour: In standalone mode, iOS is revoking the camera permissions every time the hash changes. Expected behaviour: In browser mode, once I am granted the camera use by the user, I can change the hash without loosing the camera permissions. Steps to reproduce: 1) Add a video tag to page 2) Ask for camera permissions and attach the stream to the video tag 3) Add a <a href="#"> to page 4) click on link In standalone mode: video stream is gone. In browser mode: video stream is still there. Current workaround: Set the Vue router to abstract mode.
<rdar://problem/68001080>
Thanks, I was able to repro with airhorner. It seems as if there is a navigation which stops all the capture tracks and reset the permissions when doing hash navigations in Web.app but not iOS Safari.
I have multiple PWAs which scan barcodes using and show the camera preview with getUserMedia. They use Angular routing. Everything works fine in Safari, but when added to home screen (PWA), the camera permission prompt will appear every time the route changes. Currently the only workaround we can offer to users is to provide blanket camera permissions (all web sites) in Safari. This is probably related to this issue.
(In reply to Alex Suzuki from comment #3) > > Everything works fine in Safari, but when added to home screen (PWA), the > camera permission prompt will appear every time the route changes. > > This is probably related to this issue. We have exactly this problem with our PWA which is based on QR scanner. It would be nice to have this working as in Safari.
(In reply to Alex Suzuki from comment #3) > I have multiple PWAs which scan barcodes using and show the camera preview > with getUserMedia. They use Angular routing. > > Currently the only workaround we can offer to users is to provide blanket > camera permissions (all web sites) in Safari. > Whad did you mean by this? Can you explain this workaround more please?
(In reply to Michal from comment #5) > (In reply to Alex Suzuki from comment #3) > > I have multiple PWAs which scan barcodes using and show the camera preview > > with getUserMedia. They use Angular routing. > > > > Currently the only workaround we can offer to users is to provide blanket > > camera permissions (all web sites) in Safari. > > > > Whad did you mean by this? Can you explain this workaround more please? In iOS Safari, users can persistently grant camera/microphone access from Safari UI.
Created attachment 416332 [details] Per site setting iOS UI
I uploaded a screenshot that shows where to get per-site settings UI
(In reply to youenn fablet from comment #8) > I uploaded a screenshot that shows where to get per-site settings UI Yes I see, thank you for explanation of this. Of course this is working but there is need to do it manually by users. Which I don't want to delegate this problem to end-users. If you are calculating with thousands of them. Our problem is mainly with "Installed" PWA - "Add to Home screen" (in Safari), where this permission is not persisted after you did this install of the app.
As a temporary workaround, I wonder whether the following would work: - Start capture - Before navigating inside the page, stop the capture by calling stream.getTracks().forEach(t => t.stop()) - Navigate within the same page - Restart capture (hopefully without a prompt this time).
*** Bug 212040 has been marked as a duplicate of this bug. ***
The fix is not in WebKit but in Safari standalone mode implementation. I'll keep this bug open until validation is done this works as expected.
I don't think this issue is with Safari implementation. It also happens when running an app with WKWebView. Any changes to the path of the URL causes calls to `getUserMedia` to request permissions from the user again.
It looks like the problem is a bit more serious in WKWebView. After allowing the prompt, any subsequent calls to `getUserMedia` after some period of time (looks to be about 90 seconds) will also trigger the prompt for permissions. This happens even without navigating away from the page, regardless of if the user was active or inactive in that time.
(In reply to Mauricio W from comment #14) > It looks like the problem is a bit more serious in WKWebView. > > After allowing the prompt, any subsequent calls to `getUserMedia` after some > period of time (looks to be about 90 seconds) will also trigger the prompt > for permissions. > > This happens even without navigating away from the page, regardless of if > the user was active or inactive in that time. This is a different bug, which might best be fixed by exposing a delegate to control getUserMedia prompt. If capture is ongoing, prompt should not happen again until 24 hours. If capture is not ongoing, prompt should happen again after 1 minute of inactivity. This is the same behavior as Safari.
Thanks for the reply, youenn. The documentation for this is rather scarce, so I wasn't sure. Thank you for clearing that up. I don't mean to sidetrack this thread, but since you brought it up: could you explain a bit more on how I could use a delegate to handle this? Reading through the WKWebview documentation there doesn't seem to be an obvious answer to me. I also spent some time trying to understand how the UserMediaRequest gets sent out, but I couldn't really understand the flow.
(In reply to Mauricio W from comment #16) > Thanks for the reply, youenn. The documentation for this is rather scarce, > so I wasn't sure. Thank you for clearing that up. > > I don't mean to sidetrack this thread, but since you brought it up: could > you explain a bit more on how I could use a delegate to handle this? Reading > through the WKWebview documentation there doesn't seem to be an obvious > answer to me. I also spent some time trying to understand how the > UserMediaRequest gets sent out, but I couldn't really understand the flow. UserMediaRequest is sent through IPC to UIProcess. It is processed in UserMediaPermissionRequestManagerProxy which ultimately may call a WKWebView delegate dedicated to getUserMedia permission. This delegate is not yet exposed though.
I too have PWAs that use the camera to scan barcodes. It's proving very cumbersome for our users to confirm camera access every time they try and scan a QR code. The workaround to always allow camera access across all Safari websites is a *really bad workaround* because it completely breaks user's privacy controls, just so they can seamlessly scan barcodes using our app.
I can also confirm this issue via a PWA install on home screen, the camera is requested on every page there is a camera instance initiated.
Please check this in latest iOS 14.5 beta.
In 14.5 the prompt for camera permission does not show on every page anymore. That's an improvement, but the camera permission is not conserved over multiple session. That means the camera permission prompt still shows up, when the application is closed and reopend again. Are there any plans to resolve this behaviour too?
This issue is still current with 16.3.1. User experience is miserable when multiple scans are performed more than 1 minute apart in standalone mode
I wonder if some can provide some insight for me. Some claim this issue is resolved, others claim the issue persists. I've tested on MacOS 12.6.8 w/ Safari 16.6: Visit e.g. Google.com then `getUserMedia()` and `enumerateDevices` acts as expected. Attempting the same with (Swift's Webkit) only enumerate an empty input device and hangs when calling `getUserMedia`. Is this expected?