Closed
Bug 810738
Opened 12 years ago
Closed 12 years ago
Gaia turns off the screen during incoming call
Categories
(Firefox OS Graveyard :: Gaia::System, defect, P1)
Firefox OS Graveyard
Gaia::System
Tracking
(blocking-basecamp:+)
People
(Reporter: timdream, Assigned: rexboy)
References
Details
(Keywords: regression)
Attachments
(1 file)
Steps to reproduce: 1) Power on the device and set it down 2) Wait for lock screen to appear and let he screen time out 3) Call the device 4) Incoming call screen appears for a couple seconds. Don't touch the phone 5) Screen turns off 6) Incoming call continues to ring with the screen off Note: this is likely a regression from the dependency bugs. Let's clarify the three way dance between attention screen/dialer app/screen manager in this bug and make sure bad things doesn't happen again.
Reporter | ||
Comment 1•12 years ago
|
||
chiajung, Do you have extra cycles to continue working on what we did in bug 804890?
Updated•12 years ago
|
Assignee: nobody → 21
Comment 2•12 years ago
|
||
Milestoning for C2 (deadline of 12/10), as this meets the criteria of "remaining P1 bugs not already milestoned for C1".
Target Milestone: --- → B2G C2 (20nov-10dec)
is this a dup of bug 804707? Can you check to see if the 3rd ring shows the call screen?
Comment 4•12 years ago
|
||
tim, I think I have to focus on gecko issue for now, but please feel free to discuss with me by mail, IRC or discuss on this thread. I will follow this issue.
Reporter | ||
Comment 5•12 years ago
|
||
Rex, Steve, KM, can any of you guys take this?
Comment 6•12 years ago
|
||
Tim, I think this problem may be wakelock related. I think we should somehow gather up the screen on/off related API as mentioned before. Since to use wakelock to imply whether to observe user interaction is not that good. Do you think we should let screen_manager.turnScreenOn has the right to decide whether to observer user interaction? For example: // If !canIdle => we should not turn the screen off automatically, but wait for a explicit off .turnScreenOn(instant, canIdle) { if (canIdle) configTimeout(); else return; } then let attention_screen or dialer calls to these APIs rather than handle the wakelock.
Reporter | ||
Updated•12 years ago
|
Assignee: 21 → yurenju
Assignee | ||
Comment 8•12 years ago
|
||
Patch here. I stop idle timeouts which try to turn off screen during wake-lock is acquired.
Attachment #682315 -
Flags: review?(timdream+bugs)
Reporter | ||
Comment 9•12 years ago
|
||
Comment on attachment 682315 [details] Fix to bug 810738 . Rex told me the cause of the bug and we would like to try another approach. Rex, please reset the r? to me when you done, thanks!
Attachment #682315 -
Flags: review?(timdream+bugs)
isn't this a dup of bug 805955?
Assignee | ||
Comment 11•12 years ago
|
||
I'm trying to fix it but found some issue. Although the screen can be turned off during the call now, it seems that I bumped into bug 811459 so that the screen won't be turned off when it becomes idle again even though the idle observer is correctly registered. (In detail, the onidle/onactive is called repeatedly just after idle observer is registered, which is not an excepted behavior. The callback timer set in onidle is thus instantly canceled by onactive. Also logcat is overfilled with these events.)
Assignee | ||
Comment 12•12 years ago
|
||
Oops, I mean "Although the screen will not be turned off during the call now". Sorry.
Assignee | ||
Comment 13•12 years ago
|
||
Comment on attachment 682315 [details] Fix to bug 810738 . Since the bug 811459 about idle service is fixed, I tested my patch and now it works on aurora 11/19 114289:8e00ce1788c7 (hg changeset). I've updated the new patch to the pull request attached above.
Attachment #682315 -
Flags: review?(timdream+bugs)
Reporter | ||
Comment 14•12 years ago
|
||
Comment on attachment 682315 [details] Fix to bug 810738 . r=me, if everything I said survive testing. Thank you for locate the regression and document it in this bug. I didn't aware of that.
Attachment #682315 -
Flags: review?(timdream+bugs) → review+
Assignee | ||
Comment 15•12 years ago
|
||
Comment on attachment 682315 [details] Fix to bug 810738 . The code on PR has been updated according to the comment and tested on Aurora. Thank you, Tim!
Assignee | ||
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•