await Filesystem.requestPermissions() hangs forever

[TDola]

Bug Report

Plugin(s)

capacitor/filesystem

Capacitor Version

Latest Dependencies:

  @capacitor/cli: 5.5.0
  @capacitor/core: 5.5.0
  @capacitor/android: 5.5.0
  @capacitor/ios: 5.5.0

Installed Dependencies:

  @capacitor/cli: 5.5.0
  @capacitor/android: 5.5.0
  @capacitor/core: 5.5.0
  @capacitor/ios: 5.5.0

Platform(s)

Android

Current Behavior

If you await the result, or .then() the result, it never resolves when the user click allow.

Expected Behavior

The promise should resolve

Code Reproduction

https://github.com/TDola/capacitor-file-system-request-error/tree/master

// be certain the permission is not already granted, go into app settings and disable storage permission if it is enabled
import { Filesystem } from '@capacitor/filesystem'
const results = await Filesystem.requestPermissions()
console.log(results)

Other Technical Details

Running inside android API 26 emulator

Additional Context

It does console log this, and it does grant the permission. So if you force quit and reload, it does resolve the promise the second time

I don't really know Java, but I am trying to trace this, and I notice in this function
node_modules/@capacitor/filesystem/android/src/main/java/com/capacitorjs/plugins/filesystem/FilesystemPlugin.java

private void permissionCallback(PluginCall call) {
        if (!isStoragePermissionGranted()) {
            Logger.debug(getLogTag(), "User denied storage permission");
            call.reject(PERMISSION_DENIED_ERROR);
            return;
        }

        switch (call.getMethodName()) {
            case "appendFile":
            case "writeFile":
                writeFile(call);
                break;
            case "deleteFile":
                deleteFile(call);
                break;
            case "mkdir":
                mkdir(call);
                break;
            case "rmdir":
                rmdir(call);
                break;
            case "rename":
                rename(call);
                break;
            case "copy":
                copy(call);
                break;
            case "readFile":
                readFile(call);
                break;
            case "readdir":
                readdir(call);
                break;
            case "getUri":
                getUri(call);
                break;
            case "stat":
                stat(call);
                break;
            case "downloadFile":
                downloadFile(call);
                break;
        }
    }

call.resolve() is never called. I don't know how getMethodName works but there isn't a case for requestPermission or a default

So I added this to the end

            default:
                JSObject permissionsResultJSON = new JSObject();
                permissionsResultJSON.put(PUBLIC_STORAGE, "granted");
                call.resolve(permissionsResultJSON);

And it seems to have made it happy

[Ionitron]

This issue needs more information before it can be addressed.
In particular, the reporter needs to provide a minimal sample app that demonstrates the issue.
If no sample app is provided within 15 days, the issue will be closed.

Please see the Contributing Guide for how to create a Sample App.

Thanks!
Ionitron 💙

[TDola]

This issue needs more information before it can be addressed. In particular, the reporter needs to provide a minimal sample app that demonstrates the issue. If no sample app is provided within 15 days, the issue will be closed.

Please see the Contributing Guide for how to create a Sample App.

Thanks! Ionitron 💙

Here is a repo that reproduces the issue.
https://github.com/TDola/capacitor-file-system-request-error/tree/master
It is a bit restrictive in what emulator can run it because the code in the example app requires a very new version of javascript, but API 29 was the sweet spot. But my original test was done on API 26. On API 30 the problem does not happen because storage permission is granted by default.

[ionitron-bot]

This issue has been labeled as type: bug. This label is added to issues that that have been reproduced and are being tracked in our internal issue tracker.

[agustinramos]

Hi @TDola @Ionitron

I leave PR with the fix

#1981

[ionitron-bot]

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 the plugin, please create a new issue and ensure the template is fully filled out.