Closed Bug 1000299 Opened 6 years ago Closed 6 years ago

[B2G][Tarako][Dialer] Intermittently the missed call logs are not being updating with missed calls

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:1.3T+, b2g-v1.3 unaffected, b2g-v1.3T verified)

VERIFIED FIXED
2.0 S1 (9may)
blocking-b2g 1.3T+
Tracking Status
b2g-v1.3 --- unaffected
b2g-v1.3T --- verified

People

(Reporter: jschmitt, Assigned: etienne)

References

Details

(Whiteboard: [partner-blocker][sprd302769])

Attachments

(2 files, 1 obsolete file)

Attached video Call_log.mpeg
Description:
Call logs are not being updated with phone calls

Repro Steps:
1) Update a Tarako to BuildID: 20140423014003
2) Proceed to the Homescreen
3) From another device call the test device
4) Decline the call
5) Open the Dailer app
6) Select the 'phone' icon bottom left
7) Select either 'All' or 'Missed' tab

Actual:
The call logs are not being updated.

Expected:
The phone calls be logged in the call log.

1.3t Environmental Variables:
Device: Tarako 1.3t
BuildID: 20140423014003
Gaia: 9aa9b04049f0291b124c50e0f9c3ce0e1f547725
Gecko: 5dc3e5ec4178
Version: 28.1
Firmware Version: sp6821

Notes:
Repro frequency: 100%
See attached: Video
Issue does not repro on 1.3

1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140422024003
Gaia: cab7de82832d00696807ae48ec277bd642b82a0a
Gecko: c35695cc384c
Version: 28.0
Firmware Version: v1.2-device.cfg
The repro rate appears to not be 100% after I continued to investigate further. The repro rate is around 40% Removing Smoketest keyword.
Keywords: smoketest
Summary: [B2G][Dialer] Call logs are not updating when connecting or missing a call → [B2G][Tarako][Dialer] Call logs are not updating when connecting or missing a call
Summary: [B2G][Tarako][Dialer] Call logs are not updating when connecting or missing a call → [B2G][Tarako][Dialer] Intermittently the missed call logs are not being updating with missed calls
blocking-b2g: --- → 1.3T?
blocking-b2g: 1.3T? → 1.3T+
ni? Etienne/Rik
Flags: needinfo?(etienne)
Flags: needinfo?(anthony)
(In reply to Josh Schmitt from comment #2)
> The repro rate appears to not be 100% after I continued to investigate
> further. The repro rate is around 40% Removing Smoketest keyword.

AFAIK the call log is now populated by listening to a system event, if the reproduction rate is not 100% this might be caused by the dialer app being killed due to an OOM condition or something similar. Can we have a logcat taken when the issue occurred? That should tell us if the dialer died or not.
(In reply to Gabriele Svelto [:gsvelto] from comment #4)
> (In reply to Josh Schmitt from comment #2)
> > The repro rate appears to not be 100% after I continued to investigate
> > further. The repro rate is around 40% Removing Smoketest keyword.
> 
> AFAIK the call log is now populated by listening to a system event

Yes, the telephony-call-ended system message.

> if the  reproduction rate is not 100% this might be caused by the dialer app being
> killed due to an OOM condition or something similar. Can we have a logcat
> taken when the issue occurred? That should tell us if the dialer died or not.

We're not requesting the "high-priority" lock for this system message, could it be the issue?
I'll send a patch to try this out.
Flags: needinfo?(etienne)
Flags: needinfo?(anthony)
Attached patch Patch proposal (obsolete) — Splinter Review
Josh, is this patch helping?
Attachment #8411755 - Flags: feedback?(jschmitt)
(In reply to Etienne Segonzac (:etienne) from comment #6)
> Created attachment 8411755 [details] [diff] [review]
> Patch proposal
> 
> Josh, is this patch helping?

Can you put this into a github branch? That will allow Josh to test this easily.
(In reply to Etienne Segonzac (:etienne) from comment #5)
> We're not requesting the "high-priority" lock for this system message, could
> it be the issue?

Could be, background apps on Tarako tend to die like flies :)
(In reply to Jason Smith [:jsmith] from comment #7)
> (In reply to Etienne Segonzac (:etienne) from comment #6)
> > Created attachment 8411755 [details] [diff] [review]
> > Patch proposal
> > 
> > Josh, is this patch helping?
> 
> Can you put this into a github branch? That will allow Josh to test this
> easily.

Sure, here's a 1.3t rebased version of the patch
https://github.com/etiennesegonzac/gaia/tree/bug-1000299-1.3t
Assignee: nobody → etienne
Target Milestone: --- → 2.0 S1 (9may)
Keywords: qawanted
Status: NEW → ASSIGNED
Duplicate of this bug: 1001329
Whiteboard: [partner-blocker]
Whiteboard: [partner-blocker] → [partner-blocker][sprd302769]
Etienne, could we land this so more people can try? Thanks
Flags: needinfo?(etienne)
Jason, Etienne has requested qawanted in the whiteboard, could we have a qa assigned on this please ?
Flags: needinfo?(jsmith)
Flags: needinfo?(dharris)
James - Can you get someone assigned here?
Flags: needinfo?(jzimbrick)
Flags: needinfo?(jsmith)
Flags: needinfo?(dharris)
This issue is NOT occurring on a Tarako device running 1.3T with the patch from comment 9 applied.

After declining a call on the home screen a missed call notification is displayed at the top of the screen. On opening the Dialer app the missed call is shown in the call log under both the "All" and "Missed" tabs.
Flags: needinfo?(jzimbrick)
Keywords: qawanted
QA Contact: dharris → jzimbrick
Attached file Gaia PR
Here's a patch ready for review.
Attachment #8411755 - Attachment is obsolete: true
Attachment #8411755 - Flags: feedback?(jschmitt)
Attachment #8418013 - Flags: review?(gsvelto)
Flags: needinfo?(etienne)
Comment on attachment 8418013 [details] [review]
Gaia PR

Looks good to me but I'd use the existing WakeLock mock instead of rolling the small ad-hoc one you made. Then you could test the |released| field instead of spying the unlock method, that should be more robust in the face of future changes:

https://github.com/mozilla-b2g/gaia/blob/933fe64315ff7445aa619b16bf08832f9b5faaf0/shared/test/unit/mocks/mock_navigator_wake_lock.js
Attachment #8418013 - Flags: review?(gsvelto) → review+
https://github.com/mozilla-b2g/gaia/commit/24eb700fad2fb19390407f2b1b72ee42d3dc37d1

Landed with the comment addressed.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
I think it should be landed on v1.3t.
Flags: needinfo?(fabrice)
Flags: needinfo?(fabrice)
Etienne, I had some conflicts with the tests on v1.3t, so I used your branch here: https://github.com/etiennesegonzac/gaia/tree/bug-1000299-1.3t. Can you help me uplift the tests for this patch to 1.3t, or do we care?
Flags: needinfo?(etienne)
(In reply to Michael Henretty [:mhenretty] from comment #20)
> Etienne, I had some conflicts with the tests on v1.3t, so I used your branch
> here: https://github.com/etiennesegonzac/gaia/tree/bug-1000299-1.3t. Can you
> help me uplift the tests for this patch to 1.3t, or do we care?

I think we're good as long as we do not break existing tests :)
(and I've used the same approach on earlier uplifts)
Flags: needinfo?(etienne)
Triage: this is related to low memory issue. No need in v1.4.
Verified for v1.3T. I am unable to reproduce this issue on the latest v1.3T Tarako build:

v1.3T Environmental Variables:
Device: Tarako v1.3T MOZ RIL
BuildID: 20140602014001
Gaia: 335486c42498fa7a93c21e4d6121199728602ab8
Gecko: 55e4d83019e5
Version: 28.1
Firmware Version: SP6821a-Gonk-4.0-5-12
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.