Closed Bug 1024341 Opened 10 years ago Closed 10 years ago

(meta) Wake up the device after a call hangs up

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.1 affected, b2g-v2.2 fixed)

RESOLVED FIXED
2.1 S9 (21Nov)
Tracking Status
b2g-v2.1 --- affected
b2g-v2.2 --- fixed

People

(Reporter: greatwall2686, Assigned: thills)

References

Details

(Keywords: meta, Whiteboard: torch [planned-sprint][in-sprint=v2.1-S7])

Attachments

(1 file)

* Description: Device cannot wake up automatically after Call had be hang up in black screen status.. * Reproduction steps: 1. Connect a call. 2. Press HW power into black screen status. 3. Hang up the call at another device. * Expected result: Device will wake up after the call had be hang up. * Actual result: Device cannot wake up automatically. * Reproduction build:(Buri - Firefox OS V1.4 inside) - Gaia 17b102ee8d9a724b62285547cc5f1c5d30bfb01c - Gecko https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/95be84248033 - BuildID 20140520000201 - Version 30.0 * Reproduction Frequency - 100%
We don't wake up the screen when a call is hanging up, maybe we should. What do you think Carrie?
Flags: needinfo?(cawang)
I'd suggest waking up the screen for users so that they can see the call ended page. It will get back to the lockscreen when the call end page disappears. Thanks!
Flags: needinfo?(cawang)
Summary: [Flame][v1.4][Gaia::Dialer]Device cannot wake up automatically after hang up the call in black screen status. → Wake up the device after a call hangs up
Assignee: nobody → thills
Status: NEW → ASSIGNED
Hi Carrie, The way it works today is the following cases: 1. User receives an incoming call, then remote party hangs up. The user returns to the screen/app they were in before receiving the call. 2. User makes an outbound call from the dialer, then remote party hangs up. The user returns to the dialer screen. In both of these pages, there is really no "call ended" page. The in-call page just flies off to either the previous app (in the inbound case) or the dialer(in the outbound case). Is it acceptable for user to see just this, or do we need to add a new call ended page? Thanks, -tamara
Flags: needinfo?(cawang)
Hi Carrie, Another question is how we should wake up the screen when we have multi-party calls. Couple cases: 1. 3 party conference calls: wake up the device when each remote drops or just when the last remote drops? My $.02 on this one is that they already get an audible tone when a party drops, so it might not be that useful to light up the screen. 2. Multiple calls : wake up the device when the first call drops or just when the last one does? Again, they get an audible tone when the first one drops, so not sure how useful it would be. Thanks, -tamara
Component: Gaia::Dialer → Gaia::System
Whiteboard: torch → torch [planned-sprint c=3]
Target Milestone: --- → 2.1 S5 (26sep)
Hi Tamara, The call ended page that I mention here is the page that we display the string "Call ended" and the call duration (and I think it happens on the cases that you mentioned in comment 3). So I think it has the value if we light up the screen and let users check the duration time of the call at this moment. Thanks!
Flags: needinfo?(cawang)
I don't think this falls into the System realm. We should just request the screen lock like we did in bug 961154. And release that screen lock when we finish displaying the call ended message
(In reply to Anthony Ricaud (:rik) from comment #6) > I don't think this falls into the System realm. We should just request the > screen lock like we did in bug 961154. And release that screen lock when we > finish displaying the call ended message Yeah, we thought the same thing too at first. We talked with Etienne about this. The screen lock isn't enough to turn on the display, only to keep it on once it's on. Etienne suggested hooking telephony events in the system app and turning on the display there.
See Also: → 1065177
Depends on: 1068093
Depends on: 1068104
Depends on: 1068106
Depends on: 1068109
Moving back to dialer. bug 1068104 is the component that will go in system.
Status: ASSIGNED → NEW
Component: Gaia::System → Gaia::Dialer
Keywords: meta
Summary: Wake up the device after a call hangs up → (meta) Wake up the device after a call hangs up
Whiteboard: torch [planned-sprint c=3] → torch [planned-sprint]
Hi Carrie, Can you let me know what you think about the cases in comment 4? Thanks, -tamara (In reply to Tamara Hills [:thills] from comment #4) > Hi Carrie, > > Another question is how we should wake up the screen when we have > multi-party calls. > > Couple cases: > 1. 3 party conference calls: wake up the device when each remote drops or > just when the last remote drops? My $.02 on this one is that they already > get an audible tone when a party drops, so it might not be that useful to > light up the screen. > > 2. Multiple calls : wake up the device when the first call drops or just > when the last one does? Again, they get an audible tone when the first one > drops, so not sure how useful it would be. > > Thanks, > > -tamara
Flags: needinfo?(cawang)
Ooops, forgot to answer this one. I'd suggest waking up the device only when the last remote drops. If user is still in a conference call and we light up the screen whenever a participant hangs up the phone, user might accidentally touch the UI with face attached. (In reply to Tamara Hills [:thills] from comment #4) > Hi Carrie, > > Another question is how we should wake up the screen when we have > multi-party calls. > > Couple cases: > 1. 3 party conference calls: wake up the device when each remote drops or > just when the last remote drops? My $.02 on this one is that they already > get an audible tone when a party drops, so it might not be that useful to > light up the screen. > > 2. Multiple calls : wake up the device when the first call drops or just > when the last one does? Again, they get an audible tone when the first one > drops, so not sure how useful it would be. > > Thanks, > > -tamara
Flags: needinfo?(cawang)
Whiteboard: torch [planned-sprint] → torch [planned-sprint][in-sprint=v2.1-S5]
Target Milestone: 2.1 S5 (26sep) → 2.1 S6 (10oct)
Depends on: 1075603
Whiteboard: torch [planned-sprint][in-sprint=v2.1-S5] → torch [planned-sprint][in-sprint=v2.1-S5][in-sprint=v2.1-S6]
Target Milestone: 2.1 S6 (10oct) → 2.1 S7 (Oct24)
Whiteboard: torch [planned-sprint][in-sprint=v2.1-S5][in-sprint=v2.1-S6] → torch [planned-sprint][in-sprint=v2.1-S7]
Target Milestone: 2.1 S7 (24Oct) → 2.1 S8 (7Nov)
All the child bugs are now resolved
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: 2.1 S8 (7Nov) → 2.1 S9 (21Nov)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: