1027935 - [Vertical Homescreen] App cannot be launch if an update is available

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

Description

[Johan Lorenzo [:jlorenzo]]

STR
1. Get http://mozilla.github.io/qa-testcase-data/webapi/apps/singleasm.manifest and host it on your own HTTP server
2. Install the app by pointing to you self-hosted mini-manifest via you browser
3. To simulate an app update, in the the mini-manifest, modify:
"package_path": "*value*" to "package_path": "http://mozilla.github.io/qa-testcase-data/webapi/apps/updates/singleasm-updated-twoasm.zip" 
"version": "1.0" to "version": "2.0"
4. Check for new version and wait until the notification pop.
5. Tap the icon app on the homescreen.

Expected result
App can be started.

Actual result
"Restart download" panel is shown

Comment 1

[Johan Lorenzo [:jlorenzo]]

Standard user path + regression from 1.4.

Comment 2

[Jacqueline Savory [:jsavory] UX]

In this case I believe that the actual result is the correct behaviour. 

When the user begins the download and install of an update, they correct action when tapped is to cancel the progress of the update. They should not be able to launch the application once the update has begun as this could cause possible errors.

Comment 3

[Jason Smith [:jsmith]]

(In reply to jsavory from comment #2)
> In this case I believe that the actual result is the correct behaviour. 
> 
> When the user begins the download and install of an update, they correct
> action when tapped is to cancel the progress of the update. They should not
> be able to launch the application once the update has begun as this could
> cause possible errors.

I don't think that matches my understanding of how the mozApps API works. IIRC, we stage a download of an update so that the old app can still be used while the update is occurring. I know this was working previously as well on the old homescreen & we never really had a problem with this.

Comment 4

[James Lal [:lightsofapollo]]

>I don't think that matches my understanding of how the mozApps API works.

This comes directly from fabrice... Even though it may have worked before it is not really intended behavior (it is effectively a nice big race).

Comment 5

[Jason Smith [:jsmith]]

(In reply to James Lal [:lightsofapollo] from comment #4)
> >I don't think that matches my understanding of how the mozApps API works.
> 
> This comes directly from fabrice... Even though it may have worked before it
> is not really intended behavior (it is effectively a nice big race).

To my understanding, I think this was a product requirement called out explicitly in 1.01.

See https://moztrap.mozilla.org/manage/case/4168/, which cites this user story:

As a user, once I decide to download update(s), I want to be able to use the updating app(s) while their updates download, so that I don't have to choose between updating and using the app.

Comment 6

[James Lal [:lightsofapollo]]

So- I am not really sure what to do one way or another at this point. We could implement something that for a canceled updated we don't show the resume dialog but launch the older app? I don't know what the best path forward here is.

Comment 7

[Jason Smith [:jsmith]]

Peter - Can you confirm that the user story called out in comment 5 still holds validity in the 2.0 homescreen? There's debate here that the user story might not be valid, so I'd like product input.

Comment 8

[Jacqueline Savory [:jsavory] UX]

I think it would be better for the user to cancel the update and then launch it - as opposed to launching it during the update. 

It would be best if cancelling a download for a new app and updating an app worked the same way or at least similar. It is very important for the user to be able to easily cancel a download or install and if we change it for updates, it might be overly complicated.

Comment 9

[Jason Smith [:jsmith]]

(In reply to jsavory from comment #8)
> I think it would be better for the user to cancel the update and then launch
> it - as opposed to launching it during the update. 
> 
> It would be best if cancelling a download for a new app and updating an app
> worked the same way or at least similar. It is very important for the user
> to be able to easily cancel a download or install and if we change it for
> updates, it might be overly complicated.

The problem I see with this workflow is that forces the user to patient while the app is updating to accept the fact that he/she can't use the app during update workflow. Are users willing to accept a loss of access to an app temporarily for the sake of an update in progress? They'll likely be annoyed that they'll have to stop an update to use the app & then restart the update again to make sure that they can both use the app & get the update as well (i.e. significant increase of user steps & potential risk for mistakes).

What does Android & iOS do here?

Comment 10

[Kevin Grandon :kgrandon]

So far James, UX (Jacqueline), and myself all think that this is fine as-is (show a cancel/resume) instead of launching the app.

I also verified that iOS does not allow launching of apps, and only allows pause/cancel.

Re-noming for 2.0? and suggesting that we don't block.

Comment 11

[Jason Smith [:jsmith]]

(In reply to Kevin Grandon :kgrandon from comment #10)
> So far James, UX (Jacqueline), and myself all think that this is fine as-is
> (show a cancel/resume) instead of launching the app.
> 
> I also verified that iOS does not allow launching of apps, and only allows
> pause/cancel.
> 
> Re-noming for 2.0? and suggesting that we don't block.

Relooking at the bug I think the analysis here was done incorrectly. The bug here was misinterpreted - the bug is talking about the fact that you can't launch an app with an update available. The update has *not* started progress in downloading, so the UX assessment doesn't apply to this bug. On that regard, this remains as a blocker since the above assessment is not relevant to the bug here.

Comment 12

[Kevin Grandon :kgrandon]

Reading the bug report I suppose I'd like clarification from Johan. Johan - did you start to download the app, or did you simply have a notification waiting in the utility tray?

Comment 13

[Johan Lorenzo [:jlorenzo]]

I just waited for having the notification and then I tapped the icon.

Comment 14

[James Lal [:lightsofapollo]]

I also misunderstood- I think I know the problem here and how to fix it...

Comment 15

[James Lal [:lightsofapollo]]

I have a fix that solves the primary part of this bug but it breaks pausing/resuming downloads... It is very tricky to do this correctly unless we clear errors on successful states so marking that bug blocking this one.

Comment 16

[James Lal [:lightsofapollo]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/21006

Note- this has a hard dependency on bug 1027347 which should land _first_ some workflows are broken on current master with this patch due to the hacks I removed.

Comment 17

[James Lal [:lightsofapollo]]

Attachment: Only set downloadError to an error if it actually is an error and clear past errors after successful states

Comment 18

[James Lal [:lightsofapollo]]

Comment on attachment 8446309 [details] [diff] [review]
Only set downloadError to an error if it actually is an error and clear past errors after successful states

bug number typo...

Comment 19

[James Lal [:lightsofapollo]]

Same here.... Will watch this today just needs the gecko bug to land.

Comment 20

[Kevin Grandon :kgrandon]

There are some linter errors. If you don't get to them when we have the next nightly b2g, I will rebase and fix them up. Thanks James.

Comment 21

[Kevin Grandon :kgrandon]

Comment on attachment 8446308 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/21006

Need to make sure we get a green build before we can land, but this looks great. Thanks!

Comment 22

[James Lal [:lightsofapollo]]

Gecko side just hit mozilla central... will retrigger jobs (now and again in a few hours to verify we picked up the changes)

Comment 23

[Kevin Grandon :kgrandon]

Attachment: Github pull request

Linter fixes and test re-run.

Comment 24

[Kevin Grandon :kgrandon]

Landed: https://github.com/mozilla-b2g/gaia/commit/88a69ca86576d29bcdfbe0d5db628dde8ad186c4

Comment 25

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/f0164867bbf8ee4b9bc5f03b21589f69ad6449f4