Should not need to re-check the camera permission at the Android OS level |
||||||
Issue descriptionIn arcore_device.cc PermissionManager is being used to check if the video capture permission has already been granted to the page or if it needs to be requested. This process seems to work well. If the camera permission is granted, the application starts arcore. But if the Android OS level camera permission is revoked for Chromium, PermissionManager still returns GRANTED as the status. A new Java level check has been added that should not be needed. This bug's goal is to find out what is wrong with how PErmissionManager is being used.
,
Apr 28 2018
Permissions folks, any idea why revoking the Android permission would not cause Chrome to either a) request the permission again or b) return DENIED?
,
Apr 29 2018
We've had discussions in the past about where PermissionManager should incorporate the device level permission since there are times when you don't want that to happen. In the specific case of Camera/Mic there is very complicated logic for requesting Mic/Camera permissions because they can be requested together. Simply including the device-level permission in the return value of GetPermissionStatus would break that logic. Confusingly, currently the version GetPermissionStatus that takes a PermissionType (rather than a ContentSettingsType) will include the device level permission for Geolocation only. There is a bug to refactor this somewhere and what we may want to do is expose the option to query both values from the PermissionManager API (possibly just be adding an extra function).
,
May 1 2018
,
May 24 2018
This CL https://chromium-review.googlesource.com/c/chromium/src/+/1055677 addressed this bug.
,
May 28 2018
,
Jun 8 2018
It looks like we do need to do this and have done so for issue 835037 . Thus, this is Won't Fix.
,
Jul 4
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ijamardo@chromium.org
, Apr 27 2018