1299548 - Firefox for Android URL encodes unsafe characters literally in downloaded file names.

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Download Manager, defect, P3)

Description

[Devin Hussey]

User Agent: Mozilla/5.0 (Windows NT 10.0; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160817112116

Steps to reproduce:

Downloaded a file with an unsafe character in the filename (usually a space) and tried to open it.

For example, we will be using "file name.pdf".

Device info:
Samsung Galaxy S III (Qualcomm) 
SAMSUNG-SGH-I747
Android 6.0.1 (CyanogenMod 13.0)
Firefox for Android 47.0


Actual results:

First, Firefox replaces unsafe characters in the file name. So, if I have "file name.pdf" and I download it, it appears in the notification and in the file system as "file%20name.pdf".

My educated guess is that Firefox is URL encoding the filename twice. So, the first time, it becomes "file%20name.pdf", properly converted back by the download manager, but the second time, it becomes "file%2D20name.pdf", encoding the "%" in "%20". 

The download manager interprets it as a literal "%", then a "20", resulting in the filename in the Download folder being "file%20name.pdf".

--

Second, this also causes this:

When you open that file by clicking the notification or the Snackbar, according to the logcat, Firefox fires an Intent for "file:///storage/emulated/0/Download/file name.pdf", but the actual file is "file:///storage/emulated/0/Download/file%20name.pdf". 

When the target app tries to open it, it looks for the wrong file, resulting in a java.io.FileNotFoundException error.

So opening many downloaded files fail because of this encoding error. It is really annoying, and should be fixed soon, if it hasn't already been fixed in Nightly/Aurora/Beta builds (have yet to test, will update on it soon).

Going to a file manager and clicking on "file%20name.pdf" opens it fine. 

A side note, looking at Chrome's intent in the logcat, it fired "content://downloads/my_downloads/<some number>". Looks like it uses a ContentResolver.


Expected results:

Firefox downloads the file with the proper name of "file name.pdf", and opens it properly when clicked on.

Comment 1

[Devin Hussey]

OK I looked into this, and I can not for the life of me understand the spaghetti in the repo.

However, I noticed that the file name problem is a relatively common issue in Stack Overflow, especially because it appears that we are not actually using DownloadManager.

Many of them were solved because they were *not* parsing the filename, and it just needed to be parsed.

This tutorial...
    https://developer.android.com/training/basics/data-storage/files.html
...does not actually cover spaces, but it has this interesting snippet of code:

public File getTempFile(Context context, String url) {
    File file;
    try {
    --> String fileName = Uri.parse(url).getLastPathSegment(); <--
        file = File.createTempFile(fileName, null, context.getCacheDir());
    } catch (IOException e) {
        // Error while creating file
    }
    return file;
}

This may be an answer we are looking for. It just needed to be parsed.

However, I would like to know answers to some of these:

1. Why are we not using the DownloadManager? It would simplify a lot of things.

2. Do people _really_ need a pause/resume button? If one wants to pause a download, they click on the in-progress download, it takes them to the Downloads app, and they can tap on it to pause. Nobody else seemed to have a problem with it in the 50 other Android browsers out there, and there would be less of a need to listen to the notification.

3. Do we get any benefit from the method we are currently downloading files over using the DM? Because we can query downloads by id, and besides, if we really need that pause/resume, check https://github.com/JiboStore/DownloadProvider for a 100% compatible replacement for DM.

4. If we do switch, can we solve one of (at least my) OCD issues by me, bug 1185300? We won't need to set our own icon, and Android will use the default. Instant fix.

Comment 2

[Nevin Chen(Not active on Bugzilla)]

Hi! Thanks for reporting!
I can't reproduce this error on LG Nexus 5(M) ASUS  Zenfone2(L) Sony Z3C(L) and Samsung Tab3(JB) but I can't reproduce the issue.
Would you mind if you upgrade to the latest version and try again?
Thank you!

Comment 3

[Nevin Chen(Not active on Bugzilla)]

I'll close this bug first. If it happens again, please feel free to reopen it or let me know. Thank you!