Closed Bug 1025782 Opened 5 years ago Closed 5 years ago

[Vertical homescreen] Problem stopping downloads after first retry

Categories

(Core Graveyard :: DOM: Apps, defect)

All
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:2.0+, firefox31 wontfix, firefox32 fixed, firefox33 fixed, b2g-v2.0 verified, b2g-v2.1 verified)

RESOLVED FIXED
mozilla33
blocking-b2g 2.0+
Tracking Status
firefox31 --- wontfix
firefox32 --- fixed
firefox33 --- fixed
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: crdlc, Assigned: jlal)

References

Details

(Whiteboard: [systemsfe])

Attachments

(1 file)

STR:

1) Go to marketplace and install "Cut the Rope" for instance
2) Go to vertical homescreen and click on cut the rope icon while is downloading
3) Stop the download
4) Click on icon again and resume it, the download starts again successfully
5) Click on icon again and....

Expected

* Stop UI is displayed

Current state:

* Resume UI is displayed

I can see that app.downloading is false when it is re-started in this point

https://github.com/mozilla-b2g/gaia/blob/master/shared/elements/gaia_grid/js/items/mozapp.js#L174
Whiteboard: [systemsfe]
Needed for parity with the old homescreen.
blocking-b2g: --- → 2.0?
QA Whiteboard: [VH-FL-blocking-][VH-FC-blocking+]
Duplicate of this bug: 1026032
Blocks: 1015336
No longer blocks: vertical-homescreen
(In reply to Jason Smith [:jsmith] from comment #1)
> Needed for parity with the old homescreen.

I think we are at partiy, as I just tested this on the homescreen and it appears totally broken :)

Myk or Fabrice - any idea about this?
Flags: needinfo?(myk)
Flags: needinfo?(fabrice)
Ah, appears that this a problem now because we have additional functionality on the vertical homescreen. I just verified that on the current homescreen we always prompt to re-download the application. On the vertical homescreen we have new functionality to cancel a download by tapping on the icon while it is downloading. In order to do this we need app.downloading to have the proper state.
blocking-b2g: 2.0? → 2.0+
(In reply to Kevin Grandon :kgrandon from comment #3)
> (In reply to Jason Smith [:jsmith] from comment #1)
> > Needed for parity with the old homescreen.
> 
> I think we are at partiy, as I just tested this on the homescreen and it
> appears totally broken :)
> 
> Myk or Fabrice - any idea about this?

Probably a regression then - can we try getting a range?
Oh wait - saw the comment later - it's only present with the VH.
Yes, I can confirm that Kevin says. Only the new homescreen has this new feature cancel/resume downloads.

(In reply to Kevin Grandon :kgrandon from comment #4)
> Ah, appears that this a problem now because we have additional functionality
> on the vertical homescreen. I just verified that on the current homescreen
> we always prompt to re-download the application. On the vertical homescreen
> we have new functionality to cancel a download by tapping on the icon while
> it is downloading. In order to do this we need app.downloading to have the
> proper state.
Note that there is bug 903291 about the app object state that looks wrong sometimes.
It's unclear to me at this point if there is actually a bug or if it's due to a difference between the old and the new homescreen.
Flags: needinfo?(fabrice)
(In reply to < away until June 17 > from comment #9)
> It's unclear to me at this point if there is actually a bug or if it's due
> to a difference between the old and the new homescreen.

This is a bug in the mozApp object not having the correct downloading attribute after a second download() call. We can rename this to be more clear if that would help? Or alternatively we can block on another platform bug?
(In reply to Kevin Grandon :kgrandon from comment #10)
> (In reply to < away until June 17 > from comment #9)
> > It's unclear to me at this point if there is actually a bug or if it's due
> > to a difference between the old and the new homescreen.
> 
> This is a bug in the mozApp object not having the correct downloading
> attribute after a second download() call. We can rename this to be more
> clear if that would help? Or alternatively we can block on another platform
> bug?

Renaming this one is fine.
Fernando - Any chance you'd know how to fix this bug off the top of your head or be willing to look into it?
Flags: needinfo?(ferjmoreno)
This works in my tests of https://bugzilla.mozilla.org/show_bug.cgi?id=1027458 with the visual refresh patch https://bugzilla.mozilla.org/show_bug.cgi?id=1023950 so assigning myself here too...
Assignee: nobody → jlal
It seems that James is already looking into it.
Flags: needinfo?(ferjmoreno)
Hmm, I'm not sure what's going on here, but over in bug 1013433 I recently fixed an issue where startDownload would think downloadPackage succeeded even when it failed.  I wonder if that issue could be related.
Flags: needinfo?(myk)
Should be fixed in by bug 1027458 in mozilla-central (we need to uplift to aurora)
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Depends on: 1027458
Target Milestone: --- → mozilla33
Attached video VIDEO0144.mp4
This issue has been successfully verified on Flame 2.0:
Gaia-Rev        3aa0797c111a40e36f722722309668de3d469181
Gecko-Rev       93efc8b4155f0a4a50eaad19acbb95ec24139e63
Build-ID        20141204050313
Version         32.0
Device-Name     jrdhz72_w_ff
FW-Release      4.4.2

This issue has been successfully verified on Flame 2.1:
Gaia-Rev        dbaf3e31c9ba9c3436e074381744f2971e15c7bf
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ebce587d2194
Build-ID        20141203001205
Version         34.0
Device-Name     flame
FW-Release      4.4.2
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.