Closed Bug 1017333 Opened 9 years ago Closed 8 years ago
[B2G] [Notification] Missed call notification does not disappear after being tapped if a voicemail notification is also present
Description: Tapping a missed call notification while a new voicemail notification is present does not cause the notification to be removed from the notification list. The user is still sent to the call log. Repro Steps: 1) Update Flame to Build ID: 20140527040202 2) Receive a phone call and ignore it until the call is sent to voicemail. 3) On the other device, leave a voice message for the test device. 4) Open the notification page and tap the missed call notification. 5) After the call log appears, open the notification page again. 6) Observe the notifications that are shown. Actual: The notification for the call that was just tapped is still present. Expected: The notification for the call that was just tapped is no longer present. Environmental Variables Device: Flame 2.0 Build ID: 20140527040202 Gecko: https://hg.mozilla.org/mozilla-central/rev/cbe4f69c2e9c Gaia: 6a391274cd436f8f0d1fad2db8c6b4805703259c Platform Version: 32.0a1 Firmware Version: v10G-2 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Notes: Repro frequency: 100% Link to failed test case: https://moztrap.mozilla.org/manage/cases/?filter-id=2194 See attached video clip and logcat
Does not repro on Flame 1.4 Build ID: 20140527000202 Gecko: https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/d583ae109f54 Gaia: 0542778892a294d224e75af4a76be5d42938bc90 Platform Version: 30.0 Firmware Version: V10g-2 User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
Okay, this remind me of another strange bug I have been reproducing sometimes on my Nexus S. Following your steps, I reproduce but it seems to fall under the case of this old bug. Can you try to let the call log load, the switch to dialer, wait a couple of seconds, and then switch back to call log? If this is the bug I suspect, it will at some point remove the missed call notification, and it has nothing to do with the voicemail.
When I switched to the call log from the dialer page, the missed call notifications were removed.
(In reply to ckreinbring from comment #3) > When I switched to the call log from the dialer page, the missed call > notifications were removed. Perfect, this is exactly what I was describing. As far as I remember, the Notification.get().close() code is called at some point when displaying the call log. Seems like we are missing one case here then.
Component: Gaia::System → Gaia::Dialer
Mozilla Inbound Regression Window: Last Working build Environmental Variables: Device: Flame Build ID: 20140510163004 Gaia: c1a8cbaac1d921cfb50e3a2600720b75cf5afabd Gecko: 24ff9dbc3f20 Version: 32.0a1 (2.0) MOZ Firmware Version: v10G-2 First Broken Build Environmental Variables: Device: Flame Build ID: 20140511043004 Gaia: c1a8cbaac1d921cfb50e3a2600720b75cf5afabd Gecko: 77b1f329c174 Version: 32.0a1 (2.0) MOZ Firmware Version: v10G-2 Last Working Gaia and first broken gecko Issue DOES NOT occur here. Gaia: c1a8cbaac1d921cfb50e3a2600720b75cf5afabd Gecko: 77b1f329c174 Last Working Gecko and first broken gaia Issue DOES occur here. Gaia: c1a8cbaac1d921cfb50e3a2600720b75cf5afabd Gecko: 24ff9dbc3f20 Gecko Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=24ff9dbc3f20&tochange=77b1f329c174
Push log isn't right. This is a Gaia regression, so there should be a Gaia push log, not a Gecko push log.
B2G Inbound Regression Window: Last Working: Environmental Variables: Device: Flame Build ID: 20140512053003 Gaia: a4fd33ae51aa1e84648f859c9802dc76f04e46dd Gecko: 5345d6aa6a81 Version: 32.0a1 (2.0) MOZ Firmware Version: v10G-2 First Broken: Environmental Variables: Device: Flame Build ID: 20140512083002 Gaia: ae15cfb697cc9127f9b909a5ba911186157f617c Gecko: 5fe96f1a1b5a Version: 32.0a1 (2.0) MOZ Firmware Version: v10G-2 Last Working Gecko and First broken gaia Issue DOES occur here. Gaia: ae15cfb697cc9127f9b909a5ba911186157f617c Gecko: 5345d6aa6a81 Last Working Gaia and First broken gecko Issue DOES NOT occur here. Gaia: a4fd33ae51aa1e84648f859c9802dc76f04e46dd Gecko: 5fe96f1a1b5a Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/a4fd33ae51aa1e84648f859c9802dc76f04e46dd...ae15cfb697cc9127f9b909a5ba911186157f617c
This is caused by either bug 992915 or bug 1005802. Will wait for Etienne to chime in here on which bug is the cause.
(In reply to Jason Smith [:jsmith] from comment #8) > This is caused by either bug 992915 or bug 1005802. > > Will wait for Etienne to chime in here on which bug is the cause. I really don't see how any of these css only patches could have caused the issue... I think we're just missing a CallLog.cleanNotifications() call somewhere, but I'm not setup to test it right now. Lissyx can you have a quick look? CallLog.becomeActive() should be trigger and clean the notifications.
Flags: needinfo?(etienne) → needinfo?(lissyx+mozillians)
(In reply to Jason Smith [:jsmith] from comment #6) > Push log isn't right. This is a Gaia regression, so there should be a Gaia > push log, not a Gecko push log. I think we had some racing issues with the notification persistence code in gecko at some point, maybe we shouldn't rule out a gecko bug completely.
For some reason I do not get missed call notification anymore on current master :(
Assignee: nobody → anthony
Target Milestone: --- → 2.0 S4 (20june)
Anthony should we move this to next sprint or do you think you'll have time for this? Thanks!
I'm looking into it.
We are cleaning the notifications in becameVisible(). We are calling becameVisible() either when we are displayed or when we do CallLog.init() more than once. We are not initiated a second time. And we are listening for visibilitychange events but we don't receive them (and we shouldn't). I need to find what changed so that becameVisible is not called anymore.
This is the typical bug where I don't know why it ever worked before and I don't know why it broke either. I have a fix but writing the tests for it might take a bit of time since there are not a lot of paths tested yet.
This fixes the original bug also another one with the following STR: 1) Open call log 2) Switch to keypad view 3) Go to homescreen 4) Receive a call and let it ring 5) Reopen the dialer app Expected result: Dialer is on keypad view and missed call notification is still present Actual result: Dialer is on keypad view and missed call notification is gone
Attachment #8442248 - Flags: review?(etienne)
Comment on attachment 8442248 [details] [review] https://github.com/mozilla-b2g/gaia/pull/20701 r=me with the comment on github addressed/fixed.
Attachment #8442248 - Flags: review?(etienne) → review+
I'll lan this on Monday with the nit addressed.
Whiteboard: [2.0-flame-test-run-1] → [2.0-flame-test-run-1], [2.0-flame-test-run-2]
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Just reverted my stupid action: https://github.com/mozilla-b2g/gaia/commit/a9ca62222a0458c915fcd92b3b7601b93e5c2b69 This still needs to take a look from Anthony to add Etienne's comments. I should be punished and invite for beers.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I've moved the hash setup into the suite setup() (in order to make sure the first test has the hash set) Landed in https://github.com/mozilla-b2g/gaia/commit/d78b85cf8e92b97deca86717f57a40096069ee6f. I forgot to add r=etienne in the commit message, sorry.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → FIXED
QA Whiteboard: [fxosqa-auto-backlog?]
QA Whiteboard: [fxosqa-auto-backlog?] → [fxosqa-auto-backlog+]
Clearing backlog tag as bug 1109606 was created (and fixed).
QA Whiteboard: [fxosqa-auto-backlog+]
You need to log in before you can comment on or make changes to this bug.