1. go to http://anitroubles.com/app.webapp?feature_profile=3ebdd4ff36b6.46.3 2. delete the app after download 3. reboot the device Expected: no notification after the device starts up again. Actual: notification that the webapp is downloading after it starts up. Gaia 67e8b2b0d150f87b4297bb2f1fbae3d4aca3e5a7 Gecko BuildID 20131010004040 Version 18.0 ro.build.version.incremental=eng.zxliu.20131010.001907 ro.build.date=Thu Oct 10 00:19:23 CST 2013 Buri
The build information seems a bit off - we didn't even support the download manager in the build ID cited here. I'm assuming this was tested with today's master build?
Do we know if the information used to file this bug is accurate. None of the APIs exist in b2g18.
(In reply to Ghislain 'Aus' Lacroix from comment #2) > Do we know if the information used to file this bug is accurate. None of the > APIs exist in b2g18. Don't think so - but I have seen this bug myself on the latest builds. Naoki - Can you fix your build info?
http://bit.ly/19D4jY1 Sorry, I was testing on an older version for different reasons. I retested using the bit.ly link above (same link, just bit.ly'ed it) Gaia 9a222ac02db176e47299bb37112ae40aeadbeca7 Gecko http://hg.mozilla.org/mozilla-central/rev/14ac61461f2a BuildID 20140106040201 Version 29.0a1 ro.build.version.incremental=eng.archermind.20131114.105818 ro.build.date=Thu Nov 14 10:58:33 CST 2013
There it is! Thanks Naoki. :) I'll add it to my list of issues to fix with the Downloads API.
Assignee: nobody → aus
Status: NEW → ASSIGNED
What is the status here? Does this still reproduce?
Severity: normal → major
Priority: -- → P1
Target Milestone: --- → 1.4 S1 (14feb)
Target Milestone: 1.4 S1 (14feb) → 1.4 S2 (28feb)
So, this also seems to cause all web apps installed to trigger a notification on start-up of the OS. Also not good. Quite a few people were experiencing this during the last work week.
Whiteboard: [p=5][systemsfe] → [systemsfe][p=5]
So I'm unfortunately not seeing with on the phone while running the latest nightly from GP on a Keon and the link that was provided in the description is now dead. :(
Naoki, do you have another resource for which this bug occurs?
Vivien, does this still happen for you?
QA wanted to check if this reproduces on the latest 1.4 build.
Hi, as stated in previous comment, both links listed to use with this issue are non-functioning. Will check on v1.4 when able.
(In reply to rpribble from comment #12) > Hi, as stated in previous comment, both links listed to use with this issue > are non-functioning. Will check on v1.4 when able. The links there I don't think are the only ways to reproduce this bug - this should happen with any type of download. Try these links instead to see if you can reproduce: * https://marketplace.firefox.com/app/94b4e4da-30f4-466b-9477-ec946f526bca/manifest.webapp * https://m.facebook.com/openwebapp/manifest.webapp
I tried by downloading a bunch of the top apps from marketplace and uninstall some of them and leaving the others, in different permutations and I wasn't able to reproduce. From my understanding that should be the same code path.
(In reply to Ghislain Aus Lacroix [:aus] from comment #14) > I tried by downloading a bunch of the top apps from marketplace and > uninstall some of them and leaving the others, in different permutations and > I wasn't able to reproduce. From my understanding that should be the same > code path. Downloading apps isn't related to this bug though. That uses an entirely different API.
Issue still occurring on the latest v1.4. Reproduced using both links posted by Jason above. Webapps are downloaded then deleted, device is restarted, and webapps are immediately downloaded again with no prompt from user. Environmental Variables: Device: buri v1.4 moz BuildID: 20140225040205 Gaia: e0f39c7179c8b297326c0e2313950610be1f5c52 Gecko: e3daaa4c73dd Version: 30.0a1 Firmware Version: v1.2-device.cfg
Exactly how are you guys reproducing this? Just saying you're downloading the file is a little vague. Are you using the browser? Are you manually entering the URL? By clicking on the links in the comment, I am not seeing anything happen, not even a download.
Could I get exact STRs including exactly *how* you are triggering the download?
OK, I managed to get it to reproduce. My phone got wedged into USB Mode and needed an extra restart. STRs: 1. Start Browser App, Go to this bug, comment #13 2. Click on one of the links in the comment 3. Observe that download of file completes. 4. Restart Phone (either power off, power on, or restart option, depending on your build) 5. Observe notification on restart.
Created attachment 8381823 [details] [review] Pull Request - When initializing the Gaia Download Manager, clear mozDownloadManager of all succeeded downloads. I wasn't sure where you would prefer clearing all the completed downloads from the underlying mozDownloadManager but, it should be something that we do. We don't need to keep those around at all. We could also see if we know about the download already in the Download Store, if it's in succeeded state and then opt to skip creating notifications. The reason this is happening is because we send notifications for all downloads that still exist when starting up. This includes succeeded downloads. But, the DLM code in Gaia doesn't ever clear any of those, even though we have everything we need in the Download Store. With this patch, the notification *will* persist (which is what we want) until the user clears it from the notifications. After that, no new notifications will be generated but the download can still be managed in the Settings -> Downloads section.
Attachment #8381823 - Flags: review?(crdlc)
Comment on attachment 8381823 [details] [review] Pull Request - When initializing the Gaia Download Manager, clear mozDownloadManager of all succeeded downloads. Good job! Thanks a lot for the patch
Attachment #8381823 - Flags: review?(crdlc) → review+
Thanks Cristian! I'll update the test that's failing and once that all passes I'll be merging.
Tests updated. Everything passing. Merged to master. Commit: https://github.com/mozilla-b2g/gaia/commit/4d2d6f8c424a35cb8624c1d39f741a1172c82e4f Remember, when testing this, notifications are persistent and the downloads were persisted in the Gecko Downloads API. You will get notified of these downloads one more time and this is normal.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.