Closed Bug 1358598 Opened 8 years ago Closed 7 years ago

Multiple downloads no longer show multiple notifications

Categories

(Firefox for Android Graveyard :: Download Manager, defect, P3)

52 Branch
All
Android
defect

Tracking

(fennec+, firefox58 wontfix, firefox59 wontfix, firefox60 verified, firefox61 verified)

VERIFIED FIXED
Firefox 61
Tracking Status
fennec + ---
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- verified
firefox61 --- verified

People

(Reporter: JanH, Assigned: JanH)

References

Details

(Keywords: regression, stale-bug)

Attachments

(1 file)

I've got a feeling that I've already seen a bug report for this recently, but if it actually exists, I can't find it now. In any case the issue is that with multiple downloads running concurrently, we no longer show multiple notifications.
Flags: needinfo?(nchen)
Summary: Multiple downloads no longer show multiple notificatiosn → Multiple downloads no longer show multiple notifications
I remember this being a limitation from bug 1305498.
Flags: needinfo?(nchen)
That's indeed what the blame is showing for the current notification code, however the original implementation in bug 1304145 apparently broke this as well.
Download manager is more on the platform side rather than front-end?
Flags: needinfo?(nchen)
This bug is more about notifications, which is front-end.
Flags: needinfo?(nchen)
Hi Jim, Would you help to give us more advice in how to differentiate the download progress updating, please? Thanks.
Flags: needinfo?(nchen)
You need a unique ID for each foreground notification [1], instead of all using `R.id.foregroundNotification`. So you need a way to map a notification to an ID. [1] http://searchfox.org/mozilla-central/rev/abe68d5dad139e376d5521ca1d4b7892e1e7f1ba/mobile/android/base/java/org/mozilla/gecko/notifications/NotificationService.java#23
Flags: needinfo?(nchen)
Tim this needs a front-end assignee
Assignee: nobody → max
tracking-fennec: ? → 54+
I think it's too late for 54.
tracking-fennec: 54+ → +
Priority: -- → P1
This is an assigned P1 bug without activity in two weeks. If you intend to continue working on this bug for the current release/iteration/sprint, remove the 'stale-bug' keyword. Otherwise we'll reset the priority of the bug back to '--' on Monday, August 28th.
Keywords: stale-bug
Max, do you have plans to work on this?
Max, or Tim, is this still on your radar? It's been a regression since 52 or so. If we can fix it by 59 then it will be in the new version of ESR.
Flags: needinfo?(timdream)
I am no longer being assiged to Fennec.
Flags: needinfo?(timdream)
Assignee: max → nobody
Flags: needinfo?(max)
[triage] non-critical.
Priority: P1 → P3
Assignee: nobody → jh+bugzilla
Comment on attachment 8957953 [details] Bug 1358598 - Show ongoing notifications even if they're not the "official" foreground notification. https://reviewboard.mozilla.org/r/226872/#review232642 Ideally we would map each ongoing notification to an ID that can be used with setForegroundNotification (so we have multiple foreground notifications), but this is okay.
Attachment #8957953 - Flags: review?(nchen) → review+
Pushed by mozilla@buttercookie.de: https://hg.mozilla.org/integration/autoland/rev/689a0e5ce54d Show ongoing notifications even if they're not the "official" foreground notification. r=jchen
Comment on attachment 8957953 [details] Bug 1358598 - Show ongoing notifications even if they're not the "official" foreground notification. https://reviewboard.mozilla.org/r/226872/#review232642 As far as I can tell from searching around and looking at the framework sources, a service can have only one associated foreground notification, i.e. a call to `setForeground()` from the service will replace the previous notification, so we still need the current system of notifying the service only - when we start requiring a foreground notification - when we no longer require a foreground notification - when we need to replace the current foreground notification because the old one is going away I think we could get rid of the hardcoded ID, though, by simply passing the desired notification name to the service as an additional intent extra.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 61
Blocks: 1445149
Comment on attachment 8957953 [details] Bug 1358598 - Show ongoing notifications even if they're not the "official" foreground notification. Approval Request Comment [Feature/Bug causing the regression]: Bug 1304145 [User impact if declined]: We show only one download notification even if multiple downloads are running. [Is this code covered by automated tests?]: No. [Has the fix been verified in Nightly?]: Tested locally. [Needs manual test from QE? If yes, steps to reproduce]: No. [List of other uplifts needed for the feature/fix]: None. [Is the change risky?]: No. [Why is the change risky/not risky?]: We already handled those additional ongoing notifications, but until now we simply didn't pass them on to the OS if we already had a designated foreground notification. [String changes made/needed]: none
Attachment #8957953 - Flags: approval-mozilla-beta?
(In reply to Jan Henning [:JanH] from comment #20) > [Is this code covered by automated tests?]: No. > [Has the fix been verified in Nightly?]: Tested locally. > [Needs manual test from QE? If yes, steps to reproduce]: No. Mind providing STR anyway?
Flags: needinfo?(jh+bugzilla)
Just start multiple file downloads (preferably bigger files, so that they'll definitively run in parallel).
Flags: needinfo?(jh+bugzilla)
Comment on attachment 8957953 [details] Bug 1358598 - Show ongoing notifications even if they're not the "official" foreground notification. fennec notifications fix, for 60.0b5
Attachment #8957953 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Verified as fixed: build 60.0b5. Device: Samsung Galaxy Tab S3 (Android 7.0) and Nexus 6(Android 6.0.1). Screenshot: https://i.imgur.com/2n0aRkn.png.
Verified as fixed on latest Nightly build (61.0a1 - 04.17). Device: Motorola Nexus 6(Android 7.1.1).
Status: RESOLVED → VERIFIED
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: