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? thanks!
I'm unable to reproduce this as well. What build are you on?
I'm on the tip of beta/nightly. gaia:1087df834f985c4d01db455eb60163789499e086 gecko:af8824ac54c27bc203e0016b76b9bd63a6a44d07 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: ? → +
Priority: -- → P2
Do we have an update here Yuren?
Looks the same behaviour before new lockscreen for dialer commit. working on it.
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! https://github.com/mozilla-b2g/gaia/pull/6743
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 Thanks!
Attachment #686995 - Flags: review?(etienne) → review+
Fixed with comments suggestion and merged, thank you all!
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Reviewed and verified on "Unagi" BuildID:20130103070201 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.