Wasiem Hamadeh [:WasiemH] Reporter
	Description • 10 years ago

Description:
Downloading pdf files from the web and deleting them, leaves and infinite downloading icon in the task manager. 
   
Repro Steps:
1) Update a Flame device to BuildID: 20141003000203
2) Go to google and type test files.
3) Click on the 3rd link in the search results stating "Test Download Files- Internode.
4) Download 4 files from the web. 
5) Go to settings, Downloads, then select and delete all.
  
Actual:
Download Icon displays infinitely in the task manager bar even after deleting all pdf files.
  
Expected: 
Download Icon no longer appears after deleting all pdf files.
  
Environmental Variables:
Device: Flame 2.1 KK Full Flash(319mb)
BuildID: 20141003000203
Gaia: 9861c61ec302fb0316c753a2e1c0f592180515fd
Gecko: da68900d1c66
Gonk: 2c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
  
Repro frequency: 100%
See attached: logcat, video clip: http://youtu.be/3Oa_MKh0l_o

	Wasiem Hamadeh [:WasiemH] Reporter
	Comment 1 • 10 years ago

Issue DOES occur on Flame 2.2KK Full Flash, Flame 2.0KK Full Flash.

Downloading pdf files from the web and deleting them, leaves and infinite downloading icon in the task manager. 

Flame 2.2 KitKat Base (319mb)(Full Flash)

Environmental Variables:
Device: Flame 2.2 Master
BuildID: 20141003040207
Gaia: d711d1e469eeeecf25a02b2407a542a598918b2c
Gecko: b85c260821ab
Gonk: 2c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Flame 2.0 KitKat Base (319mb)(Full Flash)

Environmental Variables:
Device: Flame 2.0
BuildID: 20141003000204
Gaia: fa797854bfe708129ed54a158ad4336df1015c39
Gecko: 9b7fd1f78a15
Gonk: 2c909e821d107d414f851e267dedcd7aae2cebf
Version: 32.0 (2.0)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

	Derek Harris [:DerekH] - Dont need info. Last day 6/5/15
	Comment 2 • 10 years ago

[Blocking Requested - why for this release]:

It looks like if multiple files are downloaded, and 1 of them finishes, and then the user tries to delete all files in the download manager, the file that was fully downloaded cannot be deleted. Also the downloads are stuck in notification tray, and the downloads icon will remain in the status bar.
Nominating this to block 2.0?

	Wayne Chang [:wchang]
	Comment 3 • 10 years ago

Dietrich,

looks like part of download manager here, do you know who is best to take a look at this?

Wasiem,

Does it recover on reboot?

	Andrew Overholt [:overholt]
	Comment 4 • 10 years ago

The triage group decided that due to this being a bug with data usage which is sensitive for many users and seems likely to be a regression from 1.4, we'd like to block on it.

Cristian, is this something you can take?

	Cristian Rodriguez (:crdlc)
	Comment 5 • 10 years ago

Sorry, now I am focus on FFOS Loop client

	Andrew Overholt [:overholt]
	Comment 6 • 10 years ago

Gregor, is this Systems FE territory?

	Andrew Overholt [:overholt]
	Comment 7 • 10 years ago

Oops, I forgot to set 2.0+ yesterday.

	Gregor Wagner [:gwagner]
	Comment 8 • 10 years ago

Aus, can you take a look here?

	Aus Lacroix [:aus] Assignee
	Comment 9 • 10 years ago

Yup, I can take a look at this today. The logcat looks kinda funky though, DOM Workers segfaulting is never a good thing.

	Aus Lacroix [:aus] Assignee
	Comment 11 • 10 years ago

Not as funky after digging deeper. Exact STR are as follows:

1. Initiate one 100M and one 50M download.
2. Go into Settings -> Downloads
3. Let the 50M download finish.
4. Before the 100M download finishes, select all and delete.

Actual -- Observe that the active download will delete as expected but the completed one does not.
Expected -- All downloads are stopped and removed from the downloads list.

If one leaves and returns to the Downloads List, you'll be able to delete the download without any issue. The download indicator does remain on forever however. The download indicator recovers on restart.

	Aus Lacroix [:aus] Assignee
	Comment 12 • 10 years ago

I have a pretty good handle on the problem and a solution in the works. I am expecting this issue to be resolved on master by Thursday and have it land on 2.1 and 2.0 by Friday.

The problem stems from how we handle completed downloads. Once a download completes, it will be removed from the underlying Gecko Downloads API and *only* present in the Downloads DataStore in Gaia (which is meant to store all completed downloads). When we do this while the Downloads List (in Settings) is showing we will fail to update the download item in the download cache for said Downloads List which causes a failure during removal.

	Rachelle Yang [:ryang][ryang@mozilla.com]
	Comment 13 • 10 years ago

Hi Ghislain, thanks for your comments and observation.

Could you please kindly share your progress and update with us on this bug? Thanks !

	Aus Lacroix [:aus] Assignee
	Comment 14 • 10 years ago

(In reply to Rachelle Yang [:ryang][ryang@mozilla.com] from comment #13)
> Hi Ghislain, thanks for your comments and observation.
> 
> Could you please kindly share your progress and update with us on this bug?
> Thanks !

Hello! This is almost ready! Several tests needed to be updated to cover the changes. The tests themselves also required updates to correct potential intermittent failures due to the use of setTimeout *without* fake timers. I'm hoping to get this into review today.

	Michael Henretty [:mikehenrty][:mhenretty]
	Comment 16 • 10 years ago

Comment on attachment 8514602 [details] [review]
Pull Request - Use DataStoreChangeEvents to update Download API Manage…  …r cache up to date. Move tracking of active downloads into StatusBar instead of DownloadNotifications.

LGTM. Let some nitty picks on github, but the approach seems solid.

	Rachelle Yang [:ryang][ryang@mozilla.com]
	Comment 17 • 10 years ago

Hi Ghislain, thank you very much for your efforts and your work !!

	Cristian Rodriguez (:crdlc)
	Comment 18 • 10 years ago

Comment on attachment 8514602 [details] [review]
Pull Request - Use DataStoreChangeEvents to update Download API Manage…  …r cache up to date. Move tracking of active downloads into StatusBar instead of DownloadNotifications.

LGTM, moving this as feedback because I cannot review neither system nor settings as far as I know, good job as always

	Kevin Grandon :kgrandon
	Comment 19 • 10 years ago

Comment on attachment 8514602 [details] [review]
Pull Request - Use DataStoreChangeEvents to update Download API Manage…  …r cache up to date. Move tracking of active downloads into StatusBar instead of DownloadNotifications.

The changes do look good to me. I am not a peer of settings though, so you may need to flag someone there =/

	Aus Lacroix [:aus] Assignee
	Comment 20 • 10 years ago

Comment on attachment 8514602 [details] [review]
Pull Request - Use DataStoreChangeEvents to update Download API Manage…  …r cache up to date. Move tracking of active downloads into StatusBar instead of DownloadNotifications.

José, I'm hoping you can review the changes that are part of the Settings App.

	Aus Lacroix [:aus] Assignee
	Comment 21 • 10 years ago

Also flagged Evelyn for review, hoping someone can get to it soon.

	Evelyn Hung
	Comment 22 • 10 years ago

Comment on attachment 8514602 [details] [review]
Pull Request - Use DataStoreChangeEvents to update Download API Manage…  …r cache up to date. Move tracking of active downloads into StatusBar instead of DownloadNotifications.

pass to Arthur who is Setting owner now, and he should be able to review it today.

	Arthur Chen [:arthurcc][inactive after 6/30]
	Comment 23 • 10 years ago

Comment on attachment 8514602 [details] [review]
Pull Request - Use DataStoreChangeEvents to update Download API Manage…  …r cache up to date. Move tracking of active downloads into StatusBar instead of DownloadNotifications.

The issue was fixed even I reverted the changes in settings app. I guess I did not encounter the case that the changes trying to address.

Please check my comments in github. Most of them are regarding readability and code structure.

	Aus Lacroix [:aus] Assignee
	Comment 24 • 10 years ago

Comment on attachment 8514602 [details] [review]
Pull Request - Use DataStoreChangeEvents to update Download API Manage…  …r cache up to date. Move tracking of active downloads into StatusBar instead of DownloadNotifications.

I've addressed the nits and concerns and also left some comments that will hopefully explain why some of your concerns I would prefer to address later. :)

	Arthur Chen [:arthurcc][inactive after 6/30]
	Comment 25 • 10 years ago

Comment on attachment 8514602 [details] [review]
Pull Request - Use DataStoreChangeEvents to update Download API Manage…  …r cache up to date. Move tracking of active downloads into StatusBar instead of DownloadNotifications.

Let's address the issue of timer and event listeners later. But there is a major issue regarding `downloadApiId`, please check my comments in github, thanks.

	Aus Lacroix [:aus] Assignee
	Comment 26 • 10 years ago

Comment on attachment 8514602 [details] [review]
Pull Request - Use DataStoreChangeEvents to update Download API Manage…  …r cache up to date. Move tracking of active downloads into StatusBar instead of DownloadNotifications.

I've improved the downloadApiListener so that it will handle 'added' events with no 'downloadApiId' present in the changeEvent.

	Arthur Chen [:arthurcc][inactive after 6/30]
	Comment 27 • 10 years ago

Comment on attachment 8514602 [details] [review]
Pull Request - Use DataStoreChangeEvents to update Download API Manage…  …r cache up to date. Move tracking of active downloads into StatusBar instead of DownloadNotifications.

r=me, thanks!

	Aus Lacroix [:aus] Assignee
	Comment 28 • 10 years ago

Commit (master): https://github.com/mozilla-b2g/gaia/commit/e9ac899aff346b2cef9be154290978fc18d1bc8f

Fixed!

Thanks everyone for your patience with this. Branch approval requests coming.

	Aus Lacroix [:aus] Assignee
	Comment 29 • 10 years ago

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Pre-existing condition not discovered until recently.
[User impact] if declined: Impossible to delete certain downloads until Settings app is killed and restarted or phone is restarted.
[Testing completed]: On Flame v188 (v2.2, v2.1, 319M) + unit tests
[Risk to taking this patch] (and alternatives if risky): Medium, ship with pre-existing issue, remove blocking status.
[String changes made]: None.

	Aus Lacroix [:aus] Assignee
	Comment 30 • 10 years ago

Asking for quick verification on 2.2.

	Aus Lacroix [:aus] Assignee
	Comment 31 • 10 years ago

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Pre-existing condition
[User impact] if declined: Impossible to delete certain downloads until Settings app is killed and restarted or phone is restarted.
[Testing completed]: On Device Flame v188 (v2.1, v2.2, 319M), unit-tests
[Risk to taking this patch] (and alternatives if risky): Medium, ship with pre-existing issue, remove blocking status.
[String changes made]: None.

	Aus Lacroix [:aus] Assignee
	Comment 32 • 10 years ago

v2.1 pull request looks good to go but there is an issue with the test on 2.0. Investigating...

	bhavana bajaj [:bajaj]
	Comment 33 • 10 years ago

NI :joshua_m to help prioritize the verification here before we uplift on branches.

	Yeojin Chung [:YeojinC]
	Comment 34 • 10 years ago

This issue still reproduces on Flame 2.2.

Result: Following STRs in Comment 11, the completed file still remains on the list after the user selects to delete the file.

Device: Flame 2.2 (319mb, KK, Full Flash)
BuildID: 20141110040206
Gaia: 5f8206bab97cdd7b547cc2c8953cadb2a80a7e11
Gecko: d380166816dd
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

	Aus Lacroix [:aus] Assignee
	Comment 35 • 10 years ago

I'm not seeing this issue on master with my fix. What I am seeing though is that the download indicator remains active *sometimes*.

I'm on v188 with Gecko from a few days ago and latest master. I hope this isn't a gecko regression!

	Aus Lacroix [:aus] Assignee
	Comment 36 • 10 years ago

Could I get a video of the issue still reproducing (file failing to delete)?

	Duane Dixon [:ddixon]
	Comment 37 • 10 years ago

Unable to reproduce issue in latest Flame 2.2 Tinderbox Engineering (Shallow Flash), Flame 2.2 Nightly (Full Flash) build, and Flame 2.1 Nightly (Full Flash).  

Actual Results: The Download icon in status bar turns off as expected when user deletes a PDF while it is downloading. 

Device: Flame 2.2
BuildID: 20141111042605
Gaia: 6af3a8a833eb8bb651e8b188cb3f3c3a43bb4184
Gecko: c60fc2c11c0e
Version: 36.0a1 (2.2)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
----------------------------------------------
Device: Flame 2.2
BuildID: 20141111040202
Gaia: 6af3a8a833eb8bb651e8b188cb3f3c3a43bb4184
Gecko: 76b85b90a8cb
Version: 36.0a1 (2.2)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
----------------------------------------------
Device: Flame 2.1
BuildID: 20141111001201
Gaia: 7154f9aa0a69af56c8bd89be0c98d9791449527b
Gecko: 452db1a0c9a0
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

	Joshua Mitchell (Inactive)
	Comment 38 • 10 years ago

Yeojin - could you check this issue again

	Aus Lacroix [:aus] Assignee
	Comment 39 • 10 years ago

I just did my own test of this with a Flame v188-1, latest flame-kk b2g distro from mozilla central and 319M memory profile.

I'm seeing the issue in comment #35 but only intermittently. :( It seems that sometimes, we don't get a succeeded state change in the status bar download state change listener that's added to downloads in progress.

Otherwise, everything works as expected. This is also confirmed in comment #37.

	Yeojin Chung [:YeojinC]
	Comment 40 • 10 years ago

(In reply to Ghislain Aus Lacroix [:aus] from comment #36)
> Could I get a video of the issue still reproducing (file failing to delete)?

I do not see this issue anymore on Today's nightly. When the user selects all files to delete, the completed file is deleted as well.

However, I still see the issue that the downloading icon on the status bar remains after deleting all files.

Device: Flame 2.2 (319mb, KK, Shallow Flash)
BuildID: 20141111040202
Gaia: 6af3a8a833eb8bb651e8b188cb3f3c3a43bb4184
Gecko: 76b85b90a8cb
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

	Aus Lacroix [:aus] Assignee
	Comment 41 • 10 years ago

Upon further investigation. The issue remaining is actually different from this original bug but I would like to reland all changes for these issues together to simplify taking this change on other branches as they can't realistically be taken separately. I'll be backing out the commit on master and re-landing tomorrow. Apologies for this but it just feels lime the beat approach in this case. Reopening in the meantime.

	bhavana bajaj [:bajaj]
	Comment 42 • 10 years ago

(In reply to Ghislain Aus Lacroix [:aus] from comment #41)
> Upon further investigation. The issue remaining is actually different from
> this original bug but I would like to reland all changes for these issues
> together to simplify taking this change on other branches as they can't
> realistically be taken separately. I'll be backing out the commit on master
> and re-landing tomorrow. Apologies for this but it just feels lime the beat
> approach in this case. Reopening in the meantime.

Cleaning up the approval uplifts for branches. Lets get the master landing verified on the updated patches and then land on branches.

	Aus Lacroix [:aus] Assignee
	Comment 43 • 10 years ago

Backed out (master): https://github.com/mozilla-b2g/gaia/commit/df6c3140d88dc77366134d22367636ab3ec60a45

	Aus Lacroix [:aus] Assignee
	Comment 44 • 10 years ago

Pull Request updated. Minor changes compared to the original but they fix a few other issues that were still hanging around. IRC based reviews requested and approved for minor differences present from original reviewers.

Waiting for green try run to re-land.

	Aus Lacroix [:aus] Assignee
	Comment 46 • 10 years ago

Commit (master): https://github.com/mozilla-b2g/gaia/commit/906123b6d71bcd9d8db77227ffba7269e6cbaeb9

Fixed once again.

QA, could we please verify this ASAP so that we may land on branches as soon as possible?

	Aus Lacroix [:aus] Assignee
	Comment 47 • 10 years ago

Commit (master): https://github.com/mozilla-b2g/gaia/commit/906123b6d71bcd9d8db77227ffba7269e6cbaeb9

Fixed once again.

QA, could we please verify this ASAP so that we may land on branches as soon as possible?

	Yeojin Chung [:YeojinC]
	Comment 48 • 10 years ago

(In reply to Ghislain Aus Lacroix [:aus] from comment #47)
> Commit (master):
> https://github.com/mozilla-b2g/gaia/commit/
> 906123b6d71bcd9d8db77227ffba7269e6cbaeb9
> 
> Fixed once again.
> 
> QA, could we please verify this ASAP so that we may land on branches as soon
> as possible?

I was unable to verify this bug. The downloading icon is not displayed at all on the Downloads page. Although the icon is shown properly on notification tray and browser, the Downloads page does not show the downloading icon at all. Sometimes it shows the processing icon instead, which stays after the download is complete. This issue is observed on both today's nightly and the latest engineer build.

Nightly:
Device: Flame 2.2 (319mb, KK, Shallow Flash)
BuildID: 20141114040205
Gaia: 1e300eac2e56d98ad51d414766d031db7d33221f
Gecko: bbb68df450c2
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

Engineer:
Device: Flame 2.2 Master(319mb, KK, Shallow Flash)
BuildID: 20141114042015
Gaia: 1e300eac2e56d98ad51d414766d031db7d33221f
Gecko: 64206634959a
Version: 36.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

	Aus Lacroix [:aus] Assignee
	Comment 49 • 10 years ago

I think this may be normal. When downloading an item, there isn't necessarily going to be enough room in the status bar area to display the downloading icon.

I could confirm that that is the case with a screenshot.

	Aus Lacroix [:aus] Assignee
	Comment 53 • 10 years ago

This is likely where there is confusion. For example, if I had dual SIM, I would be *unable* to see the download indicator in the status bar. If I had another type of icon also, that has higher priority, this can happen and it's normal. It's a feature, actually. :)

	Yeojin Chung [:YeojinC]
	Comment 54 • 10 years ago

This bug is getting complicated. :) I hope my explanation makes sense.

First, I still observed the original issue, which was the persistent downloading icon. After the downloading was finished or deleted, I still saw the icon remaining on the status bar.

Video: http://youtu.be/tXQUnYrWtUo

Second, the issue I mentioned on Comment 48 still occurs occasionally, even if there is enough room for more icons. I haven't figured out how to reproduce this issue 100%, but here's the video with the downloading icon missing on the status bar, which is different from your screenshots.

Video: http://youtu.be/dIPGf4etjhA

Would this be a separate issue? Thanks!

	Aus Lacroix [:aus] Assignee
	Comment 55 • 10 years ago

I honestly can't repro the issue anymore. I'm at a loss as to what could be going wrong. Are we certain we're doing a full flash of 2.2?

	Aus Lacroix [:aus] Assignee
	Comment 56 • 10 years ago

Also, the issue reported in comment #48 is unrelated as *the entire status bar* vanishes and only the rocketbar is left present.

	Yeojin Chung [:YeojinC]
	Comment 57 • 10 years ago

I shallow flashed previously. I tried with full flash today, and I could not reproduce when I opened the Downloads screen by tapping the toast notification. But when the Download screen was opened by pulling down the notification tray and tapping the downloading notification, the downloading icon was missing from the status bar, or sometimes the processing indicator stayed after the download was completed or deleted. But the repro rate was very low with the last scenario. I hope this helps.

=================================
Device: Flame 2.2 (319mb, KK, Full Flash)

BuildID: 20141117040203
Gaia: ddf5b92f43ec27c93ad4fea4fd1207da8936b8e7
Gecko: 21b745197618
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

	Sam Foster [:sfoster] (he/him)
	Comment 58 • 10 years ago

Just reproduced with shallow flash with todays moz-central build, with steps: 

1. Open http://mirror.internode.on.net/pub/test/
2. Click '100MB' and '50MB' test links. Observe download statusbar icon indicating downloads in progress.
3. When notification arrives that 50MB has completed downloading, click it to go to the downloads settings page
4. Stop the in-progress 100MB download

Expected results: 
No downloads are in-progress, so download statusbar icon should disappear

Actual: 
Statusbar indicates downloads are in progress.

	Aus Lacroix [:aus] Assignee
	Comment 59 • 10 years ago

Bug 1099137 was already filed and this describes the issues reported in comment #48.

	Aus Lacroix [:aus] Assignee
	Comment 60 • 10 years ago

I also filed bug 1100553 which is a more accurate bug for the issue visible in the second video of comment #54.

	Aus Lacroix [:aus] Assignee
	Comment 61 • 10 years ago

There were quite a many backouts that were performed yesterday, if we could get a re-test on this I would appreciate it. :)

	Jayme Mercado [:JMercado] (Inactive 3/4/2016)
	Comment 62 • 10 years ago

I was unable to reproduce this issue on the latest 2.2 flame build

Environmental Variables:
Device: Flame 2.2
BuildID: 20141118082629
Gaia: 4aee256937afe9db2520752650685ba61ce6097d
Gecko: 084441e904d1
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

	Aus Lacroix [:aus] Assignee
	Comment 63 • 10 years ago

Passed verification on 2.2, removing failed-verification whiteboard tag. Requesting uplifts to 2.1 and 2.0 shortly.

	Aus Lacroix [:aus] Assignee
	Comment 64 • 10 years ago

Comment on attachment 8522574 [details] [review]
Pull Request - Use DataStoreChangeEvents to update Download API Manage…  …r cache up to date. Move tracking of active downloads into StatusBar instead of DownloadNotifications.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Pre-existing condition.
[User impact] if declined: User will be left with endless 'downloading' statusbar icons and the inability to remove certain downloads from the downloads list until the settings app is restarted.
[Testing completed]: On Device (Flame v188, 318M), Unit Tests, QA Verification on 2.2.
[Risk to taking this patch] (and alternatives if risky): Low considering the testing that's been completed.
[String changes made]: None.

	Aus Lacroix [:aus] Assignee
	Comment 65 • 10 years ago

Comment on attachment 8522574 [details] [review]
Pull Request - Use DataStoreChangeEvents to update Download API Manage…  …r cache up to date. Move tracking of active downloads into StatusBar instead of DownloadNotifications.

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): Pre-existing condition.
[User impact] if declined: User will be left with endless 'downloading' statusbar icons and the inability to remove certain downloads from the downloads list until the settings app is restarted.
[Testing completed]: On Device (Flame v188, 318M), Unit Tests, QA Verification on 2.2.
[Risk to taking this patch] (and alternatives if risky): Low considering the testing that's been completed.
[String changes made]: None.

	bhavana bajaj [:bajaj]
	Comment 66 • 10 years ago

Comment on attachment 8522574 [details] [review]
Pull Request - Use DataStoreChangeEvents to update Download API Manage…  …r cache up to date. Move tracking of active downloads into StatusBar instead of DownloadNotifications.

The hugs patch makes me nervous on approving this. But given the verification on master, approving for uplift. If we discover any blocking fallouts during branch verification we may have to back this out immediately than risking further by taking anymore forward fixes.

	Aus Lacroix [:aus] Assignee
	Comment 67 • 10 years ago

(In reply to bhavana bajaj [:bajaj] from comment #66)
> Comment on attachment 8522574 [details] [review]
> Pull Request - Use DataStoreChangeEvents to update Download API Manage…  …r
> cache up to date. Move tracking of active downloads into StatusBar instead
> of DownloadNotifications.
> 
> The hugs patch makes me nervous on approving this. But given the
> verification on master, approving for uplift. If we discover any blocking
> fallouts during branch verification we may have to back this out immediately
> than risking further by taking anymore forward fixes.

I wish my patch was made out of hugs. :) Joking aside, I will be ready to back it out from 2.1 and 2.0 if anything weird is spotted. Please note that a test fix found in bug 1095187 will be landing with a=test-only as this fix (bug 1077595) exposes a brittle integration test for the software home button.

	Aus Lacroix [:aus] Assignee
	Comment 68 • 10 years ago

Commit (v2.1): https://github.com/mozilla-b2g/gaia/commit/d5b9af3dfa2c39591421803258ef18dda4c71d17

	Aus Lacroix [:aus] Assignee
	Comment 69 • 10 years ago

Commit (v2.0): https://github.com/mozilla-b2g/gaia/commit/a64ccebcfae8971388c5271546fc7f2acaa704b7

	sarsenyev
	Comment 70 • 10 years ago

Verified the issue is fixed on 2.2, 2.1 Flame

The download icon is no longer spinning by trying to download the file, when the files are removed from the "Downloads" page
 
"Flame 2.2

Device: Flame 2.2 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141120040205
Gaia: 1abe09b4925547699dfdb2d358aed019137c3aa6
Gecko: 6ce1b906c690
Version: 36.0a1 (2.2 Master)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0"

"Flame 2.1 

Device: Flame 2.1 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141120001207
Gaia: f8d3bf44029e0afc0124600a4bb34dba8fc1ad21
Gecko: f70a67a7f846
Version: 34.0 (2.1)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0"
=====================================================================
Leaving "verifyme" to verify 2.0

	KTucker [:KTucker][Inactive 3/4/2016]
	Comment 71 • 10 years ago

Sergey, please verify 2.0 on tomorrow's build.

	sarsenyev
	Comment 72 • 10 years ago

Verified the issue is fixed on 2.0 Flame

The download icon is no longer spinning by trying to download the file, when the files are removed from the "Downloads" page
 

"Flame 2.0

Device: Flame 2.0 (319mb)(Kitkat Base)(Shallow Flash)
BuildID: 20141121000203
Gaia: 626d4d11a8c7e55022c1f364abb72ea340e2f1e7
Gecko: 74a294e72d0a
Version: 32.0 (2.0)
Firmware: V188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0"

	Kai-Zhen Li [:seinlin][:kli]
	Comment 73 • 10 years ago

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

	Coler
	Comment 74 • 10 years ago

This issue has been verified successfully on Woodduck 2.0.
Reproducing rate: 0/5
See attachment: Verify_Woodduck_Download.MP4

build version:
Gaia-Rev        87b23fa81c3b59f2ba24b84f7d686f4160d4e7cb
Gecko-Rev       d049d4ef127844121c9cf14d2e8ca91fd9045fcb
Build-ID        20141124050313
Version         32.0

	Ryan VanderMeulen [:RyanVM]
	Comment 75 • 10 years ago

(In reply to Ghislain Aus Lacroix [:aus] from comment #69)
> Commit (v2.0):
> https://github.com/mozilla-b2g/gaia/commit/
> a64ccebcfae8971388c5271546fc7f2acaa704b7

Impressive, this has been causing Gaia unit test permafails since it landed and apparently nobody cared for half a week. Backed out.
https://treeherder.mozilla.org/ui/logviewer.html#?job_id=61095&repo=mozilla-b2g32_v2_0

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

	Boaz Dodin
	Comment 76 • 10 years ago

For the purpose of tracking blocking bugs list (2.0), please reopen this bug.

	Kevin Grandon :kgrandon
	Comment 77 • 10 years ago

(In reply to Boaz Dodin from comment #76)
> For the purpose of tracking blocking bugs list (2.0), please reopen this bug.

I think we generally leave it as fixed, and wait for a branch patch for v2.0. The status-b2g will generally show the current status of the bug in the branches. Can you use the status-b2g flags for tracking?

	Ryan VanderMeulen [:RyanVM]
	Comment 78 • 10 years ago

Correct, bug resolution tracks master (unless the issue only exists on a branch). Status flags track branch uplifts. Note that this has been standard practice since basically ever and we have numerous practices that depend on that being true.

	Aus Lacroix [:aus] Assignee
	Comment 79 • 10 years ago

Fixed once again on v2.0: https://github.com/mozilla-b2g/gaia/commit/99e4594c66aa3738d58b0cb44bd885a87a063b6e

Only change was to the test that was failing on b2g32-v2.0.