Can't upload files with Tor browser on Android

With this latest Android Tor version 10.0.6 (83.1.0-Release) (Build #2015737915), I am unable to upload files to my regular cloud storage systems (Woelkli and ProtonDrive). I used to be able to, but no longer, while I can do so using the DuckDuckGo browser.

*I'm new to GitLab. Apologies if I'm posting in the wrong place - please advise!

Thanks!

Could you verify whether this issue occurs in the latest Firefox (for Android)?

added Needs Information label

This seems to be an issue with any site where you would want to upload a file from the Android filesystem, such as this one: https://upload.disroot.org. After choosing a file to upload, it does not appear on the site.

This issue also seems to affect services such as the ones offered by Onionshare https://github.com/micahflee/onionshare/issues/1221 since it uses the same upload function of the browser.

Tor Browser
10.0.7 (84.1.0-Release) (Build #2015737921)
AC: 67.0.11, release build
GV: 84.0-20200502080101
AS: 67.0.0

There aren't any error messages (or any relevant messages) in the browser console. I think there's a bug somewhere between selecting the file and the file becoming available to the web content.

removed Needs Information label

added UX + 1 deleted label

Hi @sysrqb! :)

Just wanted to add that this has been a common issue and we have got some tickets on RT related to this. If you would need any help in figuring/testing out what is going wrong, please let me know and I can get in touch with the users and help in any way possible.

Thanks!

mentioned in issue tpo/web/manual#79 (closed)

marked tpo/community/support#40011 (closed) as a duplicate of this issue

mentioned in issue tpo/community/support#40011 (closed)

removed 1 deleted label

removed UX label

added Bug Next UX labels

Hey @aguestuser, could we queue this bug up next after you've figured out what's going on in fenix#40192 (closed) please?

Also can I shift this to Fenix @sysrqb, or was it not moved for a reason?

assigned to @aguestuser

added Doing label and removed Next label

Okay, poking at this! I am able to reproduce the issue, and get an error log. (The error is weirdly logged at the WARN level -- although it is clearly a halting error -- which likely why @sysrqb did not see it.)

Here are details

emulator info

• pixel 4XL running android api v 29 (Q)

version info

• FX: 96.3.0, 093d02e69
• AC: 96.0.15, 992d53f7e9
• GV: 96.0-20141228000000
• AS: 86.2.2

steps

• open TBA, visit https://upload.disroot.org
• tap "click to open the file browser"
• observe the file picker fragment show me files on the file system
• tap an image
• observe the file selection fragment close immediately with no indication that file is uploading (same screen as i saw before selecting file)
• observe logs below

logs

2022-02-23 16:54:30.672 6017-6057/org.torproject.torbrowser_debug W/GeckoViewFilePickerDelegate: Error resolving files from file picker: [Exception... "File error: Access denied"  nsresult: "0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)"  location: "JS frame :: resource://gre/modules/FilePickerDelegate.jsm :: _getDOMFile :: line 125"  data: no] Stack trace: _getDOMFile()@resource://gre/modules/FilePickerDelegate.jsm:125
    _resolveFiles()@resource://gre/modules/FilePickerDelegate.jsm:75
    open/<()@resource://gre/modules/FilePickerDelegate.jsm:65
    onResponse()@resource://gre/modules/GeckoViewPrompter.jsm:139

so, sadly: appears to be an error at the GeckoView layer, which doesn't bode well for fixing it quickly. :(

Okay, poking at this! I am able to reproduce the issue, and get an error log. (The error is weirdly logged at the WARN level -- although it is clearly a halting error -- which likely why @sysrqb did not see it.)

[...]

logs

2022-02-23 16:54:30.672 6017-6057/org.torproject.torbrowser_debug W/GeckoViewFilePickerDelegate: Error resolving files from file picker: [Exception... "File error: Access denied"  nsresult: "0x80520015 (NS_ERROR_FILE_ACCESS_DENIED)"  location: "JS frame :: resource://gre/modules/FilePickerDelegate.jsm :: _getDOMFile :: line 125"  data: no] Stack trace: _getDOMFile()@resource://gre/modules/FilePickerDelegate.jsm:125
    _resolveFiles()@resource://gre/modules/FilePickerDelegate.jsm:75
    open/<()@resource://gre/modules/FilePickerDelegate.jsm:65
    onResponse()@resource://gre/modules/GeckoViewPrompter.jsm:139

Huh, interesting. Nice find!

The relevant code is:

123   _getDOMFile(aPath) {
124     if (this._prompt.domWin) {
125       return this._prompt.domWin.File.createFromFileName(aPath);                                                                                                                                       
126     }
127     return File.createFromFileName(aPath);
128   }

in mobile/android/components/geckoview/FilePickerDelegate.jsm.

I'm assuming File.createFromFileName is throwing NS_ERROR_FILE_ACCESS_DENIED, and _getDOMFile isn't catching it.

The next challenge is finding where this error is generated. I suspect it is here: https://searchfox.org/mozilla-central/source/xpcom/io/nsLocalFileUnix.cpp#349

 348   if (!FilePreferences::IsAllowedPath(mPath)) {
 349     mPath.Truncate();                                                                                                                                                                                 
 350     return NS_ERROR_FILE_ACCESS_DENIED;
 351   }

And, based on https://searchfox.org/mozilla-central/source/xpcom/io/FilePreferences.cpp#307 (FilePreferences::IsAllowedPath), we should look at the requested path.

You may be able to just log to the console the response: https://gitlab.torproject.org/tpo/applications/tor-browser/-/blob/geckoview-96.0-11.5-1/mobile/android/components/geckoview/GeckoViewPrompter.jsm#L139 (or at another point higher in the stack).

@sysrqb thanks for the pointers! diving in...

(wishing i had already resolved blockers with building geckoview locally... else: iterating w/ tor-browser-build seems like my best option?)

FYI, logged the response, which looks like this:

{files:["//data/user/0/org.torproject.torbrowser_debug/cache/uploads/gull-small.jpg"]}

also verified that upload is also broken on API version 28. which suggests that it is not a replication of scoped storage bug appearing to block downloads in fenix#40192 (closed))

update:

• i pinpointed the release that introduced the bug to 10.0a6 (using a manual "bisect" operation installing apks from our release archive)
• this release bumped android from 10.0a6 (10.0a7 was a desktop only release)
• more details on versions, etc... forthcoming
• note: there were no error logs at this commit/release (further explaining why nobody could find error logs when the bug was reported)

got a bit more context on when the bug was introduced: it appears to have manifested along with the transition from fennec to fenix.

the first alpha release manifesting the bug is the first alpha release we shipped with fenix. the last working alpha release ran fennec.

some metadata:

10.0a8 (breaking)

• tb-build commit: bff5d955
• date: 2020-10-07
• FF: 81.1.2,
• AC: 57.0.7,
• GV: 81.0.1

10.0a6 (worked)

• tb-build commit: 9871bb24
• date: 2020-08-19
• FF: 68.12.0esr

there's a pretty big surface area between those releases to cover but... dowager rod pointed in a direction.

added Next label and removed Doing label