search

apache / cordova-plugin-inappbrowser

Apache Cordova InAppBrowser Plugin
https://cordova.apache.org/
Apache License 2.0
1.11k stars 2.14k forks source link

fix(GH-706): (android) Allow permissions requests #968

Closed joanbat closed 6 months ago

joanbat commented 1 year ago

Platforms affected

Android

Motivation and Context

Android in-app-browser does not allow in-browser camera/webcamera usage (permission denied) With this change, camera usage will be allowed as long as the app has permissions. Issue GH-706: https://github.com/apache/cordova-plugin-inappbrowser/issues/706

Description

Allows permissions requests from ChromeWebView

Testing

IAB would show permissions denied error in website https://webcam-test.com/ After the changes it successfuly works (requires app's camera permission to be enabled)

Checklist

ittlsa commented 1 year ago

plase confirm this fix.

breautek commented 1 year ago

Does this change assumes that you have the proper permissions declared in the AndroidManifest.xml? Usually you cannot request permissions unless if the app declares that it uses the permission in the manifest.

joanbat commented 1 year ago

Yes, the permissions must be declared in AndroidManifest.xml, additionally, permissions must be granted as with this change there is no OS permission popup if permissions have not been allowed.

breautek commented 1 year ago

additionally, permissions must be granted as with this change there is no OS permission popup if permissions have not been allowed.

Ok, so to be clear we have the following use cases:

Declared In Manifest means the <uses-permission> entry for the permission in question was present in AndroidManifest. Permission Granted Previously means that the permission was granted by some means outside of the WebView. Either via another action that triggered the OS permission prompt, or the user used the OS App Permission settings to enable permission manually. Permission OK'ed in IAB means that the permission was granted and the in-app-browser webview was able to utilise the feature.

Case 1

Declared In Manifest Permission Granted Previously Permission OK'ed in IAB
:heavy_check_mark: :heavy_check_mark: :heavy_check_mark:

Because the AndroidManifest contains the permission declaration, and the user has somehow previously granted permission (which has yet to be revoked), the IAB was able to receive the permission and utilise the related features.

Case 2

Declared In Manifest Permission Granted Previously Permission OK'ed in IAB
:x: :x: :x:

Because the AndroidManifest does not contain the permission declaration, the user would have never been able to have the permission granted previously, and naturally neither would the IAB browser.

Case 3

Declared In Manifest Permission Granted Previously Permission OK'ed in IAB
:heavy_check_mark: :x: :x:

The AndroidManifest does contain the permission declaration, but the user has yet to trigger a OS permission prompt somehow and does not have the permission currently granted. IAB is unable to trigger a permission prompt, so it will also fail to receive the grant.

Do these case results correctly represent the behaviour as the PR stands now?

joanbat commented 1 year ago

Exactly.

breautek commented 1 year ago

Awseome.. ok

Personally I feel like this doesn't go far enough to allow permission requests, but I understand it is still an improvement over what the plugin is doing now. Since this can be further improved later, I've written a snippet that I think we could probably include at the end of the README file that provides some notes regarding permissions.

### Permissions

Some webview features may require additional permissions. The in-app browser does not have the ability to grant additional permissions. However, on Android if the permissions have already been granted, the related featureset will become available. On iOS, permission-locked features may still be unavailable regardless of permission grants.

Also, I'm not certain if the iOS claim is accurate. I know this PR doesn't touch iOS, but we should double check iOS behaviour if possible. Unfortunately I'm not in the position to check this myself as I do not have access to a Mac. If we are unable to check the behaviour, then it might be better to scratch the On iOS, permission-locked features may still be unavailable regardless of permission grants. line. You can include the snippet if you like. Don't hesitate to rephrase or make edits if you feel like it's necessary. I'm definitely not convinced that my own wording is the best.

Outside of that, I think the PR is good but I'll request further input from a couple of other members who have worked more closely with the IAB than I have.

Note, I added the close keyword to close #706 but it seems the issue applies to both Android & iOS, so I reverted my edit as this PR only addresses the Android platform.

joanbat commented 1 year ago

Also, I'm not certain if the iOS claim is accurate. I know this PR doesn't touch iOS, but we should double check iOS behaviour if possible. Unfortunately I'm not in the position to check this myself as I do not have access to a Mac.

I only tested video, but during my tests I could use webcam and mic access on devices with iOS version 14.3 or higher - That's then WebRTC was introduced in WKWebKit, which is what IAB on iOS uses, as far as I am aware.

With the issue being reported prior to iOS 14.3 release (dec 14th 2020), and that I was able to use permission sensitive features from iOS's IAB during my tests, I would highly suspect it was entirely due to not supporting WebRTC on iOS, rather than having permissions passthrough issues.

breautek commented 1 year ago

Also, I'm not certain if the iOS claim is accurate. I know this PR doesn't touch iOS, but we should double check iOS behaviour if possible. Unfortunately I'm not in the position to check this myself as I do not have access to a Mac.

I only tested video, but during my tests I could use webcam and mic access on devices with iOS version 14.3 or higher - That's then WebRTC was introduced in WKWebKit, which is what IAB on iOS uses, as far as I am aware.

With the issue being reported prior to iOS 14.3 release (dec 14th 2020), and that I was able to use permission sensitive features from iOS's IAB during my tests, I would highly suspect it was entirely due to not supporting WebRTC on iOS, rather than having permissions passthrough issues.

Ok, so we can probably scratch the iOS claim in my snippet.

### Permissions

Some webview features may require additional permissions. The in-app browser does not have the ability to grant additional permissions. However, on Android if the permissions have already been granted, the related features will become available.
NiklasMerz commented 1 year ago

After setting the permissions I got the camera working on Android with this PR. I think it should be good to go with the small note in README.

I tested it on iOS, too and at least for my only real iOS device (iPad with iOS 16.1 beta) the camera does not work in the IAB.

Parag-Tharani commented 1 year ago

@NiklasMerz could you please approve above PR

kulkarni005 commented 1 year ago

Please Merge this to master

Meng991003 commented 1 year ago

I have tried with the above solution, adding the permission in AndroidManifest.xml and granted the access. But I still not be able to open the camera when using IAB. The website is using the input tag <input type="file" id="myFile" name="filename" accept="image/*> to get the input.

jooles commented 11 months ago

Any news on this? We need camera access for file type=input :) Thanks for reviewing, too, @NiklasMerz !

RemcovandenBerg commented 8 months ago

@NiklasMerz any reason the review and merge is being delayed? People are waiting on this. thx! @breautek Niklas seems inactive lately. Any change you could review or add someone (like me for example) to merge this?

StefaniToto commented 7 months ago

The fix is working. Thank you

NiklasMerz commented 6 months ago

@breautek If you think this fine feel free to merge. I could create a new release if we think it's a good time to do that.