-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bug: Android - Filesystem Plugin - Permission request cancellation results in endless loop #4170
Comments
This issue may need more information before it can be addressed. In particular, it will need a reliable Code Reproduction that demonstrates the issue. Please see the Contributing Guide for how to create a Code Reproduction. Thanks! |
ReproductionHere I put together a quick and dirty sample where the bug is reproduceable: https://github.com/kaunstdadenga/capacitor-filesystem-bug-sample
DocumentationHere is the official Android documentation where it is state in the "Note:" paragraph that it is possible that the request result might be empty, which should be treated as cancellation: https://developer.android.com/reference/androidx/core/app/ActivityCompat.OnRequestPermissionsResultCallback StacktraceI have added the full stacktrace to the git repo as it would exceed the comments maximum characters. https://github.com/kaunstdadenga/capacitor-filesystem-bug-sample/blob/master/stacktrace.txt Here is a part of the stacktrace of the endless loop:
|
Thanks for the sample app, the pr was merged, closing. |
Thanks for the issue! This issue is being locked to prevent comments that are not relevant to the original issue. If this is still an issue with the latest version of Capacitor, please create a new issue and ensure the template is fully filled out. |
Bug Report
Capacitor Version
latest Dependencies:
@capacitor/cli: 2.4.6
@capacitor/core: 2.4.6
@capacitor/android: 2.4.6
@capacitor/electron: 2.4.6
@capacitor/ios: 2.4.6
Installed Dependencies:
@capacitor/cli 2.4.5
@capacitor/android 2.4.6
@capacitor/ios 2.4.5
@capacitor/core 2.4.5
@capacitor/electron not installed
Platform(s)
Android
Current Behavior
When Android neither accepts or denies the permission request but instead cancels it, Filesystem does not recognise it as cancelled and neither finds a deny and restores the saved call. When processing the saved call Filesystem recognises that there is no permission for the Filesystem and request the permission again, which results in an endless loop and the app crashes.
Expected Behavior
As there are no methods to check for permissions on the capacitor Filessystem plugin, it should manage the permission dialogs correctly according to Android implementation.
Code Reproduction
Unfortunately I cannot provide a simple code to reproduce this behaviour as our project is quite large already. Additionally this problem only occurs when a modal is dismissed where the modal and the underlying view are trying to access some files and the User declined all the Filesystem Permissions to this part.
But I have pinpointed the Problem in the Android SDK (see Additional Context)
Other Technical Details
npm --version
output: 6.14.8node --version
output: v14.13.1pod --version
output (iOS issues only):Additional Context
To pinpoint the issue I looked into the Filesystem and Android Code and found the exact problem and already fixed it locally.
If you take a look at the Capacitor Filesystem.java v4.6 @ Line 664-674:
There the grantResults Array will be iterated and checked if any result contains "denied". If a denied permission is found the saved call is freed and an error is returned to the caller.
But if I take a look at the Android Activity.java SDK 28 @ line 5082 - 5084 (onRequestPermissionsResult)
Android also has the Option to cancel a request which is represented as an empty array.
If this occurs Filesystem won't iterate over the array and therefore does not find a permission denied and continues.
To catch this error locally in the filesystem in the node_modules, I simply added an additional check in the Filesystem logic before the for loop gets executed:
There I check if the array has a length of 0. If this is the case I handle the call as if Android would have denied the permission. For me this was enough, but it would be even nicer if there would be a different Error like "PERMISSION_CANCELLED_ERROR".
The text was updated successfully, but these errors were encountered: