862992 - Doing an system update with a low battery bricked my phone

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[David Bialer [:dbialer]]

I updated my Unagi phone without noticing a low battery.  Somewhere along the line, it was corrupted and had to reflash my phone as phone would not boot.  Should possibly warn me or prevent me from doing a system update unless I have at least x% of battery left.

I am assuming the low battery was the cause.

Comment 1

[Jason Smith [:jsmith]]

This sounds really bad. OTA Updates have to be solid, and especially not cause ourselves to get bricked in the process.

tef? for blocking consideration.

Marshall - Any ideas?

Comment 2

[David Bialer [:dbialer]]

I went from an older release, though I don't know which one to 4/12 version.  Unfortunately I don't have more info as it wouldn't boot with a new battery.

Comment 3

[Jason Smith [:jsmith]]

Hmm...okay. Let's get someone to repro this in house to see if reproduces. If we get it to reproduce, then let's renom.

Comment 4

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

We should probably have UX around low battery and updating.  Pretty sure Android and iPhone does this.

Comment 5

[Marshall Culpepper [:marshall_law]]

We originally had some UX plans for warning about low battery before trying to apply an OTA / FOTA update, but I can't seem to find any code dealing with it in Gaia. Tagging Etienne as he might know more

Comment 6

[Etienne Segonzac (:etienne)]

(In reply to Marshall Culpepper [:marshall_law] from comment #5)
> We originally had some UX plans for warning about low battery before trying
> to apply an OTA / FOTA update, but I can't seem to find any code dealing
> with it in Gaia. Tagging Etienne as he might know more

Never got to it.

It should be pretty easy to add a warning on the download prompt (with the same design than the cellular data warning).

But I don't think gaia gets a chance to delay the installation of the update, once it's downloaded it's uncompressed and installed right away AFAIK.

Comment 7

[Marshall Culpepper [:marshall_law]]

(In reply to Etienne Segonzac (:etienne) from comment #6)
> But I don't think gaia gets a chance to delay the installation of the
> update, once it's downloaded it's uncompressed and installed right away
> AFAIK.

Yeah, so IMO there are basically 4 things that we should be doing:
1. Battery is low before the download is started -- we can just add wording to our existing cell data prompt for this (?) or create a new prompt like you mentioned.

2. The download is started, but the battery dies mid-download. In this case, the update should still be in the 'downloading' state, and not applied on next boot. When the user tries to download the update again, it *should* resume from where it left off. If the sha256 of the MAR doesn't match what was in the update.xml because of data corruption, then the download will need to be started all over again (this isn't ideal, but it should avoid trying to install a corrupt download due to battery loss.

3. The download finishes, and staging is automatically started. We need to actually stop the extraction process if the battery is low and the device is not plugged in. We could either warn about the low battery and let them continue, or refuse to continue at all until they plug in the device. If the battery is high enough (or the device is plugged in?), we should return an immediate return to have gecko continue the staging process.

4. The user gets the "Restart Now/Later" prompt to restart the process (or OS) with a low battery. We should use the same battery UX / logic here as we did in #3

Thoughts?

Comment 8

[Mounir Lamouri (:mounir)]

IIRC, Android will not allow you to proceed with the system updates unless you follow some conditions regarding the battery. It would be probably a good idea to have a similar system.

Comment 9

[Etienne Segonzac (:etienne)]

Hey :stas, this is probably going require some new l10n-keys, how feasible is it?

Comment 10

[Jason Smith [:jsmith]]

Given the current discussions, sounds like the issue is confirmed in theory. I'll pull qawanted unless you want more QA investigation here.

Comment 11

[Marshall Culpepper [:marshall_law]]

Etienne and I have a plan for how to solve this.. Hoping I can get the platform patch up for review tomorrow.

Comment 12

[Stephany Wilkes]

Marshall and Etienne, UX is also looking at this, as it looks like 3 of the 4 issues you outlined in comment 7 require UX. Can you let us know what your plan involves in more detail, so that UX can be in sync with it? We can all hop on Vidyo or something. Thanks!

Comment 13

[Marshall Culpepper [:marshall_law]]

(In reply to Stephany Wilkes from comment #12)
> Marshall and Etienne, UX is also looking at this, as it looks like 3 of the
> 4 issues you outlined in comment 7 require UX. Can you let us know what your
> plan involves in more detail, so that UX can be in sync with it? We can all
> hop on Vidyo or something. Thanks!

That sounds fine to me. I'm in Madrid today, what time works for you?

Comment 14

[Alex Keybl [:akeybl]]

(In reply to Stephany Wilkes from comment #12)
> Marshall and Etienne, UX is also looking at this, as it looks like 3 of the
> 4 issues you outlined in comment 7 require UX. Can you let us know what your
> plan involves in more detail, so that UX can be in sync with it? We can all
> hop on Vidyo or something. Thanks!

Please make sure that no new strings are added (we can't localize new strings at this point). Graying out the update button, preventing the update from starting, etc would be the right way to go.

Comment 15

[Etienne Segonzac (:etienne)]

(In reply to Alex Keybl [:akeybl] from comment #14)
> Please make sure that no new strings are added (we can't localize new
> strings at this point). Graying out the update button, preventing the update
> from starting, etc would be the right way to go.

We have no prompt currently between the download and the actual extraction/installation (the risky steps).

No way to fix this bug without a new prompt after the download and before the extraction when the battery is low.

I really don't think disabling the _download_ button when we're low on battery is an acceptable solution: the download itself isn't risky, and without new strings we can't even explain why the button is disabled.

Comment 16

[Alex Keybl [:akeybl]]

(In reply to Etienne Segonzac (:etienne) from comment #15)
> (In reply to Alex Keybl [:akeybl] from comment #14)
> > Please make sure that no new strings are added (we can't localize new
> > strings at this point). Graying out the update button, preventing the update
> > from starting, etc would be the right way to go.
> 
> We have no prompt currently between the download and the actual
> extraction/installation (the risky steps).

I'm suggesting we delay the extraction until the user has an appropriate battery level - no prompting.

Think about how long it took for us to run into this bug - the number of users that will run into this will be very small. We just need a fix that prevents bricking.

> No way to fix this bug without a new prompt after the download and before
> the extraction when the battery is low.
> 
> I really don't think disabling the _download_ button when we're low on
> battery is an acceptable solution: the download itself isn't risky, and
> without new strings we can't even explain why the button is disabled.

I'll let UX decide what is acceptable without new UX/strings.

Comment 17

[Rob MacDonald [:robmac]]

Hi everyone...

Just looking at this on behalf of UX. I'm trying to replicate the update flow on my device but the download keeps failing. As a result, I'd appreciate if one of you could describe the flow as implemented to give me better context.

The suggestion of disabling the download button doesn't provide the user with the context they need to understand how to resolve the issue. So I recommend against this.

For the option of delaying the extraction/installation, at what point would the extraction and installation take place? More importantly, would the user be notified / prompted before the actual extraction and installation starts? And, finally, what would show in the utility tray?

And, one more question, is it possible to use another existing string to explain the issue? Could something like "Battery low" (assuming this or a similar string exists) be used in this flow?

More questions than answers, I know, but hopefully we can get this one resolved soon.

Rob

Comment 18

[Rob MacDonald [:robmac]]

Alex, are you able to elaborate on my questions in comment 17?

Comment 19

[Hema Koka [:hema]]

Can we please get Rob's questions answered and come up with an acceptable solution and move forward? 

Thanks
Hema

Comment 20

[Dave Hylands [:dhylands]]

It isn't clear to me how having a low battery can cause a brick when using OTA.

I can definitely see it for FOTA (which is what Android uses and is why it's so important under android not to run out of battery while updating). FOTA doesn't keep backups of anything so if it fails part way through, then you're hooped.

Our OTA keeps a fallback around.

Some low-battery behaviour I have notice (on my unagi):
 - If the battery is really low, then the red led flashes, and the phone won't boot.
 - Even when the red led stops flashing, there may not be enough battery to get the phone to boot. I've watched it start to boot, and then fall back to the bootloader.

So - we should probably get the bootloader to require a higher battery level before allowing the phone to try to boot.

It would be extremely useful to get access to a phone which is in the "bricked" state to see why its not booting.

Comment 21

[Andrew Overholt [:overholt]]

Do you think you can reproduce this, David?

Also, ni?(marshall) for comment #17.

Comment 22

[David Bialer [:dbialer]]

I don't think I can reproduce it as IT reflashed it for me after they tried to start it.  Sorry.

Comment 23

[Andrew Overholt [:overholt]]

QA, can you please try to reproduce?  Simulating the low battery by ripping it out at various stages of the update may work.  Thanks!

Comment 24

[Chris Lee [:clee]]

> Think about how long it took for us to run into this bug - the number of
> users that will run into this will be very small. We just need a fix that
> prevents bricking.

I disagree here.  The number of users who could run into this situation is not trivial.  Most of our dogfooders are not using their phones 100% of the time so our behavior today will not be reflective of reality when it hits a consumer's hands.  

I would tweak the path forward Etienne/Marshall have proposed:

*We should not even start the download if the battery is below X% (on other platforms I believe that is 50% battery or it needs to be plugged in if it's <50% battery life)
*This would essentially eliminate all the other dialogs or flows given no update would start without meeting this criteria

Any concerns with this approach?

We will need late l10n here and *must* have a rock solid update path forward.

Comment 25

[Dave Hylands [:dhylands]]

I don't think that the battery level at the start of the download is relevant to anything.

Especially given that it can take hours or even days to complete the download if you have spotty wifi.

If we're going to be checking the battery levels, it should be after the download is complete and we're about to apply the update. Applying the update only takes at most a few minutes, and that's the most risky portion of the whole update.

Comment 26

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Dave, the UX that I had requested for was similar to that of any android device. "Please be sure to have your device plugged in while trying to update your device" or something to that effect.

I believe iPhone also does the same thing.

We want the user charging their device while the update is happening to avoid the update borking the phone.

Comment 27

[Stephany Wilkes]

This is my attempt to finalize UX and summarize an approach based on the comments here:

* As Chris stated, it sounds like we will need late 110n here, which indicates that we should be able to add new strings. The ability to add strings means that we can use the original UX for this issue, which is shown on page 13 of this spec (ignore the rest of the pages; many of those are out of date):
https://www.dropbox.com/s/4drvlwzjz0jyblq/Gaia_Updates_20120826.pdf

* We are fine with Dave's proposal (seems totally reasonable) and defer to eng on *when* the alert is surfaced. The design on page 13 is the one that we'd like to use regardless of when exactly the alert is shown.

Comment 28

[Dave Hylands [:dhylands]]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #26)
> Dave, the UX that I had requested for was similar to that of any android
> device. "Please be sure to have your device plugged in while trying to
> update your device" or something to that effect.
> 
> I believe iPhone also does the same thing.
> 
> We want the user charging their device while the update is happening to
> avoid the update borking the phone.

That's all well and good, but what's the point if the battery is fully charged when they start the download and below the threshold when the update is applied (which is where it matters).

It doesn't matter to me if we check in both places, but if you only check before the download, then you aren't actually doing anything useful.

Comment 29

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Thanks, Dave.  Fair point, I was hoping to have the UI when you clicked on the install button and you weren't plugged in, not during the download process of the update.  

It shouldn't matter about downloading the update itself... once it passes the verification of the hash code after uncompressing, we should check the power when they are about to do the update.  That's similar to what android does.  They don't care about the download process.  It's the actual install process that they care about.

If we have enough power to complete the update, then it shouldn't take too long to update as long as they aren't draining the battery somehow really fast.  I wonder if we can measure power consumption rate on the devices by itself yet?  Alon had done that for Fennec during the Fennec 4 days.

Do you think we should check during the update process as well?  If so, what do we do during the time that they try and it hits the threshold?

Comment 30

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I should not have said "they don't care...", they do... they do not throw up the ui for the download phase for the power other than the regular power check.

Comment 31

[Dave Hylands [:dhylands]]

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #29)
> Thanks, Dave.  Fair point, I was hoping to have the UI when you clicked on
> the install button and you weren't plugged in, not during the download
> process of the update.  
> 
> It shouldn't matter about downloading the update itself... once it passes
> the verification of the hash code after uncompressing, we should check the
> power when they are about to do the update.  That's similar to what android
> does.  They don't care about the download process.  It's the actual install
> process that they care about.

Exactly.

> If we have enough power to complete the update, then it shouldn't take too
> long to update as long as they aren't draining the battery somehow really
> fast.  I wonder if we can measure power consumption rate on the devices by
> itself yet?  Alon had done that for Fennec during the Fennec 4 days.

Once the download has completed, it gets "staged", which can take a few minutes (depends on how complicated the update is). After this, the user is presented with the Install/Later dialog. If they choose to install, then b2g restarts itself and then the new files are switched in for the old files (a directory rename).

So the staging portion is where most of the flash activity takes place (so after the download and before the install/later prompt). This staging is where we should check the battery levels, and presumably at the "Install Now" time.

> Do you think we should check during the update process as well?  If so, what
> do we do during the time that they try and it hits the threshold?

I don't think we really need to check while the update is being staged. If we checked before staging, then we should be good. The only thing that can prevent the staging is pulling the battery.

Comment 32

[Marshall Culpepper [:marshall_law]]

(In reply to Rob MacDonald [:robmac] from comment #17)
> Hi everyone...
> 
> The suggestion of disabling the download button doesn't provide the user
> with the context they need to understand how to resolve the issue. So I
> recommend against this.

Agreed -- I think we should only really be checking before extraction ("staging") occurs (see Dave's previous comments), and before we restart to apply the update.

> 
> For the option of delaying the extraction/installation, at what point would
> the extraction and installation take place? 

Once the device's charger is plugged in

> More importantly, would the user
> be notified / prompted before the actual extraction and installation starts?

I'm not against showing the appropriate dialog again once the device is charging

> And, finally, what would show in the utility tray?

A message along the lines of "The system update cannot continue until you plug in your device.."

> 
> And, one more question, is it possible to use another existing string to
> explain the issue? Could something like "Battery low" (assuming this or a
> similar string exists) be used in this flow?

Maybe for a title, but the detailed messaging would more than likely require new string(s).

I have a WIP patch for this that I hope to have up for review sometime tomorrow :)

Comment 33

[Jason Smith [:jsmith]]

Pulling qawanted since I don't think it's worth investigating resources doing STR analysis if developers & UX have already confirmed this issue could happen and that we have a solution being thought about in the pipeline.

It's probably something that I'd expect that would have to be timed correctly to brick the device, anyways.

Let's just move forward with the defensive mechanism being discussed above.

Comment 34

[Stephany Wilkes]

Is the only outstanding UX item a proposed string? Trying to finish up our end of this ASAP. Thanks, all!

Comment 35

[Marshall Culpepper [:marshall_law]]

Attachment: gecko patch - v1

This seems to work when I set the pref to 100 for testing, but since the UI isn't
complete just marking for feedback. Both staging and applying will wait for the
charger to be plugged in if the battery is lower than b2g.update.min-battery-level.

Comment 36

[Dave Hylands [:dhylands]]

Comment on attachment 743870 [details] [diff] [review]
gecko patch - v1

Review of attachment 743870 [details] [diff] [review]:
-----------------------------------------------------------------

Looks reasonable to me.

Comment 37

[Marshall Culpepper [:marshall_law]]

(In reply to Stephany Wilkes from comment #34)
> Is the only outstanding UX item a proposed string? Trying to finish up our
> end of this ASAP. Thanks, all!

I think so -- just a string that describes the need to plug-in the device when the battery is too low. Etienne, do you think we'll need any others?

Comment 38

[Marshall Culpepper [:marshall_law]]

Attachment: WIP gaia changes - v1

This isn't final because of the need for new string(s).

Comment 39

[Mounir Lamouri (:mounir)]

Marshall, why is the change on the backend side instead of on the UI one? If I understand correctly, what will happen with that change is that you will do the full update process and at some point, everything will stop with an error message telling you that you need to plug, right?

It is a known UX issue regarding installation process (I will consider update as similar) that when you press "Install", the user actually expects that every checks have been done and things are good to go. If I start an update before going to lunch, I expect my update to be done when I'm back. If I get an error message in the middle of the process regarding battery level, as a user, I will not be very happy because the system had a way to tell that the phone wasn't plugged. However, I agree that at some point, the backend should do a sanity check but the full user experience shouldn't rely on that.

What about this:
- when the installation is started, if the phone isn't plugged [or doesn't have X% battery left], the UI should ask the user to plug the phone and may propose to still do the download;
- if the phone is plugged [or has at least X% battery left], the UI will allow the user to start the update process;
- an intermediate check might be done between download and actual update to make sure the battery didn't die in between;
- before starting the critical part, the backend will check the battery level and fire an error if it is not at least Y%. With X > Y.

In my opinion, that will lead to a better UI (informed before the error happens, not after) and will also allow the UI to change over time given that the UI doesn't rely on the platform behaviour.

How does that sound?

Comment 40

[Stephany Wilkes]

UX provided our recommendation in comment 27, which we would like to go with.

In reply to Marshall's comment: "I think so -- just a string that describes the need to plug-in the device when the battery is too low."

Here is a proposed string: "System update can not be installed while battery is low. Please plug the phone in to complete the system update."

If there is an existing "low battery" title and/or visualization we use in other areas (which I couldn't find in the Mercurial repo at https://hg.mozilla.org/gaia-l10n/en-US/ but may have missed), please feel free to add this string to that.  

I followed our copy guidelines and strings as best I could but please make edits as y'all more knowledgeable folks see fit.

Etienne, if there are any other strings please let me know and I'll work to clear the tef+ on this ASAP.

Comment 41

[Mounir Lamouri (:mounir)]

(In reply to Stephany Wilkes from comment #40)
> UX provided our recommendation in comment 27, which we would like to go with.

I'm not sure how the two screenshots and my proposal are conflicting. Could you elaborate?

Comment 42

[Stephany Wilkes]

Didn't mean to imply a conflict. Just restating so we can finish UX on our end (which at this point consists of a string) and get the tef+ cleared.

Comment 43

[Mounir Lamouri (:mounir)]

(In reply to Stephany Wilkes from comment #42)
> Didn't mean to imply a conflict. Just restating so we can finish UX on our
> end (which at this point consists of a string) and get the tef+ cleared.

There is no context around those two screenshots. Should they appear at the beginning of the process, the middle, the end?

Comment 44

[Stephany Wilkes]

I'm confused. Rob (from my team, UX) has posted a 13-page spec (referenced above) and comments throughout this thread. What are the "two screenshots" exactly? I'm not sure which you mean.

Marshall and Etienne, please let me know if the submitted string suffices. Thanks!

Comment 45

[Alex Keybl [:akeybl]]

It's not clear to me if we're able to go with an existing string or not, so I'm not adding late-l10n yet (although the WIP patch does have a new string). Please add that keyword yourself if a new string ends up being unavoidable.

Comment 46

[Alex Keybl [:akeybl]]

(In reply to Jason Smith [:jsmith] from comment #33)
> Pulling qawanted since I don't think it's worth investigating resources
> doing STR analysis if developers & UX have already confirmed this issue
> could happen and that we have a solution being thought about in the pipeline.

Not true - if nobody has been able to reproduce this situation, we may be able to deprioritize this completely.

Comment 47

[Alex Keybl [:akeybl]]

Plus, how can we verify if we haven't reproduced?

Comment 48

[Jason Smith [:jsmith]]

(In reply to Alex Keybl [:akeybl] from comment #46)
> (In reply to Jason Smith [:jsmith] from comment #33)
> > Pulling qawanted since I don't think it's worth investigating resources
> > doing STR analysis if developers & UX have already confirmed this issue
> > could happen and that we have a solution being thought about in the pipeline.
> 
> Not true - if nobody has been able to reproduce this situation, we may be
> able to deprioritize this completely.

The reporter already confirmed they could reproduce and there's a solution in the pipeline. I think this is wasteful to put QA resources on this at this point.

(In reply to Alex Keybl [:akeybl] from comment #47)
> Plus, how can we verify if we haven't reproduced?

We can figure that out after the patch has landed if need be by comparing builds before and after.

Comment 49

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #48)
> (In reply to Alex Keybl [:akeybl] from comment #46)
> > (In reply to Jason Smith [:jsmith] from comment #33)
> > > Pulling qawanted since I don't think it's worth investigating resources
> > > doing STR analysis if developers & UX have already confirmed this issue
> > > could happen and that we have a solution being thought about in the pipeline.
> > 
> > Not true - if nobody has been able to reproduce this situation, we may be
> > able to deprioritize this completely.
> 
> The reporter already confirmed they could reproduce and there's a solution
> in the pipeline. I think this is wasteful to put QA resources on this at
> this point.

And by reproduce, I mean they reproduced it during the initial filing of the bug.

Comment 50

[Jason Smith [:jsmith]]

Per talking with akeybl, QA will agree to see what we can find doing some exploratory testing around loss of battery during OTA updates to see what happens.

Comment 51

[Jason Smith [:jsmith]]

Couldn't reproduce on today's 5/1 build with tests that tried:

- Pulling the battery during download a few times
- Pulling the battery during uncompressing a few times
- Pulling the battery post the install update UI

Comment 52

[Jason Smith [:jsmith]]

Keep in mind that I agree with clee's comment above about the fact that I don't think reproducibility should affect whether this blocks or not. A bug like this even in the 0.01% case of being reproduced is extremely bad. If defensive mechanisms can be put in place to better protect a low battery device bricking, then that can be a worthwhile investment.

The patch being worked on here by marshall from what I'm seeing ensures that we only try to apply an update when the battery is 50% or greater. That would optimally prevent the problem that happens with a low battery case even if happens at a low percentage of occurrence.

Comment 53

[Etienne Segonzac (:etienne)]

Comment on attachment 743896 [details] [diff] [review]
WIP gaia changes - v1

Review of attachment 743896 [details] [diff] [review]:
-----------------------------------------------------------------

The SystemBanner will only be shown for a short instant (very easy to miss).
If we go with this instead of a prompt (which I'm in favor of), we probably need to update the "pined notification" (in the utility tray) too to make sure that the user can see that he/she needs to plug the phone

Comment 54

[Alex Keybl [:akeybl]]

(In reply to Jason Smith [:jsmith] from comment #52)
> Keep in mind that I agree with clee's comment above about the fact that I
> don't think reproducibility should affect whether this blocks or not.

All depends on the calculus of when this will land, with what string changes, and with what risk. We won't slip our dates if we're unable to reproduce and we've only had one instance in months of testing.

If this can land before 5/10, great we'll take the fix. After that this will be a harder sell.

Comment 55

[Marshall Culpepper [:marshall_law]]

(In reply to Etienne Segonzac (:etienne) from comment #53)
> Comment on attachment 743896 [details] [diff] [review]
> WIP gaia changes - v1
> 
> Review of attachment 743896 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> The SystemBanner will only be shown for a short instant (very easy to miss).
> If we go with this instead of a prompt (which I'm in favor of), we probably
> need to update the "pined notification" (in the utility tray) too to make
> sure that the user can see that he/she needs to plug the phone

Agreed -- I coded this up quickly to test my changes, but was hoping someone could take over on the UI changes at this point :)

If not, I can dig in and do the UI if necessary -- just let me know.

Comment 56

[Marshall Culpepper [:marshall_law]]

(In reply to Mounir Lamouri (:mounir) from comment #39)
> Marshall, why is the change on the backend side instead of on the UI one? If
> I understand correctly, what will happen with that change is that you will
> do the full update process and at some point, everything will stop with an
> error message telling you that you need to plug, right?
> 
> It is a known UX issue regarding installation process (I will consider
> update as similar) that when you press "Install", the user actually expects
> that every checks have been done and things are good to go. If I start an
> update before going to lunch, I expect my update to be done when I'm back.
> If I get an error message in the middle of the process regarding battery
> level, as a user, I will not be very happy because the system had a way to
> tell that the phone wasn't plugged. 

I'm fine with checking (and warning) about battery level before the download begins, but it's impossible to predict what the battery state will be like after the download finishes.  With less connectivity and lower download speeds, the separation between download and staging / applying (the risky parts) could easily be several hours, or days. I'm not sure how we avoid giving the user _some_ sort of indication that the battery is too low to continue without showing them? Just stopping the process without any feedback seems like it would be even more confusing.

Comment 57

[Etienne Segonzac (:etienne)]

(In reply to Marshall Culpepper [:marshall_law] from comment #55)
> (In reply to Etienne Segonzac (:etienne) from comment #53)
> > Comment on attachment 743896 [details] [diff] [review]
> > WIP gaia changes - v1
> > 
> > Review of attachment 743896 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > The SystemBanner will only be shown for a short instant (very easy to miss).
> > If we go with this instead of a prompt (which I'm in favor of), we probably
> > need to update the "pined notification" (in the utility tray) too to make
> > sure that the user can see that he/she needs to plug the phone
> 
> Agreed -- I coded this up quickly to test my changes, but was hoping someone
> could take over on the UI changes at this point :)
> 
> If not, I can dig in and do the UI if necessary -- just let me know.

I can help :)

So what's the final UX?
(It's not the PDF linked before since it references part of the settings app that were never built).

So, just a prompt before stating?

Comment 58

[Alex Keybl [:akeybl]]

No reproductions, high risk change, remaining UX, not a blocker.

Comment 59

[Stephany Wilkes]

It looks like the UX spec that Rob provided cannot or will not be used, and so a prompt is proposed instead. Is the remaining UX, then, for us to validate that idea and/or provide a string?

Comment 60

[Stephany Wilkes]

Alex, can you (or someone else) please describe the remaining UX needed here, per my comment 59? Trying to clear all of our FFOS-UX needs. Thanks!

Comment 61

[Stephany Wilkes]

Removing UX needinfo since we're not hearing anything about what outstanding UX is still needed.

Comment 62

[Wayne Chang [:wchang]]

I'd like to nom this for koi?, it's probably better to have this protection mechanism.

Comment 63

[bhavana bajaj [:bajaj]]

needinfo :dhylands on what the next steps here for 1.2 ?

Comment 64

[Dave Hylands [:dhylands]]

(In reply to bhavana bajaj [:bajaj] from comment #63)
> needinfo :dhylands on what the next steps here for 1.2 ?

It looks like the UX was done, but rejected due to being too late for string changes previously.

Marshall has already coded up the backend, and it needs the gaia work to be done.

Comment 65

[bhavana bajaj [:bajaj]]

(In reply to Dave Hylands [:dhylands] (on PTO back Oct 15) from comment #64)
> (In reply to bhavana bajaj [:bajaj] from comment #63)
> > needinfo :dhylands on what the next steps here for 1.2 ?
> 
> It looks like the UX was done, but rejected due to being too late for string
> changes previously.
> 
> Marshall has already coded up the backend, and it needs the gaia work to be
> done.
Sounds too late for 1.2 at this point, I am going to move this to 1.3 and set the assignee as you. Feel free re-assign if someone else is going to be work on it.

Comment 66

[Jason Smith [:jsmith]]

This isn't happening anytime soon for any target release, so I'm clearing the nom.

Comment 67

[:gerard-majax]

Didn't we fixed this in bug 959195 ?