Closed Bug 1077595 Opened 7 years ago Closed 7 years ago

[Window Management] After downloading pdf files then deleting them, the download icon in the status bar continues

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

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

VERIFIED FIXED
2.1 S9 (21Nov)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- fixed
b2g-v2.0M --- verified
b2g-v2.1 --- verified
b2g-v2.2 --- verified

People

(Reporter: whamadeh, Assigned: aus, NeedInfo)

References

()

Details

(Keywords: regression, Whiteboard: LocRun2.1-1, systemsfe)

Attachments

(6 files, 3 obsolete files)

81.03 KB, text/plain
Details
46 bytes, text/x-github-pull-request
aus
: review+
Details | Review
78.39 KB, image/png
Details
105.81 KB, image/png
Details
34.53 KB, image/png
Details
36.47 KB, image/png
Details
Attached file flame2.1logcat.txt
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
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
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(dharris)
[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?
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(dharris)
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?
Flags: needinfo?(whamadeh)
Flags: needinfo?(dietrich)
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?
Flags: needinfo?(dietrich) → needinfo?(crdlc)
Sorry, now I am focus on FFOS Loop client
Flags: needinfo?(crdlc)
Gregor, is this Systems FE territory?
Flags: needinfo?(anygregor)
Flags: needinfo?(anygregor)
Summary: [Window Management] After downloading pdf files then deleting them, the download icon in the task manager is suspended infinitely → [Window Management] After downloading pdf files then deleting them, the download icon in the status bar continues
Component: Gaia::System::Window Mgmt → Gaia::System
Whiteboard: LocRun2.1-1 → LocRun2.1-1, systemsfe
Oops, I forgot to set 2.0+ yesterday.
blocking-b2g: 2.0? → 2.0+
Aus, can you take a look here?
Assignee: nobody → aus
Yup, I can take a look at this today. The logcat looks kinda funky though, DOM Workers segfaulting is never a good thing.
Status: NEW → ASSIGNED
Target Milestone: --- → 2.1 S7 (24Oct)
Blocks: 1080790
Duplicate of this bug: 1085306
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.
Flags: needinfo?(whamadeh)
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.
Target Milestone: 2.1 S7 (24Oct) → 2.1 S8 (7Nov)
Hi Ghislain, thanks for your comments and observation.

Could you please kindly share your progress and update with us on this bug? Thanks !
Flags: needinfo?(aus)
(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.
Flags: needinfo?(aus)
Attachment #8514602 - Flags: review?(mhenretty)
Attachment #8514602 - Flags: review?(crdlc)
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.
Attachment #8514602 - Flags: review?(mhenretty) → review+
Hi Ghislain, thank you very much for your efforts and your work !!
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
Attachment #8514602 - Flags: review?(crdlc) → feedback+
Attachment #8514602 - Flags: review?(kgrandon)
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 =/
Attachment #8514602 - Flags: review?(kgrandon) → review+
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.
Attachment #8514602 - Flags: review?(josea.olivera)
Attachment #8514602 - Flags: review?(ehung)
Blocks: 1091923
Also flagged Evelyn for review, hoping someone can get to it soon.
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.
Attachment #8514602 - Flags: review?(ehung) → review?(arthur.chen)
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.
Attachment #8514602 - Flags: review?(josea.olivera)
Attachment #8514602 - Flags: review?(arthur.chen)
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. :)
Attachment #8514602 - Flags: review?(arthur.chen)
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.
Attachment #8514602 - Flags: review?(arthur.chen)
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.
Attachment #8514602 - Flags: review?(arthur.chen)
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!
Attachment #8514602 - Flags: review?(arthur.chen) → review+
Commit (master): https://github.com/mozilla-b2g/gaia/commit/e9ac899aff346b2cef9be154290978fc18d1bc8f

Fixed!

Thanks everyone for your patience with this. Branch approval requests coming.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Attached file Pull Request - v2.1 (obsolete) —
[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.
Attachment #8519249 - Flags: approval-gaia-v2.1?
Asking for quick verification on 2.2.
Attached file Pull Request - v2.0 (obsolete) —
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.
Attachment #8519268 - Flags: approval-gaia-v2.0?
v2.1 pull request looks good to go but there is an issue with the test on 2.0. Investigating...
Depends on: 1095187
NI :joshua_m to help prioritize the verification here before we uplift on branches.
Flags: needinfo?(jmitchell)
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
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?][failed-verification]
Flags: needinfo?(jmitchell) → needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
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!
Could I get a video of the issue still reproducing (file failing to delete)?
Keywords: verifymeqawanted
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
QA Whiteboard: [QAnalyst-Triage+][failed-verification] → [QAnalyst-Triage?][failed-verification]
Flags: needinfo?(jmitchell)
Keywords: qawanted
Yeojin - could you check this issue again
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(jmitchell) → needinfo?(ychung)
Keywords: verifyme
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.
(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
QA Whiteboard: [QAnalyst-Triage+][failed-verification] → [QAnalyst-Triage?][failed-verification]
Flags: needinfo?(ychung) → needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
Blocks: 1097435
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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.
Attachment #8519249 - Flags: approval-gaia-v2.1?
Attachment #8519268 - Flags: approval-gaia-v2.0?
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.
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?
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Keywords: qawanted
Resolution: --- → FIXED
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?
(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
QA Whiteboard: [QAnalyst-Triage+][failed-verification] → [QAnalyst-Triage?][failed-verification]
Flags: needinfo?(ktucker)
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.
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. :)
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!
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(ktucker)
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?
Also, the issue reported in comment #48 is unrelated as *the entire status bar* vanishes and only the rocketbar is left present.
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
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.
Bug 1099137 was already filed and this describes the issues reported in comment #48.
Depends on: 1099137
I also filed bug 1100553 which is a more accurate bug for the issue visible in the second video of comment #54.
There were quite a many backouts that were performed yesterday, if we could get a re-test on this I would appreciate it. :)
Keywords: qawanted
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
QA Whiteboard: [QAnalyst-Triage+][failed-verification] → [QAnalyst-Triage?][failed-verification]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(jmitchell)
Passed verification on 2.2, removing failed-verification whiteboard tag. Requesting uplifts to 2.1 and 2.0 shortly.
QA Whiteboard: [QAnalyst-Triage+][failed-verification] → [QAnalyst-Triage+]
Target Milestone: 2.1 S8 (7Nov) → 2.1 S9 (21Nov)
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.
Attachment #8522574 - Flags: approval-gaia-v2.1?
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.
Attachment #8522574 - Flags: approval-gaia-v2.0?
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.
Attachment #8522574 - Flags: approval-gaia-v2.1?
Attachment #8522574 - Flags: approval-gaia-v2.1+
Attachment #8522574 - Flags: approval-gaia-v2.0?
Attachment #8522574 - Flags: approval-gaia-v2.0+
(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.
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
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Sergey, please verify 2.0 on tomorrow's build.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage-]
Flags: needinfo?(ktucker) → needinfo?(sarsenyev)
Keywords: verifyme
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"
QA Whiteboard: [QAnalyst-Triage-] → [QAnalyst-Triage?]
Flags: needinfo?(sarsenyev) → needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
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
(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
Flags: needinfo?(aus)
For the purpose of tracking blocking bugs list (2.0), please reopen this bug.
Flags: needinfo?(whamadeh)
(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?
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.
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.
Flags: needinfo?(aus)
You need to log in before you can comment on or make changes to this bug.