[Contacts] When viewing contact details from the Messages app (via Activity) the chat icon is not functional and not disabled either

RESOLVED FIXED in Firefox OS v1.3

Status

Firefox OS
Gaia::Contacts
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: nkot, Assigned: arcturus)

Tracking

unspecified
1.3 C3/1.4 S3(31jan)
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:1.3+, b2g-v1.3 fixed)

Details

Attachments

(4 attachments)

(Reporter)

Description

4 years ago
Created attachment 8356820 [details]
logcat

Description:
Viewing contact info from the header(contact name) in the message tread will open a contact details page where chat icon is displayed but is not functional and not disabled either.

Repro Steps:
1) Updated Buri to BuildID: 20140107040206
2) Have existing contact on device
3) Have some messages to or from that contact
4) Open Messages app 
5) Open existing thread
6) Tap on the contact name (header)
7) Select to View contact
8) Tap on chat icon to send a message to a contact

Actual:
Tapping the icon doesn't do anything, the icon is nonfunctional 

Expected:
The icon is either disabled or functional

Environmental Variables:
Device: Buri v1.4 Master build, Mozilla RIL
BuildID: 20140107040206
Gaia: 9f30198a420632359b271de7e680abde92ccbcd6
Gecko: e7a366c1036c
Version: 29.0a1
Firmware Version: 20131115

Notes:

Repro frequency: 100%
See attached logcat
Does this reproduce on 1.3 or 1.2?
Keywords: qawanted
Component: Gaia::SMS → Gaia::Contacts
Summary: [B2G][Messages] When viewing contact details from the Messages app the chat icon is not functional and not disabled either → [Contacts] When viewing contact details from the Messages app (via Activity) the chat icon is not functional and not disabled either

Updated

4 years ago
QA Contact: sarsenyev

Comment 2

4 years ago
It does reproduce on 1.3 build
The chat icon is inactive in contact details (via Activity)

It doesn't reproduce on 1.2 during the different design, when a user tap the contact name he is navigated to make a phone call to this contact, no any other options are available

Device: Buri 1.3 MOZ
BuildID: 20140108004001
Gaia: 522779225e86b7a4d1bf759036678dc321a1486e
Gecko: 2287f2839256
Version: 28.0a2
Firmware Version: v1.2_201331115
Keywords: qawanted
Can I get a video demonstrating the bug?
Keywords: qawanted

Comment 4

4 years ago
Created attachment 8358508 [details]
Bug_video.ogg

I attached a video for the bug

Updated

4 years ago
Keywords: qawanted
Looks like this is broken UI - we have a chat icon available to click that does nothing.
blocking-b2g: --- → 1.3?
I am also having problems when calling to the contact from the same contact detail screen,

so same steps from 1 to 7 as in the Description of this bug and
8) Tap on dialer icon to call to the contact

Actual:
go back to the messaging thread

Expected:
Dialer is opened with the contact number entered.

I can open a new bug for it if you think it's better

buri
v1.3
B-34
Gecko-a08d78f
Gaia-14e199d
What's the proposed UX here.

Should we remove the icon? For me is the preferred option.
(In reply to Maria Angeles Oteo (:oteo) from comment #6)
> I am also having problems when calling to the contact from the same contact
> detail screen,
> 
> so same steps from 1 to 7 as in the Description of this bug and
> 8) Tap on dialer icon to call to the contact
> 
> Actual:
> go back to the messaging thread
> 
> Expected:
> Dialer is opened with the contact number entered.
> 
> I can open a new bug for it if you think it's better
> 
> buri
> v1.3
> B-34
> Gecko-a08d78f
> Gaia-14e199d

Yup, that's a different bug for me. Will need to check if we can use the Telephony Helper when being called as an activity, have some doubts about permissions.

Thanks!
(In reply to Francisco Jordano [:arcturus] from comment #7)
> What's the proposed UX here.
> 
> Should we remove the icon? For me is the preferred option.

The last WF documentation that I have found regarding this topic, HTML5_SMS-MMSUserStorySpecifications_20130429_V7.0.pdf, do not offer the option "View Contact" when tapping the contact in the header of the thread so ni to Ayman to clarify if what is the desired behaviour.

Depending on his answer I will file another bug reporting the dialer issue.
Flags: needinfo?(aymanmaat)

Comment 10

4 years ago
Hey Maria

Bit of history for you to being you back up to speed now your back :)

In V1.0 ‘tap on header == open contact detail’. Then in V1.2 we had a hard requirement to change this to ‘tap on header == direct dial’ because we could not get a ‘dial’ CTA on the message thread interface. Both these changes are documented. However during V1.3 the behaviour was changed again from ‘tap == dial’ to ‘tap == options (1. Call, 2. View contact)’ but not documented as it was handled on the fly. The reason for this change was because there was a desire (i cannot remember where it came from) to deliver more functions and information to the user about the contact when they tapped on the header in a message thread. The original UX proposal was that upon tap the user would go direct to the contact detail card (as this is where all the information/functionality a user could ever want for a given contact is stored) however there was *still* the hard requirement to ‘direct dial’ the contact on the number that is associated to the thread being viewed. We simply could not put the Dial CTA in the interface of the message thread itself as in the current page architecture there is no real estate for it, and there was no design/dev bandwidth to completely redesign the message thread interface (which is something we need to do at some point). The next option explored was to have the number associated to the message thread (somehow) highlighted in the contact detail card. But again at the time there was no design/dev bandwidth to follow this option through… So we ended up with, upon tap, this overlay that contains three CTAs: 1) Call, 2) View Contact, 3) Cancel.

From a UX PoV the solution to this bug should be..

1) SELECT MSG CTA FROM CONTACT DETAIL CARD ACCESSED VIA MESSAGE APP  

**PATH**
1.1) open message app
1.2) select thread that is associated to contact in the contact list
1.3) select the header of the message thread
1.4) select ‘View contact’
1.5) select the message CTA that is associated to the number associated to the message thread opened in step 2

**EXPECTED**   
The user will be presented with the message thread opened in in step 2

2) SELECT MSG CTA FROM CONTACT DETAIL CARD ACCESSED VIA CONTACTS APP  

**PATH**
2.1) open contacts app
2.2) select a contact that has an existing message thread in the message app
2.3) in the contact’s detail card select the message CTA 

**EXPECTED**
The user will be presented with the current message thread for this contact
this was specified in HTML5_Dialer_Contacts_20120810_R2S1_V6.0, page 24, annotation 04

**ACTUAL**
The user is presented with the new message screen. 
….We should open a bug to address this.

3) SELECT DIAL CTA FROM CONTACT DETAIL CARD ACCESSED VIA MESSAGE APP  

**PATH**
3.1) open message app
3.2) select thread that is associated to contact in the contact list
3.3) select the header of the message thread
3.4) select ‘View contact’
3.5) select the dial CTA that is associated to the number associated to the message thread opened in step 2

**EXPECTED**
Number will be dialled

**ACTUAL**
Message thread accessed in step 3.2 is presented
….We should open a bug to address this.
Flags: needinfo?(aymanmaat)
Hi Ayman,

I think this open the door to way to many problems. First we can enter in loops that won't be a pain in the ass for navigation, and memory, opening sms, contacts and dialer ... with our current devices I'm sure that the memory killer will start working before the user ends up doing what was suppose to do.

Also, for example in the case 1, if we go to see a user from a thread, and the user has 2 phone numbers, what should happen if clicks in the phone number that wasn't the same one used on the thread that opened contacts? Perhaps we don't have a thread with the 2nd phone number.

IMHO, I would like to restrict the actions that you can do when using contacts as a web activity. Right now is the nexus for doing way too many things (calling, sending sms, email), and that could lead (or is leading) to way to many errors.

I would like to revisit all this possible actions once we haidify contacts, and the cost of accessing the contact detail view is not that heavy.

Toughs?
Flags: needinfo?(felash)
Flags: needinfo?(aymanmaat)

Comment 12

4 years ago
(In reply to Francisco Jordano [:arcturus] from comment #11)
> Hi Ayman,
> 
> I think this open the door to way to many problems. First we can enter in
> loops that won't be a pain in the ass for navigation, and memory, opening
> sms, contacts and dialer ... with our current devices I'm sure that the
> memory killer will start working before the user ends up doing what was
> suppose to do.
> 
> Also, for example in the case 1, if we go to see a user from a thread, and
> the user has 2 phone numbers, what should happen if clicks in the phone
> number that wasn't the same one used on the thread that opened contacts?
> Perhaps we don't have a thread with the 2nd phone number.

Well each thread should be dedicated to a single number. So if a contact has more than one mobile phone number and ‘phone number 1’ has a thread and ‘phone number 2’ does not and the user: 

1) is looking at the thread for ‘phone number 1’ 
2) selects the header
3) selects ‘view contact’
4) selects the message CTA for ‘phone number 2’ in the contact detail card  
…I would expect the new message composer to be opened because the user is starting a new thread. Step 4 in isolation was specified back in HTML5_Dialer_Contacts_20120810_R2S1_V6.0, page 24, annotation 04
 
> 
> IMHO, I would like to restrict the actions that you can do when using
> contacts as a web activity. Right now is the nexus for doing way too many
> things (calling, sending sms, email), and that could lead (or is leading) to
> way to many errors.

Ok, well lets talk and see what we can do. My bottom line is that I don’t wanna disable the related messages CTA in the Contact Detail card as this makes no sense from a IxD PoV: The user *can* send a message to the number in question, its just inconvenient for us for them to attempt to do it via this rout. There is no way a user will understand that if they were to find the button disabled.

> 
> I would like to revisit all this possible actions once we haidify contacts,
> and the cost of accessing the contact detail view is not that heavy.

I hear you, but unfortunatly we need a solution for the versions effected before we reached the promised land that is Haida

> 
> Toughs?

Lets talk. Ping me when your free
Flags: needinfo?(aymanmaat)
> The reason for this change was because there was a desire (i cannot remember where it came
> from) to deliver more functions and information to the user about the contact when they 
> tapped on the header in a message thread.

I think it came from me: I want to be able to go to a contact card (eg to modify it, add notes, etc) from a thread header. Also, this was inconsistent with the behavior when tapping on a header for an unknown contact, which _was_ showing a menu.

Now to reply to Francisco, well, I don't know. Remember an activity could come from anywhere. For example, if a random app wants to display a contact, why would you remove the ability to text/call from the contact card?

I don't think entering in loops is really an issue. When we launch an activity for an app that is already launched, they share the same process. The real issue (in my opinion) is that we load too much stuff for showing only one contact card. (The same happens in the SMS app and I'm working on the first step to fix this).

Also related, Gabriele pointed me to bug 892371 about modifying the app priorities when sending/handling activities.

But you didnd't explain what's the initial cause of the bug. Is that an OOM issue ? Is that an activity issue ?
Flags: needinfo?(felash)
David,

Please review if this bug is reproducible in 1.3?

Please work per comment 12
Flags: needinfo?(dscravaglieri)
clear n?
Flags: needinfo?(dscravaglieri)
hi Francisco, do you think it is possible to fix this in the 1.3 remaining timeframe? thanks
Flags: needinfo?(francisco.jordano)
Hi Joe,

taking care of this :)
Assignee: nobody → francisco.jordano
Flags: needinfo?(francisco.jordano)
Blocks: 962566
Hi, again

I was looking at the code, and we have a patch from Etienne 2 years ago preventing to launch some operations (mainly opening other web activities) if contacts is already being invoked as a web activity:

https://github.com/mozilla-b2g/gaia/commit/3bf13c0b

Pinging Etienne, to clarify if what were the reasons to avoid this, otherwise we could remove that limitations. My point is again, if we allow this circular dependencies we will end up with a huge memory problem.

Thanks,
F.
Flags: needinfo?(etienne)

Updated

4 years ago
blocking-b2g: 1.3? → 1.3+

Updated

4 years ago
Target Milestone: --- → 1.3 C3/1.4 S3(31jan)
(In reply to Francisco Jordano [:arcturus] from comment #18)
> Hi, again
> 
> I was looking at the code, and we have a patch from Etienne 2 years ago
> preventing to launch some operations (mainly opening other web activities)
> if contacts is already being invoked as a web activity:
> 
> https://github.com/mozilla-b2g/gaia/commit/3bf13c0b

Well you can launch a gallery pick activity while you do a new contact activity already and it works, so there is no inherent limitation.
That said, I think we probably want to make sure we're not launching any new activity while handling a "PICK" activity.

Anyway I wouldn't trust my code from two years ago :)
Flags: needinfo?(etienne)
Thanks Etienne, I do trust your code from two years ago, but will enable the actions when we are in an activity which type is not PICK.

Will provide a patch soon.

Thanks folks!
I'd say you want to enable the actions only for the "view" activity. Seems like that for all other activities we don't want to do sms or dialing...
(but I admit I don't know well all activities you have, so it's up to you :) )
Hi,

just reviewing the code, we have a 'open' activity, I think this review didn't go under my radar, won't modify this, since I don't want to introduce new regressions, so will use that for the actions of sending an sms or email ... and calling, so we fix as well bug 962566
Blocks: 963504
Created attachment 8364984 [details] [review]
Pointer to PR 15679
Attachment #8364984 - Flags: review?(jmcf)
Duplicate of this bug: 962566

Comment 25

4 years ago
Comment on attachment 8364984 [details] [review]
Pointer to PR 15679

thanks!
Attachment #8364984 - Flags: review?(jmcf) → review+
status-b2g-v1.3: --- → affected
Landed:

https://github.com/mozilla-b2g/gaia/commit/57ff25637a82ab816039604018b619c2fb17a5f4
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Reporter)

Comment 27

4 years ago
Created attachment 8368140 [details]
screenshot

There are other activities that are still nonfunctional, can those be fixed here as well?
Uplifted 57ff25637a82ab816039604018b619c2fb17a5f4 to:
v1.3: b4845322abe4365ebd0782e47438b7e4c616b89e
status-b2g-v1.3: affected → fixed
Comment on attachment 8368140 [details]
screenshot

NI Francisco for comment 27
Flags: needinfo?(francisco.jordano)
@Julien, 

thanks a lot for the NI.

I've been taking a look and we missed the email web activity, is not going through the flow that was fixed with this bug.

For the social actions, this is worst, since they are not web activities.

Will create two new bugs. One for doing the follow up and another for the social actions.

Thanks!
Flags: needinfo?(francisco.jordano)
Blocks: 966445
You need to log in before you can comment on or make changes to this bug.