Closed Bug 871450 Opened 7 years ago Closed 7 years ago
[Email] Cached contact info is not automatically updated by notifications from the moz
Contacts API; stale info can be shown
412 bytes, text/html
358 bytes, text/html
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: email@example.com
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
Assignee: nobody → bugmail
Status: NEW → ASSIGNED
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?
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.
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? → -
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?
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.
Pointer to Github pull-request
Pointer to Github pull-request
Attachment #756246 - Flags: review?(squibblyflabbetydoo)
Comment on attachment 756178 [details] Pointer to Github pull request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/213 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!
laned on gaia-email-libs-and-more/master: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/213 https://github.com/mozilla-b2g/gaia-email-libs-and-more/commit/b1755f7beeb3861bf7263a76ce42de4c01cdad09 landed on gaia/master: https://github.com/mozilla-b2g/gaia/pull/10118 https://github.com/mozilla-b2g/gaia/commit/7bdd94acc9703e1ed99ab738ddf0b7bbef5799da
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. https://moztrap.mozilla.org/manage/cases/?filter-id=9241
Flags: in-moztrap? → in-moztrap+
You need to log in before you can comment on or make changes to this bug.