Closed Bug 977593 Opened 10 years ago Closed 10 years ago

[zffos1.3][P3](Local) The notification of new voicemail message is deleted once is read.

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia::System
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-b2g:1.3+, b2g-v1.3 fixed, b2g-v1.3T fixed, b2g-v1.4 fixed)

Status:
RESOLVED FIXED
Milestone:
1.4 S3 (14mar)
Project Flags:
blocking-b2g 1.3+
Tracking Flags:
Tracking Status
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed

People

(Reporter: fang.chen1, Assigned: gerard-majax)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [systemsfe] [p=1]) 

User Agent: Mozilla/5.0 (Windows NT 6.1; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; TCO_20140227092630; rv:11.0) like Gecko

Steps to reproduce:

    A.- Overview Description (technical background, concise explanation of the bug):
    The notification of new voicemail message is deleted once is read.
    
    ________________________________________________________________________________
    B.- Steps to Reproduce (initial conditions, required resources, step by step instructions to reproduce):
    1- Leave a voice messages on voice mailbox of the DuT.
2- The notification is displayed on the screen.


Actual results:

After reading the notification of new voicemail message, it is automatically deleted.


Expected results:

The voice message notification should disappear when listening the message and this is deleted or saved.
Built ID :20140218180032
OS version
1.3.0.0-prerelease
QC RIL commit:
a406d321  Add null check when handling set preferred network type
QC RIL TAG version: AU_LINUX_GECKO_B2G_JB_3.2.01.03.00.112.223

gaia commit:
744fb691 Merge pull request #15526 from steveck-chung/bug-961231

gecko commit:
6840e8c2 Bumping gaia.json for 1 gaia-1_3 revision(s) a=gaia-bump
FangChen, I think this is a dupe of bug 910999. Please check you had that part of the code in your build.
Flags: needinfo?(fang.chen1)
(In reply to Beatriz Rodríguez [:brg] from comment #2)
> FangChen, I think this is a dupe of bug 910999. Please check you had that
> part of the code in your build.

Except for the fact that this was fixed in early in January, but the build ID here is shown to be on 2/18.

Can someone check if they can reproduce this on the Moz side?
Keywords: qawanted, regression
Flags: needinfo?(fang.chen1)
Issue reproduces on the latest Buri v 1.3.0 Mozilla RIL

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140310004001
Gaia: 78c30d7ed6f6e30337d6c05453b867f5e97e42bc
Gecko: 00f249d54bda
Version: 28.0
Firmware Version: v1.2-device.cfg

I left 5 voicemails on the device. The notification was deleted after listening to the first voicemail.
Keywords: qawanted
Could not reproduce on the latest Buri v 1.4.0 Mozilla RIL.

Device: Buri 1.4 MOZ
BuildID: 20140310080111
Gaia: 8c9191df3c107df4073f3ca63816a1d36c51af5d
Gecko: 923f1411f42f
Version: 30.0a1
Firmware Version: v1.2-device.cfg

I left 5 voicemails on the device. The voicemail notification decreased by 1 each time after listening to a voicemail and then checking the notification. The notification was not deleted until all messages were listened to.
I think this might be something we fixed in 1.4 timeframe with the changes of how we persist notifications.

Mike - Can you confirm? Or is there something we tried to do here in the 1.3 timeframe to address this bug?
Flags: needinfo?(mhenretty)
(In reply to Jason Smith [:jsmith] from comment #6)
> I think this might be something we fixed in 1.4 timeframe with the changes
> of how we persist notifications.
> 
> Mike - Can you confirm? Or is there something we tried to do here in the 1.3
> timeframe to address this bug?

AFAIK, there is nothing we did in the 1.3 timeframe (besides bug 910999) to address this bug. Also, there is nothing we did in 1.4 to specifically fix this regression. But there are a couple of changes we made to notifications in 1.4 that could have fixed this as a side effect. Bug 935094 changed the way we do notification replacement, which seems like a likely candidate. Unfortunately, I don't know much more than that.
Flags: needinfo?(mhenretty)
This is a followup to a cert blocker for 1.3 (see https://bugzilla.mozilla.org/show_bug.cgi?id=910999#c17 for context), so this needs to block.
blocking-b2g: --- → 1.3?
Component: Gaia::SMS → Gaia::System
Whiteboard: [systemsfe]
Blocks: 910999
blocking-b2g: 1.3? → 1.3+
Assignee: nobody → lissyx+mozillians
(In reply to FangChen from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 6.1; Trident/7.0; SLCC2; .NET CLR
> 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0;
> .NET4.0C; .NET4.0E; TCO_20140227092630; rv:11.0) like Gecko
> 
> Steps to reproduce:
> 
>     A.- Overview Description (technical background, concise explanation of
> the bug):
>     The notification of new voicemail message is deleted once is read.
>     
>    
> _____________________________________________________________________________
> ___
>     B.- Steps to Reproduce (initial conditions, required resources, step by
> step instructions to reproduce):
>     1- Leave a voice messages on voice mailbox of the DuT.
> 2- The notification is displayed on the screen.
> 
> 
> Actual results:
> 
> After reading the notification of new voicemail message, it is automatically
> deleted.
> 
> 
> Expected results:
> 
> The voice message notification should disappear when listening the message
> and this is deleted or saved.

Can we get verbose logcat with RIL debug enabled ?

The Gaia code is expected to only react on events and the presence of messages: https://github.com/mozilla-b2g/gaia/blob/744fb691c2b2a25a07c5d19fabf5748ae9aba4d9/apps/system/js/voicemail.js#L71
Flags: needinfo?(fang.chen1)
I clearly confirm the issue on Buri running 1.3 :(
I think this is because we do not have bug 890440 on 1.3
I'm also seeing manifestations of bug 963130 on 1.3
I can confirm that adding the following commits fixes the issue on 1.3:
 - bug 963035
 - bug 963130
 - bug 890440

None of those have been marked as 1.3+.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(fang.chen1)
Keywords: regression, regressionwindow-wanted
Depends on: 963035, 963130, 890440
Removing all dependencies - the 1.3 fix that was being asked for here needs to align with the original approach used in bug 910999, as trying to resolve the dependencies needed here on 1.3 is far too risky. This was working post landing of bug 910999, so something must have regressed here after that landing.

Let's backup here & understand what regressed here after bug 910999 & use that to implement a 1.3-specific fix.
No longer depends on: 890440, 963035, 963130
(In reply to Jason Smith [:jsmith] from comment #14)
> Removing all dependencies - the 1.3 fix that was being asked for here needs
> to align with the original approach used in bug 910999, as trying to resolve
> the dependencies needed here on 1.3 is far too risky. This was working post
> landing of bug 910999, so something must have regressed here after that
> landing.
> 
> Let's backup here & understand what regressed here after bug 910999 & use
> that to implement a 1.3-specific fix.

bug 963035 and bug 963130 fixes critical behavior of the new Notification API. They should have been in gecko 28, but I only noticed they were lacking right now, maybe my fault for not being careful enough.

About bug 910999, I see a QA verification regarding 1.4 only. 1.3 uplift for this one specifically has been done, but no further QA. So I'm highly doubtful we ever correctly fixed this in 1.3.
For clarification, the current behavior observed that I checked on v1.3 on my Buri totally agrees with the lack of bug 890440: the notification is dismissed as soon as it is being tapped.
Okay - let's wait for a window here. That will determine if this ever worked on 1.3 or not.
Btw - for bug 963035 & bug 963130 - if you think those issues are critical for the notifications API on 1.3, then feel free to nom them for the notifications API need.
QA Contact: mvaughan
I agree with Alexandre, bug 890440 needs to be uplifted to fix this. However, doing this uplift will expose v1.3 to several other bugs which should be uplifted as well:

https://bugzilla.mozilla.org/show_bug.cgi?id=956276
https://bugzilla.mozilla.org/show_bug.cgi?id=963035
https://bugzilla.mozilla.org/show_bug.cgi?id=963130
Depends on: 890440
I'd still like an understanding of whether the patch in bug 910999 ever worked on 1.3. If it did, then we should fix this contextually based on what regressed. If it never worked, then let's consider other options here.
Switching to QA Wanted to see if this ever worked at all on 1.3 (i.e. test to see if this reproduces on a 1/8/2014 build).
Keywords: regressionwindow-wanted → qawanted
These (In reply to Michael Henretty [:mhenretty] from comment #19)
> I agree with Alexandre, bug 890440 needs to be uplifted to fix this.
> However, doing this uplift will expose v1.3 to several other bugs which
> should be uplifted as well:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=956276
> https://bugzilla.mozilla.org/show_bug.cgi?id=963035
> https://bugzilla.mozilla.org/show_bug.cgi?id=963130
> https://bugzilla.mozilla.org/show_bug.cgi?id=962977

These are actual blockers since without them tests will break on travis for the 1.3 uplift of bug 890440.
Depends on: 962977, 963130, 963035
In the 01/08/14 (and 03/13/14) 1.3 build, if I dial into my voicemail through the dialer and *don't* tap on the "new voicemail" notification, the amount of new voicemails will be tracked as I listen to them. Once I listen to all the new voicemails, the "new voicemail" notification will disappear. 
	
However if I *do* tap the "new voicemail" notification, the notification will disappear and dial into my voicemail. The notification will never appear again even if I don't listen to all my new voicemails. This contradicts 1.4 where I can tap on the "new voicemail" notification as much as I want and it will not disappear until I finish listening to all my new voicemails. It will also keep track of how many new voicemails I have as I listen to them.
Keywords: qawanted
Matthew, could you please retest when all the uplifted work from comment 23 is done in 1.3 and provide feedback?
Flags: needinfo?(mvaughan)
Keywords: qawanted
(In reply to Beatriz Rodríguez [:brg] from comment #25)
> Matthew, could you please retest when all the uplifted work from comment 23
> is done in 1.3 and provide feedback?

After testing on the 03/14/14 1.3 build, I've found that this works the same as the 1.4 build. 

If I tap on the "new voicemail" notification, I will be dialed into my voicemail and the notification will *not* disappear. Therefore I can tap on it as much as I want and it will only disappear once I have finished listening to all my voicemails. Additionally, the notification will update with how many new voicemails I have so I will know how many I have left if I didn't actually hear them all.
Flags: needinfo?(mvaughan)
Keywords: qawanted
Resolved with uplifts of blocking bugs.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
status-b2g-v1.3T: --- → fixed
Target Milestone: --- → 1.4 S3 (14mar)
Does someone give one patch about how to fix this issue on v1.3? Thanks.
(In reply to chencong from comment #28)
> Does someone give one patch about how to fix this issue on v1.3? Thanks.

This issue was fixed by uplifting the pathes from the bugs that this bug depends on.
Whiteboard: [systemsfe] → [systemsfe] [p=1]
Flags: in-moztrap?
URL: https://moztrap.mozilla.org/manage/ca...
Flags: in-moztrap? → in-moztrap+
You need to log in before you can comment on or make changes to this bug.