1384811 - Download notification needed - Because automatical downloading starts without users' knowledge after tapping on pictures or opening some websites

Status: RESOLVED INCOMPLETE

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

Description

[Bingqing Li]

Attachment: download-notification.png

Steps to reproduce:
---------------------------------
1. Launch Firefox for Android

2. Goto https://tieba.baidu.com/mo/q---DB37EC6644B843E25F1470360B78C17F:FG=1-,-2-3-0--2/m?kz=5135197711&lp=7202&pinf=__&pn=0&

3. Tap any of the images
   ==> Start to download file - Baidu Tieba apk.
       Users need to go to the notification center to cancel this download.


Additional info:
------------------------
Users complained a lot about this issue increasing their mobile data costs.

Sometimes the downloading even starts right after opening some (weird) websites.

In MozillaOnline build, there is a popup window before every downloading begins, asking users whether to download the file or not.

But there still is a problem:
The downloading is still ongoing on the background until users tap on "ignore" when using mobile date, which still consumes a lot of mobile date without users' knowledge.

Comment 1

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Talked to Beijing team and figured out what's needed here.

Essentially they would like to see bug 1303929 getting implemented, so we only start the download with user consent every time. There has been a long discussion there for and against the feature, so there is no need to repeat here. The bottom line is, it's still pending.

The alternative is to get their own implementation of the dialog properly. Currently, their dialog (with the screenshot above) cannot pause the download -- it will prompt, but as comment 0 says, it only stops the download once the user hits 'ignore,' instead of waiting for the user to hit 'download'. This would require people familiar with that part of Gecko to figure out how to do it.

Comment 2

[Jan Henning [:JanH]]

Showing a confirmation dialogue every time isn't what bug 1303929 is about, though - the problem there is only that once you've chosen to "always" use a specific app for handling a certain MIME type, you cannot reset that choice without going into about:config. The proper fix for that is providing a reset button (ideally per file type, although a general reset for all MIME types would probably also be acceptable and easier to implement), *not* side-stepping the issue by showing the dialogue every time and therefore taking away the choice of "Always" using a certain app for downloading a specific file type.

Besides, while I appreciate the issue of wasting data volume on potentially unwanted downloads on a metered/capped connection, conversely if you're on an unmetered connection where data usage is unimportant, downloads starting automatically, respectively speculative background downloads while the helper app dialogue is being shown can also be a valuable feature.

Therefore, my personal choice would be to implement this along the following lines:

The helper app dialogue should have an unlimited mode and an additional data saving mode. In unlimited mode, it's operation would be unchanged, that is
- the user choice to "Always" use a certain app for a certain MIME type should be respected
- when there is no choice of different apps, the downloads starts immediately
- when there is a choice and we display the helper app dialogue, we still start a speculative background download

In data-saving mode on the hand,
- the dialogue would be shown every time, even when a default app is available or there is only one choice
- the download doesn't start until the user made a positive choice

The data-saving mode could then be configured from the settings to be used
- Always
- On metered connections only (i.e. mobile data and metered wifi connections as defined by the OS) - could be our default setting?
- Never

If I remember correctly do have some sort of network type detection service already implemented (although I'm not sure whether it already properly handles metered Wifi connections) to turn our offline cache on and off, although it potentially still seems to have some issues on some phones.
I'm not really familiar with our download handling, though, so I'm not sure how easily speculative background downloads could be dynamically turned on and off depending on settings and network connection conditions.

Comment 3

[Jan Henning [:JanH]]

(In reply to Jan Henning [:JanH] from comment #2)
> In data-saving mode on the [other] hand,

... and instead of saying "Always" and "Just once", the buttons should read something like "Download" and "Cancel", of course.

Comment 4

[Bingqing Li]

Attachment: UC-download-mgr-icon.png

(In reply to Jan Henning [:JanH] from comment #2)
> Therefore, my personal choice would be to implement this along the following
> lines:
> 
> The helper app dialogue should have an unlimited mode and an additional data
> saving mode. 
That is a good idea.

But what if users forget to enable data-saving mode when they start to use mobile data? Or users may even not notice they are using mobile data. 

>In unlimited mode, it's operation would be unchanged, that is
>...
>- when there is no choice of different apps, the downloads starts immediately
What if it's an unexpected download? 
For example, the downloading starts right after I opened a website without knowing what this website is about, and maybe I don't want the apk at all. 
Or I just want to preview some pictures, but it starts to download an apk directly right after tapping on the pictures.
No matter what I'm using, wifi or mobile data, the unexpected downloading can be really annoying.

Also I think we need to provide a button/icon for users to open the download manager easily when the downloading begins, just like UC browser(pls refer to the attachment UC-download-mgr-icon). Because many users do NOT know where to find the file just downloaded.

Comment 5

[Jan Henning [:JanH]]

(In reply to Bingqing Li from comment #4)
> But what if users forget to enable data-saving mode when they start to use
> mobile data? Or users may even not notice they are using mobile data.

That's why I suggested to
a) try fixing any outstanding issues that our network type detection might still have [1], and
b)
> The data-saving mode could then be configured from the settings to be used
> [...]
> - On metered connections only (i.e. mobile data and metered wifi connections
> as defined by the OS) - could be our default setting?

> Also I think we need to provide a button/icon for users to open the download
> manager easily when the downloading begins, just like UC browser(pls refer
> to the attachment UC-download-mgr-icon). Because many users do NOT know
> where to find the file just downloaded.

We show a notification for each running download (or at least we would if bug 1358598 was fixed).

[1] When we attempted to turn on offline browsing on Release, we got a number of reports that Firefox would believe the device to be offline (and therefore show cached pages) even though the device was in fact connected to the internet (bug 1373756).

Comment 6

[Bogdan Surd, QA [:bsurd, NI]]

Changing component to Download Manager, if anyone feels like this is not the right component please feel free to change it back.

Comment 8

[Jan Henning [:JanH]]

Bug 438905 covers what we'd need from the platform side, although it seems that adapting our download handling accordingly might be a little tricky.

Comment 9

[4a-support]

Has there been any consideration to integrating this with Android's data saver mode? i.e.

if (connectivityManager.getRestrictBackgroundStatus() == RESTRICT_BACKGROUND_STATUS_DISABLED) {
   // data saver disabled
   showDialogOnlyIfNeccessary();
} else {
   pauseOrThrottleDownload();
   forceShowDialog();
}

Data saver has a dedicated quick settings tile for easy toggling and status bar icon so its state is always obvious. The user shouldn't have to repeat themselves by configuring a Firefox-specific setting.

Comment 11

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.