816783 - [email] Autocomplete known contacts when user manually types/enters an e-mail address in any of the composer address fields

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, enhancement)

Description

[mlevin]

Attachment: No drop down list of contacts seen while typing in the e-mail address.

Unagi Build ID: 20121129071415

See attached screen shot.

Steps:
1. Open and Compose Message View and tap in the "CC" field
2. The Virtual Keyboard is displayed
3. Type an email address in the "CC" field

Expected:    
The user can type in the "CC" field. If the typed email is associated with an existing contact a filtered list of contacts is displayed as a drop-down list. For each contact in the list the name and the contact picture is displayed in the list. Tapping on the contact will autocomplete the email in the "CC" field.

Actual:
When the typed email is associated with an existing contact a filtered list of contacts is NOT displayed as a drop-down list.

Comment 1

[Natalya Kot [:nkot]]

Also occurs when typing in "To" field, no drop-down list of relevant contacts appears while typing (TC #1989)

Comment 2

[Nick Davidson]

This is reproing on Unagi Kernal Dec 5  Build 20130130070201

CASE #1994 

Gecko:  http://hg.mozilla.org/releases/mozilla-b2g18/rev/94a2d6fcdfde
Gaia:   6369dbf33b622faf4b4d176fed30b77c5c319dfc

Actual Results:
When user typing email associated with an existing contact in address book in "To" "Cc" or "BCC" fields a filtered list of contacts is NOT displayed as a drop-down list.

Comment 3

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

dropped for v1; need to change test case.  Moving as enhancement as I'm pretty sure we want this in a future version.

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

Not tracking then since this is OOS for v1, please renominate for tracking in the version it will be targeted for.

Comment 5

[Mila Davydova]

This issue still reproduces on Unagi device.
Build ID: 20130225070200
Kernel Date: Dec 5
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/3a5a27992a75
Gaia: 5691a16fff8e1403c75ed9d6f3a443b7e58198c6

When user types an email address, associated with an existing contact in address book in "To" field, a filtered list of contacts is NOT displayed as a drop-down list.

UCID: email-103
TC: https://moztrap.mozilla.org/runtests/run/859/env/305/?pagenumber=1&pagesize=20&sortfield=order&sortdirection=asc&filter-id=1989

Comment 6

[Chris Kreinbring [:CKreinbring]]

Still repros on Leo 1.1 mozilla RIL.

Build ID: 20130801070210
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/aff662053ee8
Gaia: ddb922ed002e88d01f71199da32ff75911b455b2
Platform Version: 18.1

Comment 7

[Nikolai Khristoforov]

This issue repros on Buri v 1.2 Mozilla RIL.

Build ID: 20131011004001
Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/c8e97fd5b94d
Gaia: 79abf09f2b5b6440f43cb5ae44ef6c85c0437e8d
Platform Version: 26.0a2

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

This aspect of the test case was never valid; this is a feature request.  The original UX wireframes called for this feature, but it was scoped out.  If the permafail hasn't stopped people from running the test case, it should be invalidated or modified as Naoki suggested in comment 3.

Comment 10

[Jason Smith [:jsmith]]

backlog - this doesn't hit the QC & DSDS feature list, so not blocking.

Comment 12

[nulti-korisnik]

Is there any chance for this to be added in near future? This is important feature.

Comment 13

[James Burke [:jrburke]]

The planning for 3.0 is still ongoing, so no confirmed set of features yet for that release, which would be the next feature release. I agree it would be nice to have, but also no active work is being done on it at the moment.

Comment 15

[Sheeri Cabral [:sheeri]]

FWIW it's not in the 3.0 pre-release. Is the planning still ongoing for the 3.0 features or are they already set?

Comment 16

[James Burke [:jrburke]]

Planning is still in progress. While that planning is ongoing, the current focus of the email developers is on conversation support. I would like to get this in too. However, given that the conversation support is a very large change, I am not sure yet when work on this item would begin, as we would likely want to build it on top of the extensive conversation support changes.

Comment 17

[James Burke [:jrburke]]

Here is a video capture in a simulator that shows an initial UI pass at an autocomplete for email compose:

https://vimeo.com/134511325

It is only using the contacts API, but we would like to expand the autocomplete API to include email addresses from email you sent.

I noticed the labels (to: cc: bcc:) and the + icons should be breaking to the next line as the input does too. So that is a bug that I plan on fixing.

Looking to get UX feedback from the UX team to make sure this is in the right direction, so asking Juwei for feedback.

Right now this is on the email conversations branch, not in master. If we lock down how it should operate, there is a chance we could land it on email master if we just stick with the contacts API as the data source, and the UI behavior does not depend on the other component refactor work in the conversation branch. This example does not currently, at least not too much. However, I will know better if we can cherry pick this out of the conversations branch once we settle on the UX feedback.

Comment 18

[GitHub Autolander Bot]

Attachment: [gaia] jrburke:bug816783-email-autocomplete > mozilla-b2g:master

Comment 19

[Juwei Huang[:juwei]]

Hi James! Nice job! looks sophisticated :)
I think this bug is the same as bug 989809, it used to be a 2.x feature.
And it is well alignment with the spec except for a few transition, however I think we can tweak the transition on later version.

Great job! Luv it :D

Comment 20

[James Burke [:jrburke]]

Comment on attachment 8640757 [details] [review]
[gaia] jrburke:bug816783-email-autocomplete > mozilla-b2g:master

Juwei: thank you for pointing to the other bug. I did not bother to look for another bug since this one's bug number is so old, thought it was the one to use to track the feature!

The display of the autocomplete matches is different than bug 989809's design doc. That design doc specified placing the matches inline with the DOM elements for the to/cc/bcc (with a height animation for in/out display), and allowing that whole DOM to scroll.

That sounds neat, and I will keep bug 989809 open to track looking into that. I have had trouble getting an animation slide down of existing content to show new nodes for the account display in the folder picker. Bug 1180243 comment 2 indicates one of the side effects that is seen when the email app does it for the list of accounts in the folder overlay.

It is very possible I am not using the best mechanism for that kind of scroll reveal (I was trying to stick with transformY since they seemed to animate well given prior animation guidance).

So if I figure out a better mechanism for the account display, then we could use it here. The way the email autocomplete is working now, it matches close to what the sms app does, with the autocompletes overlaying instead of inlining the matches. So all that coupled with the UX OK to land this as-is with a follow on improvement (which bug 989809 will track), I will ask for dev review now.

Comment 21

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 8640757 [details] [review]
[gaia] jrburke:bug816783-email-autocomplete > mozilla-b2g:master

Awesome like Blossom.  I think that's the reference.  r=asuth with non-nits/non-discretionary things addressed, of which there are very few.

Comment 22

[James Burke [:jrburke]]

Comment on attachment 8640757 [details] [review]
[gaia] jrburke:bug816783-email-autocomplete > mozilla-b2g:master

Asking for review again after some significant changes based on review feedback:

* The autocomplete now sits as a tag at the bottom of compose's scrollregion-below-header area. This allows it to properly sit on top of the other content in compose, particularly since the cmp-autocomplete-input-list now uses a transform for scrolling, and that seemed to create a separate layer so that if the autocomplete was in that area, it was getting clipped/hidden by the divs below cmp-autocomplete-input-list.

* cmp-autocomplete-input-list is now scrolled using an translateY transform with a CSS transition to move the input elements to the top of the view. gesture_detector was used to detect 'pan' finger drags to restore the cmp-autocomplete-input-list to translateY(0). This gives it a nice drag feeling when wanting to "scroll up" to see addresses already entered.

* Since a transition is used to move the input box around, the user has a better sense of place, and the autocomplete list is first shown after the transition finishes, to help the user track their sense of place. This meant doing some transitionend work, and the positionElements method (was named sizeList before) has a promise jump to finish its work.

* The onBlur approach with its setTimeout hide was removed, and instead event listeners on the document for click or focus events will hide the autocomplete. I liked the onBlur approach to try to keep the autocomplete encapsulated within itself, but since the autocomplete is already reaching outside of itself for things like window resize events, this seemed fine to do. It removes the setTimeout, and also works better for screen reader use as the matches stay up for selection. So the screen reader situation is much better.

* Due to the better screen reader support, the autocomplete_item.html changed its structure. It was a balancing act to get selectable elements in the screen reader as well as proper full bleed background active/focus coloring that did not affect the margins around the text and bottom border line for each item.

* Support for pressing the down arrow in a full keyboard was added, pressing it while in an input field jumps the focus down to the first item in the match list. Using Tab from then on to select other elements work. The Down arrow in the match list scrolls the match list, just the default browser navigation actions there, nothing added explicitly by this change.

* I did some small HTML/CSS adjustments for RTL in autocomplete_item.html for mixed content, just using the standard dir="auto" and explicit text-align approach we have used elsewhere.

Comment 23

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 8640757 [details] [review]
[gaia] jrburke:bug816783-email-autocomplete > mozilla-b2g:master

Love how smooth the new scrolly stuff is!  Clearing review flag for another pass because the weird duplicated autocomplete input which can cause scrolling breakage is bad and since I haven't quite figured out why it's happening, I'll need to take a look again once you've fixed it.

Also, for the next check, if you could avoid squashing, it'd be appreciated.  I locally diffed between your pre and post-rebases, but it's more fun to just look at the commits on github.

Comment 24

[James Burke [:jrburke]]

Comment on attachment 8640757 [details] [review]
[gaia] jrburke:bug816783-email-autocomplete > mozilla-b2g:master

Ready for another review pass. I kept the review feedback changes separate this time. Sorry for squashing earlier, it felt so different I did not think it would help to maintain the old commit, but did not adequately consider your saved memory state.

The only other change I did besides just review comments (which are called out in comments in the github pull request) was changing the slide transition to 200ms instead of 300ms, to match the existing 200ms we use for transitions everywhere else.

Comment 25

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 8640757 [details] [review]
[gaia] jrburke:bug816783-email-autocomplete > mozilla-b2g:master

Woo!

Comment 26

[Ryan VanderMeulen [:RyanVM]]

Master: https://github.com/mozilla-b2g/gaia/commit/79b9da4db1b7ac7cdbf7a1879731994d2bc88daf