Closed Bug 871450 Opened 7 years ago Closed 7 years ago

[Email] Cached contact info is not automatically updated by notifications from the mozContacts API; stale info can be shown


(Firefox OS Graveyard :: Gaia::E-Mail, defect, P2)

Gonk (Firefox OS)


(blocking-b2g:leo+, b2g18+ fixed)

1.1 QE2 (6jun)
blocking-b2g leo+
Tracking Status
b2g18 + fixed


(Reporter: leo.bugzilla.gaia, Assigned: asuth)



(Whiteboard: [TD-27371], c= , MiniWW)


(2 files)

1. Title : Saving Email for existing contact is not reflecting immediately on email viewer.
2. Precondition : Email should be working 
3. Tester's Action:  Launch Email -> Open an email -> Save the contact to existing contact.
4. Detailed Symptom (ENG.) : Saved contact name is not reflected immediately on email viewer card.
5. Expected :Saved contact should reflect on the email viewer contact screen.
6.Reproducibility: Y
           1)Frequency Rate : 100%
7.Gaia Master/v1-train : Reproduced
8.Gaia Revision: 393b3f57822ae0f34055c6a6060f1433136bafa0
9.Personal email id:
Target Milestone: --- → 1.1 QE2
We chose to cut corners on this at the work week and landed the contact resolution fix in bug 848266 without the mozContacts notification listening logic.

Note that the add/remove/edit a contact logic when you click on an e-mail bubble is not impacted by this; we explicitly issue a fresh lookup every time when deciding what menu options to try.
Depends on: 848266
Summary: [Email]Saving Email for existing contact is not reflecting immediately on email viewer → [Email] Cached contact info is not automatically updated by notifications from the mozContacts API; stale info can be shown
Priority: -- → P2
Assignee: nobody → bugmail
blocking-b2g: --- → -
tracking-b2g18: --- → +
blocking-b2g: - → leo?
Hi Leo, can you clarify if this bug means:
1> The address is not displayed only directly after you added the new contact; or
2> The new contact never gets displayed as a saved name?
Flags: needinfo?(leo.bugzilla.gaia)
Hi wchang,
Both the points 1) and 2) in comment #2 are also applicable in this case.

From email reader, if we save to new contact, or save to an existing contact or edit a contact name, it is not reflecting on transition to message reader from contacts app.

We have to kill the app and relaunch to see the changes updated at contacts.
Flags: needinfo?(leo.bugzilla.gaia)
Its a minor annoyance, not blocking worthy and the user is still able to perform the job.Will consider a low risk uplift if found depending on where we are in the cycle
blocking-b2g: leo? → -
Whiteboard: [TD-27371] → [TD-27371], c=
Whiteboard: [TD-27371], c= → [TD-27371], c= , MiniWW
As discussed in San Diego work week marking this as leo+.
blocking-b2g: - → leo+
Andrew are you actively working on this or should we reassign?
Flags: needinfo?(bugmail)
Yes, actively being worked.  Combination of review burden on other bugs, more UI clean-up required than expected, and general optimism about unit tests has drawn this out a little.
Flags: needinfo?(bugmail)
Attachment #756246 - Flags: review?(squibblyflabbetydoo)
Comment on attachment 756178 [details]
Pointer to Github pull request:

Key note when testing: we do *not* update names when removing a contact.  So if the e-mail display name is "Bob", and you add a contact covering that e-mail with a name of "Chuck", our UI will update from Bob to Chuck.  But if you delete that contact (or the email on the contact), we will not reset the name back to "Bob" because we had already forgotten about the name.  Things will reset the next time the e-mail is re-displayed and contacts are re-displayed from scratch.
Attachment #756178 - Flags: review?(squibblyflabbetydoo)
Attachment #756178 - Flags: review?(squibblyflabbetydoo) → review+
Attachment #756246 - Flags: review?(squibblyflabbetydoo) → review+
Both of these look good. Tests pass, and it seems to work in practice based on my manual tests!
Flags: in-moztrap?
Created test case for this issue, checking to make sure if an e-mail address is added to an existing contact, then the name of the contact will be displayed when being sent back to the e-mail app.
Flags: in-moztrap? → in-moztrap+
You need to log in before you can comment on or make changes to this bug.