Choose File option does not work

[Bhupesh-V]

Describe the bug
The option to update the profile picture on the app is not responding.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Settings/Profile Image'
2. Click on 'Choose File'
3. See error

Expected behavior
The button does not respond.

Smartphone (please complete the following information):

• Device: [Tenor G by Amazon]
• OS: [e.g. 8.0 "Oreo"]

[subbramanil]

I have a fair idea of how to fix this.

After googling for some time, I came to know that, the WebViewClient doesn't help a lot in this case, but WebChromeClient does. But both WebViewClient and WebChromeClient offer different sets of functionalities, so replacing WebViewClient with WebChromeClient will not help.

Also, Webview can have both WebViewClient as well as WebChromeClient. And depends on the functionality requires, it uses the appropriate client.

binding.webView.webViewClient = CustomWebViewClient(this@MainActivity, binding)
binding.webView.webChromeClient = CustomWebChromeClient(this@MainActivity, binding)

First step would be creating a CustomWebChromeClient extending WebChromeClient and override the function, onShowFileChooser().

The second step would be creating an implicit intent to launch any app(file browser, gallery, etc.,) that helps you to pick the photo.

val intent = Intent()
// Show only images, no videos or anything else
intent.type = "image/*"
intent.action = Intent.ACTION_PICK
// Always show the chooser (if there are multiple options available)
ActivityCompat.startActivityForResult(
    this,
    Intent.createChooser(intent, "Select Picture"),
    100,
    null
)

The above block of code will launch the app chooser with the apps that can handle the intent.

The third step would be getting the file uri from the data being returned and access the file.

I'm able to complete so far. From my understanding, the next step would be making a call to the rest API to upload the file to the cloud storage. But I'm stuck, as I'm not able to figure out the API endpoint to upload the file.

I am assuming that Dev.to uses s3 or some cloud storage to store the profile pics. But once I upload the profile pic, the s3 path should be available in the 'Profile' form, so that it can be saved when clicking on 'submit' at the bottom. I'm not sure how that works as of now.

The incomplete code is available in commit

[maestromac]

Thank you for that detailed step @subbramanil !

If i'm following this correctly, the upload should be done automatically via the web-app. All you have to do is hit "save" at the bottom of the page and user profile will be updated.

[subbramanil]

Yeah, I see what you mean. When I click on 'submit', the form field "Choose File", should have the path to the chosen image. When you click on 'save', it submits the form which updates the profile.

[maestromac]

I found an edge-case with the upload feature. If the gallery is launched by choose file and nothing was selected (ie. closing the gallery), subsequent clicks on choose file will not prompt the launcher.

[subbramanil]

@maestromac My bad, I didn't test it thoroughly.

Found what's actually causing it and fixed it. Testing the fix right now.

I will submit another PR by the end of today.

[subbramanil]

@maestromac I have submitted a PR that fixes the issue. This is the simplest solution without saving any state information.

Just a heads-up, The below behavior is the intended behavior of Android.

1. Click on Choose File and go to the gallery and select a pic
2. The form field shows the file chosen
3. Click on Choose File again, and cancel the operation by clicking 'back'/choose nothing in the gallery
4. The previously chosen pic is cleared

When you click on Choose File, You are leaving from the current app with the intention of selecting a pic. When you press back without selecting a pic, that resets the last value received.

To avoid that, We can try cache the chosen pic name locally but there's no callback to clear the cache once the form is submitted. I will look into this further to see if there's anything we can do.

[maestromac]

No worries and thanks for such a fast fix @subbramanil ! In regard to that intended android behavior, that can be addressed in another PR since I doubt many will encounter this bug.

[maestromac]

Resolved with #26 #34