Closed Bug 997924 Opened 6 years ago Closed 6 years ago

[B2G]SMS notification is not received while the device is locked if it was locked while viewing the SMS thread

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

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

RESOLVED FIXED
2.0 S1 (9may)
blocking-b2g 1.3T+
Tracking Status
b2g-v1.3T --- verified
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: astole, Assigned: etienne)

References

Details

(Keywords: regression)

Attachments

(2 files)

10.00 KB, text/plain
Details
46 bytes, text/x-github-pull-request
alive
: review+
rik
: review+
Details | Review
Attached file logcat
If the device is locked while viewing a SMS thread, there will be no notification if a SMS is received from the same number attached to the thread. The phone vibrates, but does not make any sound.

Repro Steps:
1) Update a Buri to BuildID: 20140417040206
2) Send a SMS to the DUT
3) View the message and lock the device while the thread is open
4) Send another SMS to the DUT from the same device used in step 2

Actual:
There is no notification received

Expected:
There is a notification received

1.5 Environmental Variables:
Device: Buri 1.5 MOZ
BuildID: 20140417040206
Gaia: dadf0e60a6421f5b57ee9fc536c6617212805c19
Gecko: c55dfb01a027
Version: 31.0a1
Firmware Version: V1.2-device.cfg

Repro frequency: 3/3, 100%
See attached: logcat
This issue does not occur on the latest 1.4

1.4 Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140417000204
Gaia: 00a9d55a3e7463cecfb5dde185c0ee1f4c4d9e54
Gecko: d3d40652aaa2
Version: 30.0a2
Firmware Version: V1.2-device.cfg
blocking-b2g: --- → 2.0?
Component: Gaia::System::Window Mgmt → Gaia::System
QA Contact: jzimbrick
ni? julien/steve
Flags: needinfo?(schung)
Flags: needinfo?(felash)
Yes, I think the document.hidden property lies to us in that case. I think we have another bug that has the same cause, but didn't dig more than this yet.
Flags: needinfo?(felash)
Like julien said, it should be a issue in document.hidden that the value still be false even the device is locked. Just note that 4/10 master build could not reproduce this issue.
Flags: needinfo?(schung)
b2g-inbound Regression Window:

Last Working Environmental Variables: 
Device: Buri
BuildID: 20140415002702
Gaia: 5576f4568618f4a57b887910fb2c6f00ea9d0d08
Gecko: acfc8089f7a2
Version: 31.0a1
Base Image: V1.2-device.cfg

First Broken Environmental Variables: 
Device: Buri
BuildID: 20140415004202
Gaia: 7afce8a6e965a45f38988227828ccdfb315394f3
Gecko: 4f9f1be9e587
Version: 31.0a1
Base Image: V1.2-device.cfg

Last Working Gaia / First Broken Gecko: Issue does NOT occur.
Gaia: 5576f4568618f4a57b887910fb2c6f00ea9d0d08
Gecko: 4f9f1be9e587

First Broken Gaia / Last Working Gecko: Issue DOES occur.
Gaia: 7afce8a6e965a45f38988227828ccdfb315394f3
Gecko: acfc8089f7a2

Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/5576f4568618f4a57b887910fb2c6f00ea9d0d08...7afce8a6e965a45f38988227828ccdfb315394f3
Does this reproduce on a Tarako device?

Caused by bug 990003.
Blocks: 990003
Keywords: qawanted
This issue does reproduce on a Tarako device running the latest 1.3T build.

Environmental Variables:
Device: Tarako
BuildID: 20140418071327
Gaia: d185c05756e4bf366b1d9ac0c025909212c39f66
Gecko: cc89df9f6f30
Version: 28.1
Base Image: SP682la-4-18
Keywords: qawanted
blocking-b2g: 2.0? → 1.3T?
Is it the same as bug 995907?
James, I don't think so, bug 995907 was filed before bug 990003 landed.

This looks strange that bug 990003 provoked this... Can we try to reproduce on a 1.4 build, to have another proof?
Keywords: qawanted
Etienne, any clue?
Flags: needinfo?(etienne)
(In reply to Julien Wajsberg [:julienw] from comment #9)
> James, I don't think so, bug 995907 was filed before bug 990003 landed.
> 
> This looks strange that bug 990003 provoked this... Can we try to reproduce
> on a 1.4 build, to have another proof?

1.4 was already tested here - doesn't reproduce on 1.4.
Keywords: qawanted
Right, so yes, bug 990003 is very likely the culprit here. We'll need Etienne!
Component: Gaia::System → Gaia::SMS
blocking-b2g: 1.3T? → 1.3T+
Back to system component because the change in the System app in bug 990003 triggered this bug.
Component: Gaia::SMS → Gaia::System
Ok got it. We're not hiding the window because the preloaded callscreen must have an audio channel opened [1].
Working on a patch.

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/visibility_manager.js#L65-75
Assignee: nobody → etienne
Flags: needinfo?(etienne)
Attached file Gaia PR
Attachment #8410176 - Flags: review?(anthony)
Attachment #8410176 - Flags: review?(alive)
Attachment #8410176 - Flags: review?(alive) → review+
Comment on attachment 8410176 [details] [review]
Gaia PR

One of the unit test is to update, see PR.
Attachment #8410176 - Flags: review?(anthony) → review-
Comment on attachment 8410176 [details] [review]
Gaia PR

test udpated.
Attachment #8410176 - Flags: review- → review?(anthony)
Attachment #8410176 - Flags: review?(anthony) → review+
Hi! James,

Check in needed. Thanks

--
Keven
Flags: needinfo?(james.zhang)
Keywords: checkin-needed
(In reply to Keven Kuo [:kkuo] from comment #18)
> Hi! James,
> 
> Check in needed. Thanks
> 
> --
> Keven

It's on master, I need v1.3t.
Flags: needinfo?(james.zhang)
Apparently this got merged on master (hope travis was green), so resolved fix.

https://github.com/mozilla-b2g/gaia/commit/c0e3264cf1e57d2da3ce201554b620bd3cf01d24
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Please land it on v1.3t.
Flags: needinfo?(ying.xu)
Flags: needinfo?(yang.zhao)
James, it will eventually go to 1.3+ once the people in charge of uplifts will do it today. No worry.
Flags: needinfo?(ying.xu)
Flags: needinfo?(yang.zhao)
hi James, your team is also granted permission to do 1.3T gaia uplifts. Can your team simply does the uplift? and once you have done this, change the status1.3T to fixed. thanks
Flags: needinfo?(james.zhang)
Already done.
commit id:94de493682d56f22f25ecadd6434bd4f2555e643
Duplicate of this bug: 999318
Keywords: checkin-needed
Target Milestone: --- → 2.0 S1 (9may)
(In reply to yang.zhao from comment #25)
> Already done.
> commit id:94de493682d56f22f25ecadd6434bd4f2555e643

land.
Flags: needinfo?(james.zhang)
I'm sorry to be dense here, why isn't it possible to wait for the sheriff to do the uplift? I'm afraid of introducing bugs when someone that didn't write the patch tries to uplift to a branch in some code that he doesn't know, especially if there are conflicts (and I see there were some conflicts here).

For example, we can see that the uplift was not done using "-x", so we don't have the direct reference to the uplifted commit.
Duplicate of this bug: 999563
Verified as fixed in today's build

1.3t Environmental Variables:
Device: Tarako 1.3t
BuildID: 20140428014001
Gaia: 8895b180ed636069473703d0e7b73086989601ce
Gecko: 7caf4b5abfce
Version: 28.1
Firmware Version: sp6821
You need to log in before you can comment on or make changes to this bug.