User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 Build ID: 20140716183446 Steps to reproduce: SW version Boot2Gecko 2.1.0.0-prerelease Buildidentifier 20140831160203 I tried to update my phone Please see attached screen-dump Actual results: After I pressed the button confirming that I wanted to apply the SW update the confirmation dialogue disappeared and the underlying window was shown. The screen was not responding to any touch event After a while the screen went black and the phone was successfully updated Expected results: After the user confirms to update the SW, a message shall be shown that informs the user that the SW has started and asks the user to wait. This is important for users. System updates are scary and uncommon. A confirmation that all is well is needed.

Definitely doesn't sound like desired behaviour for such a critical use case. Flagging QA to verify the behaviour and whether this is a regression and Jacqueline to update any ux flows if required.

Gregor, does this live in the System app? Is it covered by SysFE or Tim's team?

(In reply to Peter Dolanjski [:pdol] from comment #2) > Gregor, does this live in the System app? Is it covered by SysFE or Tim's > team? We don't have clear ownership but we can take it. Adding Tim as well so he can follow what we want to do.

Dupe of bug 1061962 ?

I agree that this is not the ideal flow. Since we missed the string cut off date, I think it would be best to add a loading or processing screen when the update is in progress to show that the user cannot interact with the device.

We'll need visual for this. We could re-use an existing string (I'm thinking "System update" works) and have a simple loading icon above it. Note: we can't use an animation since the screen freezes during this process. Jacqueline, who is the point person for providing a visual spec here?

The "System update" suggestion sounds good to me, thanks Michael! I believe the visual designer for this would be Eric, so ni? on Eric to provide the needed screen. Eric - Feel free to reassign if someone else should be covering this.

(In reply to Michael Henretty [:mhenretty] from comment #6) > We'll need visual for this. We could re-use an existing string (I'm thinking > "System update" works) and have a simple loading icon above it. Note: we > can't use an animation since the screen freezes during this process. > > Jacqueline, who is the point person for providing a visual spec here? Hey Michael, I'm thinking we stick to the building blocks and do something like this (without the cancel button): http://buildingfirefoxos.com/building-blocks/progress-and-activity.html#progress-modal-spinner Though..if the icon doesn't move the user will most likely think the phone has crashed. Because of the string freeze I guess we can't really add anything that lets the user know they need to wait?

It would be much easier if we don't have to add any strings, but I think it's still doable if absolutely necessary. What about using that building block and having it say "System update" and putting an exclamation icon instead of the loading icon?

I'm worried that an exclamation mark might look like an error or that something went wrong... But I do agree we should use the Building blocks. I think using the text 'System Update' works as long as the icon can display that something is happening. If not, we could use a word like 'Loading' or 'Processing' to help explain that an action is taking place. Eric do you have any other suggestions for the icon and text?

Just a word of caution with regards to re-use of text strings. How is "System Update" previously used? Some languages will phrase "system update" differently dependent on context. E.g. if it is an ongoing action, an action that will happen or something that has happened.

What if we did something in the style of the FM Radio overlay (that tells you to plug in headphones)? See attached screen, if you think this can work I can get the icon ready in the right sizes. Also, if possible we can have 'System Update' on the first line and something that lets the user know they have to wait on the second. We'll also have to take into account Olaf's comment about how it's used.

(In reply to Eric Pang [:epang] from comment #12) > Created attachment 8487878 [details] > system update prompt.jpg > > What if we did something in the style of the FM Radio overlay (that tells > you to plug in headphones)? See attached screen, if you think this can work > I can get the icon ready in the right sizes. > > Also, if possible we can have 'System Update' on the first line and > something that lets the user know they have to wait on the second. We'll > also have to take into account Olaf's comment about how it's used. If we can't update the strings I can always make a smaller version of the above icon and we can replace the the spinner with it and use the building blocks http://buildingfirefoxos.com/building-blocks/progress-and-activity.html#progress-modal-spinner

(In reply to Olof Wickström from comment #11) > Just a word of caution with regards to re-use of text strings. How is > "System Update" previously used? Some languages will phrase "system update" > differently dependent on context. E.g. if it is an ongoing action, an action > that will happen or something that has happened. That's a good point. It's used as the title for system update related dialogs. If we use it similarly (ie. as a dialog title), I think we should be ok.

I think this sounds good as well, system update as the text and the above icon as the loading icon.

Updated the screen, updating the icons next :)

Here's the icon we can use in the place of the loading indicator. Let me know if anything else is needed! Thanks!

Alberto, can you help us get the visual spec in comment 16 in for this bug?

Sure

(In reply to Alberto Pastor [:albertopq] from comment #19) > Sure let me know if a more detailed spec is needed :) Thanks!

I'm not able to receive OTA updates. Is that a known issue? Can somebody help me with that otherwise?

(In reply to Alberto Pastor [:albertopq] from comment #21) > I'm not able to receive OTA updates. Is that a known issue? Can somebody > help me with that otherwise? People have been having some issues with FOTA updates on the mailing list. Do you flash pvt builds? You might try flashing a build a couple of days old, and see if the update prompt shows up. Also, here is a wiki on building/hosting FOTA updates yourself [1]. In any case, we can take this conversation offline. Let's talk tomorrow. 1.) https://wiki.mozilla.org/B2G/Updating

Hey Michael, thanks for your comments. I think my issue is related to Bug 1063237, as I'm building KK images. I'll try with JB and let's see if it helps. Thanks!

[Blocking Requested - why for this release]: After the user confirms to update the SW, a message shall be shown that informs the user that the SW has started and asks the user to wait. This is important for users. System updates are scary and uncommon. A confirmation that all is well is needed.

This is not a blocker the release as this has been working this way all along..Please note that the risk this may add to the release is significant, and I only want to consider an uplift if the solution is going stick on trunk and we can manage the risk. Systemsfe is currently going to focus on burning down blockers, and will try to accommodate this ad-hoc request given depending on the bandwidth and keeping the "partner" consideration in mind here. If we are able to fix this in a low risk way without fallouts, we'll uplift it, the timeline for this could get beyond FC date though and fully depends on the "risk" here. Gregor , feel free to add anything I've missed per offline discussion with you..I've communicated this to Jaime as well.

This is a blocker for me. See motivation from jachen in comment 24 above. Please fix for 2.1

(In reply to Olof Wickström from comment #26) > This is a blocker for me. See motivation from jachen in comment 24 above. > Please fix for 2.1 Please check comment #25 why this would not be a blocker for release. lets discuss offline about how and what our blocking process means to avoid bugzilla wars.

I cannot work on this one, as I cannot make OTA to work

It probably also make sense to flip feature-b2g so this don't fall through the cracks.

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #29) > It probably also make sense to flip feature-b2g so this don't fall through > the cracks. We will take care of it as soon as someone becomes available in our team.

Per partner discussion from Joe/Frlee, its fine to minus this for 2.1.

This issue occurs on Flame 2.2 KK, Flame 2.1 KK, and Flame 2.0 KK. Environmental Variables: Device: Flame 2.2 BuildID: 20141002093155 Gaia: 191d805f4911628d37a8a90a1e23a6013995138f Gecko: 5d6ec4dddf14 Version: 35.0a1 (2.2) Firmware Version: L1TC10011800 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Environmental Variables: Device: Flame 2.1 BuildID: 20141002000202 Gaia: 94dcc25f2e34a4900ea58310c26be52bcb089161 Gecko: baaa0c3ab8fd Version: 34.0a2 (2.1) Firmware Version: L1TC10011800 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Environmental Variables: Device: Flame 2.0 BuildID: 20141001000205 Gaia: ddb7567c60b31dbcb27817f8c126bbba8dccb63b Gecko: e3545ca967ae Version: 32.0 (2.0) Firmware Version: L1TC10011800 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Here's my WIP: https://github.com/Cwiiis/gaia/tree/bug1061466-system-update-splash I've no idea if this works, I've not thought of a good way to test this yet... It's quite late here, so n?kgrandon for ideas in case he has something that'll save me some time working it out tomorrow morning.

(In reply to Chris Lord [:cwiiis] from comment #33) > Here's my WIP: > https://github.com/Cwiiis/gaia/tree/bug1061466-system-update-splash > > I've no idea if this works, I've not thought of a good way to test this > yet... It's quite late here, so n?kgrandon for ideas in case he has > something that'll save me some time working it out tomorrow morning. I think the ideal solution here is to create some kind of "fake update server" running in node.js. Your test could then go through the full flow of downloading and installing the update. We would then also probably need to intercept the update-prompt-apply-result event. http://mxr.mozilla.org/mozilla-central/source/b2g/components/UpdatePrompt.js#450 It's probably a *lot* of work to get something like this working, but I think it could provide a lot of value. I imagine that the fake update server would work a lot like the fake app server does in the vertical home screen.

I tested this by just manually calling the acceptInstall method on the system update object. Will attach a screenshot. I'm not flagging this for review yet, as we could do with some kind of marionette test for this (I think a unit test is of limited use, but I could certainly add one). If this is super-urgent, we could apply this patch to 2.1 without the tests I suppose, if someone is able to verify manually that it works ok.

Here's an actual screenshot to compare to attachment #8489451 [details]. I'd say it's reasonably close, the font kerning isn't quite the same and the shadow on the divider isn't exactly the same either, but hopefully close enough?

Comment on attachment 8504606 [details] System update prompt screenshot Thanks Chris, this is close enough :)

Comment on attachment 8504590 [details] Show a splash screen before initiating a system update Added a very basic marionette test. Note, I think we could do with a suite of system-update marionette tests (as there don't currently appear to be any?), as kgrandon alludes to, but I think that's a separate bug to this one.

Comment on attachment 8504590 [details] Show a splash screen before initiating a system update r=me

Merged in master: https://github.com/mozilla-b2g/gaia/commit/80db58e27291e1cc3eb4e6828bf8ca6c62a6b697

Comment on attachment 8504590 [details] Show a splash screen before initiating a system update [Approval Request Comment] [Bug caused by] (feature/regressing bug #): This bug [User impact] if declined: Performing a system update can look like the phone has hung [Testing completed]: Tested locally via code injection and marionette, but not tested by doing an actual system update. [Risk to taking this patch] (and alternatives if risky): If the event handler for doing an update and restarting doesn't work for whatever reason, this could leave an undismissable splash screen on the screen. I assume that this can't happen, but would appreciate someone with the ability to simulate or do system updates to confirm this works correctly. [String changes made]: None

Now that this is in master, adding qawanted to test that it works as expected (i.e. doing a system update that would formerly cause the phone screen to hang now shows this splash-screen instead). I don't know if a tako device is required to test this or not.

sorry had to revert the changes for test failures like https://treeherder.mozilla.org/ui/logviewer.html#?job_id=644982&repo=b2g-inbound

Whoops, looks like I forgot to re-check unit tests before hitting merge. Small error, will fix. Darn unit tests...

Small change to the updatable unit test to fix errors, carrying r+.

Unit tests green, merged again: https://github.com/mozilla-b2g/gaia/commit/25a74ff8f5caf8c391ef547fc4f48ed8cf20c606

Comment on attachment 8505530 [details] Show a splash screen before initiating a system update (fixed unit tests) Re-requesting approval, copy-pasted from comment #41 [Approval Request Comment] [Bug caused by] (feature/regressing bug #): This bug [User impact] if declined: Performing a system update can look like the phone has hung [Testing completed]: Tested locally via code injection and marionette, but not tested by doing an actual system update. [Risk to taking this patch] (and alternatives if risky): If the event handler for doing an update and restarting doesn't work for whatever reason, this could leave an undismissable splash screen on the screen. I assume that this can't happen, but would appreciate someone with the ability to simulate or do system updates to confirm this works correctly. [String changes made]: None

v2.1: https://github.com/mozilla-b2g/gaia/commit/ee99635743af980b35f80b414c83da25c6b2fa1d

Issue verified fixed on Flame 2.1 and Flame 2.2 Actual Result: After user selects install software update they are given a system update splash screen when user performs OTA from 2.1 to 2.2 or from older 2.2 to current 2.2. Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash) Build ID: 20141027001201 Gaia: c97463d61f45513a2123b19610386ddbfc916819 Gecko: 4f8c0c021128 Version: 34.0 (2.1) Firmware Version: v188 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Device: Flame Master (319mb)(Kitkat Base)(Full Flash) Build ID: 20141027040237 Gaia: e91d99e4d96954f06383c00bb9d79598a697e310 Gecko: 8230834302c9 Version: 36.0a1 (Master) Firmware Version: v188 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Leaving QAWanted keyword as comment 42 was never answered

issue verified fixed - removing old keywords