Closed Bug 1548770 Opened 6 months ago Closed 5 months ago

File upload results in 0 byte file

Categories

(Firefox for Android :: General, defect)

ARM
Android
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 68
Tracking Status
firefox-esr60 --- unaffected
firefox66 --- unaffected
firefox67 --- unaffected
firefox67.0.1 --- unaffected
firefox68 --- verified

People

(Reporter: gerard-majax, Assigned: baku)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

Uploading files recently regressed on multiple websites, resulting either in error or in 0 byte file uploaded. 100% repro on Sony Xperia XZ2 Compact, Android 9.0.

A few days / weeks ago it was fine. Currently running uptodate nightly, installed from Play Store, 68.0a1 BuildID: 20190502095227.

STR:

  1. On a website allowing file upload, initiate file picker process
  2. Select image or file

Expected:
File / image gets properly uploaded

Actual:
File or image gets 0-byte upload, or error

Reproduced on:

  • Facebook chat, results in an error
  • Telegram, results in never-ending never-progressing upload
  • Fastmail, results in 0-byte file or image

[Tracking Requested - why for this release]:
Severe regression

Selecting image from Android/Sony's tools, selecting file from File Commander. It's not a size issue (image was 2MB, file was text file, PEM certificate, 2KB). Previously, on those services, I could upload 10-15MB images without any problem.

Hi,

I have managed to reproduce the issue on
-Facebook chat - error
-Fastmail - after downloading the file the it displays 0-byte details
-Telegram - the file fails to be uploaded

Environment
Device: Google Pixel C, Android (8.0.0)
Build: Firefox Nightly 68.0a1

Screenshots attached:
-Facebook Chat
-Fastmail
-Telegram Web version

Regards,
Diana Rus

OS: Unspecified → Android
Hardware: Unspecified → ARM

Diana, could you get a regression window?

Flags: needinfo?(diana.rus)

Hi,

The regression has been done on Sony Xperia Z5(Android 7.0.0) on build Firefox Nightly 68.0a1(2019-04-26), details below.

last good build: 2019-04-26 18:20:40.033000; changeset: daeba572395db4aa51076a85d1b908405152d50a
first bad build: 2019-04-26 18:43:06.546000; changeset: 4419a372fd717eba8619c454182e072fadfba447
Pushlog: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b13f2b24ae625d16fdeeb61cdec10978c3c75638&tochange=4419a372fd717eba8619c454182e072fadfba447

With respect,
Diana Rus

Flags: needinfo?(diana.rus)
Regressed by: 1534712

Hello,

Sorry to bother you Andrea, but according to comment #5, it's highly likely bug 1548770 regressed with the symptoms exposed in this bug.

Flags: needinfo?(amarchesini)

Out of interest, is this android-specific, ie is it working on desktop?

Flags: needinfo?(lissyx+mozillians)

(In reply to :Gijs (he/him) from comment #7)

Out of interest, is this android-specific, ie is it working on desktop?

I have not noticed the issue on desktop, and I just checked and it worked on my linux/ubuntu 19.04 with matching nightly

Flags: needinfo?(lissyx+mozillians)

esawin, can you help me here? I don't have an android build and I don't know how to debug this issue.

Flags: needinfo?(amarchesini) → needinfo?(esawin)

It's pretty easy to get an Android build going. https://mozilla.github.io/geckoview/tutorials/geckoview-quick-start#bootstrap-gecko

If you build for x86, you can use an accelerated emulator, so you don't even need a device.

Yep, building on android and running on an emulator is quite straightforward these days, and Android is a strategically-critical platform (just like Windows). Ping me or any of the folks in #gv (slack) if you need any help.

Given that this bug is on Fennec, it might be an e10s-vs-non-e10s thing. Does the bug reproduce with e10s disabled on Desktop? Lissy, does it reproduce in Fenix or the Reference Browser (based on GeckoView, which does have e10s)?

Flags: needinfo?(esawin) → needinfo?(amarchesini)
Flags: needinfo?(lissyx+mozillians)

(In reply to Bobby Holley (:bholley) from comment #11)

Given that this bug is on Fennec, it might be an e10s-vs-non-e10s thing. Does the bug reproduce with e10s disabled on Desktop? Lissy, does it reproduce in Fenix or the Reference Browser?

This was my thought as well. Tried in desktop w/o e10s and it seemed ok. Haven't tried in GVE w/o e10s though.

Sounds similar to bug 1511839

See Also: → 1511839

(In reply to Kevin Brosnan [:kbrosnan] from comment #13)

Sounds similar to bug 1511839

Not sure, this has been filed months ago, the current bug appeared only a few days ago.

Flags: needinfo?(lissyx+mozillians)

(In reply to Bobby Holley (:bholley) from comment #11)

Yep, building on android and running on an emulator is quite straightforward these days, and Android is a strategically-critical platform (just like Windows). Ping me or any of the folks in #gv (slack) if you need any help.

Given that this bug is on Fennec, it might be an e10s-vs-non-e10s thing. Does the bug reproduce with e10s disabled on Desktop? Lissy, does it reproduce in Fenix or the Reference Browser (based on GeckoView, which does have e10s)?

Does not seems to work in Fenix, but the behavior is different, so I can't tell if it's because of the same issue ...

Testing on latest Fennec / Fenix, with Telegram:

  • on Fennec, I can see the file "starting to upload", i.e. Telegram shows its name, a progress bar that gets stuck at <1%, and a Cancel button that works
  • on Fenix, I don't see the progress bar nor the filename, and when I try again to tap on the button to attach a file, it seems not working

I'm not sure it's really conclusive of anything.

Assignee: nobody → amarchesini
Flags: needinfo?(amarchesini)

Awesome work - thanks baku!

Pushed by amarchesini@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/47d40e2693bd
File.createFile() should not assume that the file doesn't exist, r=smaug
Duplicate of this bug: 1550678
Pushed by amarchesini@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/daa283778924
Better test for File.createFile(), r=smaug
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 68
Flags: in-testsuite+

Picked up the fix on my device during the weekend, it's working :)

Hi, I checked the issue with device Sony Xperia Z2(Android 5.1.1) on Fennec 68.1b1 build1 and Fennec 68.0 build3, I confirm that the issue is not reproducible.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.