Incoming call while not screen locked presents the lockscreen incoming call screen

RESOLVED FIXED in B2G C2 (20nov-10dec)


Firefox OS
5 years ago
5 years ago


(Reporter: m1, Assigned: yurenju)



B2G C2 (20nov-10dec)
Gonk (Firefox OS)

Firefox Tracking Flags



(Whiteboard: [LOE:S])


(1 attachment)

Call the device when not locked and observe that the lockscreen incoming call screen is displayed instead.   

It seems like toggling the lockscreen from settings can get the device back into a state where the normal incoming call appears consistently until the next reboot.
Hi Michael,

I can't reproduce it, could you try again in last build?

Comment 2

5 years ago
I'm unable to reproduce this as well.  What build are you on?

Comment 3

5 years ago
I'm on the tip of beta/nightly.


The situation has improved overnight but still not resolved.  The behavior I now see is that the first time an incoming call is received upon boot regardless of whether or not phone log is active presents the lock screen incoming call screen.  2nd call usually works.
I can reproduce this.
The key here is that the incoming call has to launch the dialer app.  If it's already running, then we show the right incoming-call screen when the phone is unlocked.  So STR

 (1) Unlock lockscreen
 (2) Ensure dialer app is not running (kill in task manager if running)
 (3) Call b2g phone, ensuring screen stays unlocked

If the new incoming-call screen with the loopy curve shows up, you're seeing this bug.

Yuren, can you take this?
Assignee: nobody → yurenju
This bug also reproduces with latest gaia and gecko (m-c).
blocking-basecamp: ? → +
Keywords: regression
Priority: -- → P2

Comment 8

5 years ago
Do we have an update here Yuren?
Priority: P2 → P1
Target Milestone: --- → B2G C2 (20nov-10dec)
Looks the same behaviour before new lockscreen for dialer commit. working on it.
Whiteboard: [LOE:S]
Created attachment 686995 [details]
pull request

oncall.html doesn't get screenState yet on first time launch.

Etienne, could you please review it? thank you!
Attachment #686995 - Flags: review?(etienne)
Comment on attachment 686995 [details]
pull request

I don't think this is the right approach.

Basically what happens here is: after the first call (when you do the `Settings.observe`) the dialer will open the call screen every time the screen is locked or unlocked! (and close it subsequently because there are no calls).

Here is a suggestion:
* Keep the `SettingsListener.observe` call at the same place than before
* Initialize `screenState` to null
* Pass a null default value to the `SettingsListener.observe`

* When opening the call screen if `screenState` is truthy, open it right away
* If not, we didn't get the correct `screenState` value yet, you can query for the `lockscreen.locked` setting  directly (without adding an observer since we already have one) and then open the call screen in the onsuccess callback of the request. (the mozSetting API will return a DOMRequest when getting the setting value)
* Probably safer to still open the callscreen with a default state value in the onerror callback, error happen.
Attachment #686995 - Flags: review?(etienne) → review-
Comment on attachment 686995 [details]
pull request

Hi Etienne, pull request updated, could you review again? thanks.
Attachment #686995 - Flags: review- → review?(etienne)
Comment on attachment 686995 [details]
pull request

r=me with the comments on github addressed

Attachment #686995 - Flags: review?(etienne) → review+
Fixed with comments suggestion and merged, thank you all!
Last Resolved: 5 years ago
Resolution: --- → FIXED

Comment 15

5 years ago
Reviewed and verified on "Unagi"
Incoming call no longer shows locking display on the unlocked screen
You need to log in before you can comment on or make changes to this bug.