Return to app after activating the dialer



Firefox OS
4 years ago
3 years ago


(Reporter: Gert-Jan Braas, Unassigned)


(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)



(1 attachment)



4 years ago
Created attachment 8338534 [details]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:28.0) Gecko/20100101 Firefox/28.0 (Beta/Release)
Build ID: 20131126030201

Steps to reproduce:

I have a small app. Just toe learn how to program in F-OS

some personal information is shown, among which, one or more telephone
numbers. These links are displyed with a link of the form: "<a href='tel:{{phone1}}'>Call</a>" 

Tapping a link of this form "<a href='tel:06-51521379'>Call</a>" results in the dialer as shown in the provided screenshot. The dailer is shown, with the selected number prefilled.

The user then wants to cancel the call, and should return to the personal information in my app.

Actual results:

The dialer is activated as shown in the provided screenshot.

I see no way to cancel the dialer action and return to my own app.

Expected results:

I would expect some (back)button somewhere to cancel a sub-process if it is started by another proces.
Here is some context:

Taping on a "tel:" link will trigger a dial activity [1].

The "dial" activity is of type "window" [2], which means that it should not have a back or cancel button since the caller application should not wait for the activity to finish.
It's like opening a link to another website, when the user wants to come back they will launch your app again.

There is another type of activity, "inline", where the caller waits for a result [3].
If we have a strong enough use case we could implement a "inline" version of the dial activity but I'm not sure what it would look like.
Your app would then need to specifically launch this new activity (as opposed to simply using a tel: link).

+1 for implementing inline activity for dialing. As stated on the mailing list, I would like to get information regarding the call (was it made or canceled, how long did it take) to be posted back if the application asks for it[1].

Would be pretty awesome to get a rough idea of the expected UX here (even just with words ;)).

To recap: currently when an app delegates a call to the dialer (via a WebActivity or a tel link) it's a one way trip. It behaves like an app switch.

We're discussing the possibility of having an "inline" version of this, which needs to be cancel-able and might send back some information to the caller app.
Flags: needinfo?(firefoxos-ux-bugzilla)

Comment 4

4 years ago
Flagging Carrie on Dialer UX.
Flags: needinfo?(firefoxos-ux-bugzilla)
Need-info Carrie on the matter (recap in comment 3 ;) ) Thanks!
Flags: needinfo?(cawang)

I can't really imaging how can we do "inline" for Dialer. Because right now, we add an "X" button at the top left for inline activity. I feel it may look awkward in Dialer. In addition, I think going back to the dialer page totally makes sense. The dialer page is truly your previous step in this case. Thanks!
Flags: needinfo?(cawang)
Carrie, I'd like to bring this up again as part of the tabless redesign. Do you think we could fit it in with the other changes that we're making?
Blocks: 1036516
Ever confirmed: true
Flags: needinfo?(cawang)

My expected behavior would be:

1. Tap phone numbers in other APPs (e.g. Browser)
2. Open the Dialer APP with dialer pad opened and the numbers are prepopulated
3. Tap the call button
4. Cancel the call or finish the call
5. Dialer is closed automatically and user is redirected to the previous page (which would be Browser in this case)

I wonder can we close the Dialer APP directly after finishing the call? Although inline activity is something more like a system pattern, I still have concern on adding a "x" at the top of the page. I think Dialer is something more like an "APP" thing not a "page" thing. Thanks!
Flags: needinfo?(cawang)
You need to log in before you can comment on or make changes to this bug.