Closed Bug 831974 Opened 11 years ago Closed 10 years ago

[B2G][Dialer] User has to press 1 for a long time before Voicemail is reached

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
2.1 S6 (10oct)

People

(Reporter: ahubenya, Assigned: rik)

References

Details

(Whiteboard: [c=1])

Attachments

(1 file, 1 obsolete file)

When user tries to access Voicemail by pressing and holding number 1 on Unagi Dialer, he must wait approx. 5 seconds before voicemail is reached. 

Repro Steps:
1. Update to Unagi Build ID: 20130117070201. 
2. Open Dialer
3. Press and hold number 1


Actual Results:
Speed dial to reach voicemail takes long to reach.


Expected Results:
Voicemail through speed dial should be reached a lot faster than it is.

Notes: 
Repro rate: 6/6, 2 dif accounts
OS: Windows 7 → Gonk (Firefox OS)
Hardware: x86_64 → ARM
The same issue is reproducing on Inari Build ID: 20130426070207

Environmental  Variables:
Kernel Date: Feb 21
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/54285d67454b
Gaia: c47ef39de04e634d847cc86b6acc616fabce69eb
Issue is still reproducing on the Leo device. When holding down 1 to reach voicemail, it takes a couple seconds before user is connected to the voicemail.

Environmental Variables
Build ID: 20130805071207
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/a2a9b89ef5ee
Gaia: 45f6a739b09292e16717fb21003386c914ca29c2
Platform Version: 18.1
Flags: needinfo?
Flags: needinfo?
Currently, we're waiting 1.5 seconds before calling voicemail. Maybe we could reduce that time?

Carrie: What do you think? Is there a requirement for it to be that long?
Flags: needinfo?(cawang)
Yes, I've tried it on both our device and Android device. I feel that it takes at least 3 secs to connect to voicemail (Android takes approx 1.5 secs). I think we need to cut it down at least under 2 secs. Thanks!
Flags: needinfo?(cawang)
(It only takes ~1 second on my Flame, running a Firefox 2.1 Aurora build, FWIW.)
Carrie: In the code, we are currently waiting exactly 1.5s before calling. I've just verified with a stopwatch on a Flame and we see the 1 disappearing around 1.5s later. That's when we know we're calling the voicemail. It takes a bit more time (< 300ms I'd say) for the callscreen app to slide down in view. But that's expected because we need the telephony stack to initiate the call and send the event that opens the callscreen app (callschanged).

So if Android feels faster, it's probably because they wait less time than 1.5s. What we need to know is how short can we make that timer without breaking certification or something else.

For example, the timer to turn a "0" to a "+" is 400ms. Same timer for the delete key to delete the whole number.
Flags: needinfo?(cawang)
OK, I've tried it and also calculated the time. It takes approx 2.8 secs to display the whole voicemail screen. I think the problem is the time of "long press". We need to keep holding on the key for a while. Can we cut it down (<400ms)? Thanks!
Flags: needinfo?(cawang) → needinfo?(anthony)
Assignee: nobody → anthony
Status: NEW → ASSIGNED
Flags: needinfo?(anthony)
Whiteboard: [c=1]
Target Milestone: --- → 2.1 S6 (10oct)
Here's a patch with 400ms instead of 1.5s. Let me know if it feels too short now.
Attachment #8498295 - Flags: ui-review?(cawang)
Attachment #8498295 - Flags: review?(drs+bugzilla)
(In reply to Carrie Wang [:carrie] from comment #7)
> Can we cut it down (<400ms)? Thanks!

That seems like way much too short of a threshold to me.  I can easily see people holding down number buttons for 400ms during normal dialing -- for example:
 a) older folks who can't move their fingers very fast
 b) people who aren't familiar with smartphones / touchscreens (i.e. our target market)
 c) people with low-powered hardware that may have a bit of a delay between touching the screen & the number showing up (i.e. our target hardware), depending on phone load

Rik says in IRC that we have a 400ms delay on the "0" key to make it insert a "+", but if the user accidentally triggers that, it's a lower-cost sort of mistake to make -- they can easily just backspace it.  In contrast, if they accidentally trigger a voicemail call by holding "1" for too long, they'll enter a call, and the phone number that they're partway through typing will be erased.

I think the current delay (1500ms) is pretty reasonable. (If it's lowered, it shouldn't go lower than a second, or else we'll start to cause accidental-voicemail-calls for users in cases a/b/c above.)

The real problem here seems to be that Carrie's device is showing some extra delay between the 1500ms-threshold and the voicemail screen actually popping up. Maybe we need to make that snappier? I don't think the solution is to make the 1500 threshold much lower, though.
Alternately: I'd be more OK with a lower threshold, if we made it so that "1" *only* dialed voicemail if it's there's nothing entered before it. A lot of my concern is for folks who are dialing a number with a "1" near the end, like "+##-###-###-##1#" -- if they happen to hold that 1 for too long (and we have the threshold set to something low like 400ms), then we'll interrupt their dialing & ruin all the work that they've spent dialing the rest of the number.
(In reply to Daniel Holbert [:dholbert] from comment #10)
> Alternately: I'd be more OK with a lower threshold, if we made it so that
> "1" *only* dialed voicemail if it's there's nothing entered before it. A lot
> of my concern is for folks who are dialing a number with a "1" near the end,
> like "+##-###-###-##1#" -- if they happen to hold that 1 for too long (and
> we have the threshold set to something low like 400ms), then we'll interrupt
> their dialing & ruin all the work that they've spent dialing the rest of the
> number.

This is a good idea. I just checked, and Android does it this way.
Comment on attachment 8498295 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/24621

Technically, this looks good. I left one nit in the PR.
Attachment #8498295 - Flags: review?(drs+bugzilla) → review+
Hi, 

I've asked some people to try the patch and all of them think that 400ms feels much better (I thought we are currently adopting 400ms so that's why I suggested <400ms in comment 7). In addition, I think the suggestion from comment 10 is really the right direction. Let's do it with 400ms and also only connect to voicemail when there isn't any number before long-pressed "1".
Attachment #8498295 - Flags: ui-review?(cawang) → ui-review+
Previous pull request was closed so here's a new one.

I've addressed the comment, made the changes to make it only work for the first digit, added the tests and also removed the useless voicemail parameter.
Attachment #8498868 - Flags: review?(drs+bugzilla)
Attachment #8498295 - Attachment is obsolete: true
Comment on attachment 8498868 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/24705

Please see my comment on the PR.
Attachment #8498868 - Flags: review?(drs+bugzilla) → review-
Comment on attachment 8498868 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/24705

I've removed the data-voicemail attribute in all apps (Dialer, Callscreen and Emergency-call). I've also removed the voicemail related code from the emergency call app since there are no reasons to use it from there.
Attachment #8498868 - Flags: review- → review?(drs+bugzilla)
Comment on attachment 8498868 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/24705

You missed `data-voicemail="true"` in mock_dialer_index.html.

This is a good opportunity to file a followup to unify the emergency-call and dialer keypad.js files. We can use init config parameters to enable and disable functionality.
Attachment #8498868 - Flags: review?(drs+bugzilla) → review+
We already have bug 1053922 to clean our keypad code.
https://github.com/mozilla-b2g/gaia/commit/537bce4802284d5347d96802d7919ef19ce21dfa
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: