Closed Bug 1310491 Opened 3 years ago Closed 2 years ago

Canceling "Complete action using" still downloads the whole file and leaves it inaccessible

Categories

(Firefox for Android :: Download Manager, defect, P1)

All
Android
defect

Tracking

()

VERIFIED FIXED
Firefox 60
Tracking Status
firefox49 --- wontfix
fennec + ---
firefox50 --- wontfix
firefox51 --- wontfix
firefox52 --- wontfix
firefox-esr52 --- unaffected
firefox58 + verified
firefox59 --- verified
firefox60 --- verified

People

(Reporter: c.ascheberg, Assigned: JanH)

References

Details

(Whiteboard: [TPE-1])

Attachments

(2 files)

Tested on a Nexus 4 running stock Android 5.1.1.

Steps to reproduce:
1. [Example] Open Mozilla Nightly website and click link to download apk
2. Firefox will show a dialog "Complete action using"
3. Tap Android back button to cancel

Result:
Firefox will download the whole file in the background without any visual indication.
This leads to increased data usage and wasted storage space. You can see the used storage space in "Settings - Storage - Downloads". It is not easily possible to delete the .part file, because it is not listed in the Android Downloads app, and it is not deleted when clearing app cache.

Expected:
Maybe the download should not even start at that step. But the download should at least stop and the .part file should be deleted.
tracking-fennec: --- → ?
Hardware: Unspecified → All
Severity: major → normal
Priority: -- → P2
Whiteboard: [TPE-1]
We should not use speculative downloading when on mobile data. It should continue to work when on WiFi.
tracking-fennec: ? → +
Mass wontfix for bugs affecting firefox 52.
From bug 1426156 comment 7:

> Speculatively starting the download in the background is the intended behaviour,

I would think the user needs to consent to dowloading before we begin a download on the basis of privacy, potential exploits, and unexpected data usage. To me, clicking a link does not constitute consent to download something to the device.

[triage] Moving P1 to re-evaluate but I'm not convinced this is critical. Susheel, what do you think?
Flags: needinfo?(sdaswani)
Priority: P2 → P1
(In reply to Michael Comella (:mcomella) [please needinfo for a response] from comment #4)
> From bug 1426156 comment 7:
> 
> > Speculatively starting the download in the background is the intended behaviour,
> 
> I would think the user needs to consent to dowloading before we begin a
> download on the basis of privacy, potential exploits

I don't see why we should be in a different situation than desktop Firefox here...

> and unexpected data usage.

... though I agree on that one, at least when we're on a metered connection.
I'd suggest leaving any further discussion regarding speculative downloads on metered connections or otherwise to bug 1384811.

As for the immediate issue at hand, I think I've found where we made a mistake.
Assignee: nobody → jh+bugzilla
See Also: → 1384811
Mike, given we have a proposed fix, let's keep it P1 and assume it gets closed soon. We can reevaluate if it doesn't.
Flags: needinfo?(sdaswani)
Comment on attachment 8946015 [details]
Bug 1310491 - Part 1 - Always properly clear speculative downloads when forwarding a download.

https://reviewboard.mozilla.org/r/216082/#review222032
Attachment #8946015 - Flags: review?(esawin) → review+
Comment on attachment 8946016 [details]
Bug 1310491 - Part 2 - Abort speculative download if user backs out of our App Chooser dialogue.

https://reviewboard.mozilla.org/r/216084/#review222036
Attachment #8946016 - Flags: review?(esawin) → review+
Pushed by mozilla@buttercookie.de:
https://hg.mozilla.org/integration/autoland/rev/fecef9e5df9a
Part 1 - Always properly clear speculative downloads when forwarding a download. r=esawin
https://hg.mozilla.org/integration/autoland/rev/e479bda148a0
Part 2 - Abort speculative download if user backs out of our App Chooser dialogue. r=esawin
Comment on attachment 8946016 [details]
Bug 1310491 - Part 2 - Abort speculative download if user backs out of our App Chooser dialogue.

Approval Request Comment
[Feature/Bug causing the regression]: Downloads on Android
[User impact if declined]: If the user cancels a download by exiting our app chooser dialogue without choosing anything, the download continues invisibly in background.
[Is this code covered by automated tests?]: No.
[Has the fix been verified in Nightly?]: Verified locally.
[Needs manual test from QE? If yes, steps to reproduce]: 1. Start a download that triggers our app chooser dialogue, e.g. an APK download from ftp.mozilla.org.
2. Press "back" to exit the dialogue without choosing anything.
3. No temporary ".part" file should be left behind in the Downloads directory.
[List of other uplifts needed for the feature/fix]: Part 1, although it's an optional improvement and not strictly necessary to fix the main issue.
[Is the change risky?]: No.
[Why is the change risky/not risky?]: Just adding the missing call to actually cancel the speculative background download if the user chooses nothing. We already cancel the download in the same way when the user *does* choose to complete the download with an app other than Firefox.
[String changes made/needed]: none
Attachment #8946016 - Flags: approval-mozilla-release?
Attachment #8946016 - Flags: approval-mozilla-beta?
https://hg.mozilla.org/mozilla-central/rev/fecef9e5df9a
https://hg.mozilla.org/mozilla-central/rev/e479bda148a0
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 60
Sorina, can you verify the fix on nightly before we uplift to beta? Thanks!
Flags: qe-verify+
Flags: needinfo?(sorina.florean)
I was able to reproduce the issue on 59.0b5 and release builds with Nexus 5 (Android 6.0.1) and Google Pixel (Android 8.0) following the steps from description and comment 13. Tested on latest Nightly build (60.0a1 from 01/31) with the affected devices, following the same steps, and the apk.part file was not displayed in storage.
So verified as fixed on Nightly 60.
Flags: needinfo?(sorina.florean)
Comment on attachment 8946016 [details]
Bug 1310491 - Part 2 - Abort speculative download if user backs out of our App Chooser dialogue.

Verified in Nightly, let's uplift for beta 6.
Attachment #8946016 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment on attachment 8946015 [details]
Bug 1310491 - Part 1 - Always properly clear speculative downloads when forwarding a download.

It looks like this should also be uplifted to beta along with part 2. Jan, is that correct?
Flags: needinfo?(jh+bugzilla)
Attachment #8946015 - Flags: approval-mozilla-beta+
Ah, I see where you mentioned Part 1 now.
Flags: needinfo?(jh+bugzilla)
Comment on attachment 8946016 [details]
Bug 1310491 - Part 2 - Abort speculative download if user backs out of our App Chooser dialogue.

The user impact here is pretty severe, fix was verified on nightly60, safe enough to include as a ride-along in Fennec 58.0.2.
Attachment #8946016 - Flags: approval-mozilla-release? → approval-mozilla-release+
Device:
 - Samsung Galaxy Tab S3 (Android 7.0);

 Verified this using the steps provided in Comment 13 in both Beta (59.0b7) and Release (58.0.2), the issue is fixed nothing has been downloaded without the user actually confirming the download action. 
 Marking as verified.
Status: RESOLVED → VERIFIED
I have tested this on Firefox for android on version 58.0.2 and Firefox Beta 59.0 on android this issue of speculative download still exists and has not been resolved, downloads still start without even asking in background and continue even after exiting the "app Chooser" dialogue.  I have tested this on Xiaomi Mi A1 Android One device running on android Oreo. Please solve this bug it is consuming a lot of mobile data in the background just today i have lost 1GB of mobile internet data.
Duplicate of this bug: 1439075
(In reply to za1175014 from comment #24)
> downloads still start without even asking in background
That is a known limitation of the way downloads currently work, see bug 1384811 and bug 
438905.

> continue even after exiting the "app Chooser" dialogue.
I'm afraid I can't reproduce that.
This bug was verified on Firefox 58, 59, 60. Remove the Qe-verify+ flag.
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.