App-visible behavior of blocking Camera & Microphone in VR is different from denied permission |
||||||
Issue descriptionChrome Version: 61.0.3143.0 Permission-requiring features are currently blocked in VR - both if the origin has not been granted the permission and in general ( issue 738209 ). The app-visible behavior should be the same as the origin not having the permission and/or the user choosing to block the permission. Based on experiments with https://permission.site/, this appears to be the case for all permissions except Camera and Microphone, which remain in an unresolved state. See the attached screenshots. The first shows the results after accepting all permissions/popups. Bluetooth and USB are red because I did not connect to a device. The second shows the result of refreshing the page, entering VR, and clicking all the buttons. Note that Camera, Microphone, and Camera + Microphone are all white rather than red. Permanent Storage is also white; this one is odd since it does not appear to request a site permission ever. The third shows the result of clearing all permissions for the site and declining every permission/popup. This is what the second image should look like in general. Any exceptions should be clearly understood.
,
Jul 5 2017
I thought that blocking permission requests while in VR was the intended behavior, as per the CL here: https://codereview.chromium.org/2904623002/
,
Jul 5 2017
Yes. The issue here is that it appears that if the site has been given permission previously (in 2D) and tries to use it while in VR, the promise is never rejected. (This is my assumption for why the buttons on https://permission.site/ remain white instead of red in the second picture.)
,
Jul 5 2017
Ah right, I see. Yes I think this is because audio/video don't currently go through PermissionManager::RequestPermission if they have been previously allowed (we just check PermissionManager::GetPermissionStatus). We should change that but it would require some reworking of the code I'm a bit reluctant to do that now because we've just done some large refactoring to that code and it needs bake time for M61. A good temporary solution might just be to check whether we are in VR in MediaStreamDevicesController::RequestPermissionsWithDelegate. If you folks want to add that check, I'm happy to take on the proper fix for ~M62 or so. wdyt?
,
Jul 5 2017
The other alternative fix would be to move the VR check into PermissionContextBase::GetPermissionStatus. This would ensure that all permissions are disallowed while in VR. That would probably fix the Persistent Storage issue too ...
,
Jul 14 2017
Adding a proper fix in M62 SGTM. Thanks.
,
Jul 24 2017
Given the backlog and that I'm going to be on vacation for 3 weeks I don't think that this is going to make M62 and would have to push it back to 63. The proper fix is probably a bit lower priority for us, so I would suggest that if you really would like a shorter-term fix you use one of the suggestions in #4.
,
Aug 9 2017
,
Aug 9 2017
Amir, would you be able to look at how simple the change in @4 is is?
,
Aug 11 2017
,
Oct 27 2017
This will be fixed when we allow permission dialog to show up in VR. I'll close this one and keep track of this in issue 779126. There won't be a simple fix, and it doesn't worth fixing it case by case. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ddorwin@chromium.org
, Jul 5 2017