Open Bug 1520297 Opened 4 years ago Updated 18 days ago

Preload Intermediates on Android

Categories

(Core :: Security: PSM, defect, P3)

All
Android
defect

Tracking

()

Webcompat Priority P1
Tracking Status
firefox66 --- affected

People

(Reporter: jcj, Unassigned)

References

(Blocks 4 open bugs)

Details

(Whiteboard: [crlite] [psm-backlog])

The intermediate preloading tests fail on Android, likely due to tighter constraints.

See log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=222040989&repo=autoland&lineNumber=2017

On Android we're going to want to be careful when fetching our intermediates, too. We should prefer to do so while in a strong network and connected to power before turning this feature on.

Blocks: 1404934
No longer blocks: 1520278
Summary: Fix intermediate preloading on Android → Preload Intermediates on Android

(In reply to J.C. Jones [:jcj] (he/him) from comment #1)

We should prefer to do so while in a strong network

The dev-platform post suggested that "strong network" means wifi. Could you, please, (since the Android system seems to lack one) add a pref that allows the user to affirm that their mobile connection is a proper Internet connection? The assumption of "wifi good, mobile bad" is problematic in countries where mobile is not only fast and unmetered but is the only practical option for some residential areas. In such places, devices might never naturally connect to wifi except as a specific manual chore to work around U.S.-centric limits on software updates. (It's bad to have to take devices out of the house to some other place that has wifi to work around limitations that updates work on wifi only or to have to set up mobile devices as wifi hotspots for other mobile devices and be sure to mix operating systems enough that the other device believes it's on stationary wifi and not on tethering wifi in order to download updates.)

Would a pref such as security.remote_settings.intermediates.download_via_mobile_network that defaulted false work for your use case, Henri?

(In reply to J.C. Jones [:jcj] (he/him) from comment #3)

Would a pref such as security.remote_settings.intermediates.download_via_mobile_network that defaulted false work for your use case, Henri?

With UI exposure in the prefs, yes, but it should probably be more generic so that potential other future background download logic could use the same pref to decide whether to wait for wifi and plugged in or just go ahead if plugged in.

Mathieu -

Given comment 3 and comment 4, what would you prefer the key name of such a preference to be?

Flags: needinfo?(mathieu)

If it applies to Remote Settings, I would suggest it to have services.settings. as a prefix like the existing ones: https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/modules/libpref/init/all.js#2749-2754
And since intermediates are records attachments, services.settings.attachments.download_via_mobile_network could work!

If it's even more generic than that within the browser (assets, updates, ...), then I'd rather let you choose ;) It seems some of them start with browser.download.

Flags: needinfo?(mathieu)
No longer blocks: 1672402
Duplicate of this bug: 1672402

This is currently breaking https://www.apple.com/ca/shop
which is quite a major website.

Webcompat Priority: --- → P1

Let's try to contact them (Apple).

(Apple has fixed its cdn for images and it is now working.)

No longer blocks: 1606696

The severity field for this bug is set to normal. However, this bug has a P1 WebCompat priority.
:keeler, could you consider increasing the severity of this web compatibility bug?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dkeeler)
Severity: normal → S2
Flags: needinfo?(dkeeler)
Depends on: 1772232
You need to log in before you can comment on or make changes to this bug.