Closed Bug 1027935 Opened 5 years ago Closed 5 years ago

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

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:2.0+, b2g-v2.0 fixed, b2g-v2.1 fixed)

RESOLVED FIXED
2.0 S5 (4july)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: jlorenzo, Assigned: jlal)

References

Details

(Keywords: regression, Whiteboard: [systemsfe])

Attachments

(1 file, 2 obsolete files)

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
Standard user path + regression from 1.4.
blocking-b2g: --- → 2.0?
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+]
Keywords: regression
blocking-b2g: 2.0? → 2.0+
Assignee: nobody → jlal
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.
(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.
>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).
(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.
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.
Assignee: jlal → nobody
Flags: needinfo?(jsavory)
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.
Flags: needinfo?(pdolanjski)
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.
Flags: needinfo?(jsavory)
(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?
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.
blocking-b2g: 2.0+ → 2.0?
(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.
Flags: needinfo?(pdolanjski)
blocking-b2g: 2.0? → 2.0+
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?
Flags: needinfo?(jlorenzo)
I just waited for having the notification and then I tapped the icon.
Flags: needinfo?(jlorenzo)
I also misunderstood- I think I know the problem here and how to fix it...
Assignee: nobody → jlal
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.
Depends on: 1027347
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.
Attachment #8446308 - Flags: review?(kgrandon)
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...
Attachment #8446309 - Attachment is obsolete: true
Attachment #8446309 - Flags: review?(fabrice)
Assignee: jlal → kgrandon
Target Milestone: --- → 2.0 S5 (4july)
Same here.... Will watch this today just needs the gecko bug to land.
Assignee: kgrandon → jlal
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 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!
Attachment #8446308 - Flags: review?(kgrandon) → review+
Gecko side just hit mozilla central... will retrigger jobs (now and again in a few hours to verify we picked up the changes)
Attached file Github pull request
Linter fixes and test re-run.
Attachment #8446308 - Attachment is obsolete: true
Attachment #8446889 - Flags: review+
Landed: https://github.com/mozilla-b2g/gaia/commit/88a69ca86576d29bcdfbe0d5db628dde8ad186c4
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.