STR: 1. Device is with battery < 50% full 2. Plug-in the device to charge 3. Try to OTA Expect: Can do OTA because when it's plugged-in, the power should never got out Actual: The OTA got blocked I think this is annoying because user has no chance to OTA even with a plugged-in device, and the user must wait to charge to > 50% with no reason. Since I don't know whether this is an UX decision, but it seems related to user flow, so I NI UX to take a look. ---- Device Flame: Gecko: 33.0a1 20140704040205 Gaia: b597b862

This is not a UX issue. OTA updates should work. This sounds like an engineering bug. Please flag the engineering lead for this area.

NI Tim because OTA seems not owned by one peer, and I don't know who should handle this.

The actually code is located in apps/system/js/updatable.js:SystemUpdatable.prototype.showApplyPrompt $ g count -- apps/system/js/updatable.js 9 Etienne Segonzac 5 Julien Wajsberg 3 Marshall Culpepper 3 Alive Kuo 1 Francesco Lodolo (:flod) 1 KWierso 1 Margaret Leibovic 1 Michal Budzynski 1 Pavel Ivanov 1 Alexandre Lissy 1 crh0716 1 Alexandre Poirot 1 Anthony Ricaud 1 Fabien Cazenave

Yeah, FWIW I agree with Greg, and I asked the same question when this change was introduced, here's the answer: https://bugzilla.mozilla.org/show_bug.cgi?id=959195#c2 It's definitely a UX decision, the code change to make it work like described in the description is trivial.

According to Etienne, this is an UX issue and I've seen Jenny's opinion: > We can't know for sure if the device will still be plugged in after the installation starts, so, just to be safe, let's keep the current behavior. Tks! So NI Jenny. I think the major problem is to charge to 50% sometimes would take a long while, and you can do nothing even though you exactly know while the updating is on going, the power can be supplied continuously. I've experienced that I can't continue to charge my phone because I need to move around and to un-plug it several times. In such case, although the battery is very close to 50%, you still can do nothing. I recollect that I've found there is an update available at morning, and since I've no change to charge it to 50%, although the most close result is > 45% and I've some long enough updating windows to plug it, I can only do OTA until night (while it got charged to over 50% finally). I know to prevent user to brick their phone is an important issue. However, as a user who exactly know what he is doing, and the risk is so small (~50% and I'm pretty sure it would not out of power suddenly), I feel it's very annoying to be forced to wait just because the system worry about the bricking issue too much, which is like a nervous mother worry her children as well. If you still think to cancel this restriction is too risky, we may provide a option in Developer menu to let developer do that at their own risk.

Let's reduce the block to below 10% or 20% maybe?

That sounds way too low. I would keep the 50%, even if it's annoying for users that know what they do (or are ok with risking to brick their phone). Another option would be to add a button in the warning dialog saying something like "I know what I'm doing!" to bypass the limit when battery level is between 25% and 50%.

Hi all, per discussion with Greg, I've reduced the threshold to 25%. Charging or not, if battery level is <25%, install cannot be started. Please refer to the attached spec. Tks!

And we've discussed that developers should be allowed to cancel the check while it is plugged in, via a option in the Developer menu. This should be fixed, too.

INMHO, this bug is closely related with bug 1039480. Instead of wire the threshold I'm adding them to settings as under app.update.battery-threshold.unplugged and app.update.battery-threshold.plugged keys with values 9 and 25 per commentaries in the bugs. However, notice these actual descriptions make no much sense as we are preventing the user to install the update when the device is running under 25% while charging and 9% (a lower value) when not charging. We should review the case.

Patch is work in progress but it completely functional. Etienne, could you please review my patch and provide me feedback? Thank you!

Comment on attachment 8459674 [details] [WIP] Adding settings to set the battery thresholds to prevent system updates in case of low battery Nice patch! I'd like to add default values in case the settings is empty (you never now with upgrades...) so we don't consider the threshold to be 0, and add a test for this. And we need UX to confirm the 9% / 25% thresholds.

Bruce, Jenny, as we talked via e-mail , this battery threshold should be configured in build time, but as Etienne explains in comment 12 we should have a default value. Could you help us with it? so Salva can provide a final patch. Thanks a lot!

Hello, charging or not, if battery level is <25%, install cannot be started. Tks!

Comment on attachment 8459674 [details] [WIP] Adding settings to set the battery thresholds to prevent system updates in case of low battery Hello Etienne, I've prepared a version 2 of the patch with the info received from UX about default thresholds. As you suggested me, in case of mozSettings fail to recover the settings or these are undefined, the default is applied. You can specify a threshold of 0 but you must do it explicitly. A value not being a number or undefined falls back into the default value. I've modified a l10n string cause now the prompt indicating the minimum battery needed should be dynamically localized. Please Etienne, do you mind to review my patch?

Acceptance criteria updated according to Bruce and Jenny feedback

Comment on attachment 8459674 [details] [WIP] Adding settings to set the battery thresholds to prevent system updates in case of low battery thanks!

master: dd8d9ad3e6ad7a0ed778353a745eda4cae44fcb4

Please back-out and land with a new string ID :-\ https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localization_best_practices#Changing_existing_strings

Sorry, my fault. Backoute: 5424d713e8cf3b469d70e2f76dcb484a9a0ec0e2

Same patch with the l10n key changed.

Comment on attachment 8463271 [details] Adding settings to set the battery thresholds to prevent system updates in case of low battery I don't think I should review patches with code (switching to f), but string/l10n look definitely good now (added a possible l10n comment for the string, mostly for the % following the variable name).

Comment on attachment 8463271 [details] Adding settings to set the battery thresholds to prevent system updates in case of low battery This new patch should carrying the original r+ if the only change is just the string id.

Comment on attachment 8463271 [details] Adding settings to set the battery thresholds to prevent system updates in case of low battery Indeed, the only change was the id. Restoring the r+ flag. Waiting for Travis to finish before merging.

Now it's ok. Master: 6356148a55e2e48309a04ace49f403fd11591b63

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1048772

(In reply to Loli (:lolimartinezcr) PTO 18th-24th Aug from comment #27) > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1048772 This bug is verified for this reason it is verified also.