835402 - [EMAIL] The current transitions implemented when entering the search facility give the impression that the app is malfunctioning

Status: RESOLVED DUPLICATE of bug 866899

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

Description

[ayman maat :maat]

Attachment: Video of current implementation of transitions when opening the email app's search facility

**DESCRIPTION**
The current transitions implemented when entering the search facility give the impression that the app is malfunctioning

**PATH**
1) open the email app
2) enter the search facility either by tapping on the search icon or tapping on the search text field

**EXPECTED**
The email app will transition gracefully into its search facility 

**ACTUAL**
Its very difficult to describe the transitions in their current state so i have attached a video to illustrate. Nevertheless currently they give the impression that the app is malfunctioning and as such severely impede end user perception of integrity of the  current product and therefore its viability.


[TEF_REQ] as fix is required for TEF build.

Comment 1

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

All of the complications are related to keyboard/focus management; I think we can reduce the problems, but we are still at the mercy of how the keyboard transition works and impacts our app.

In the video, Ayman is triggering the search mechanism by pulling down the message list to expose the search input box.  We listen for a click on the input box, which means that focus will have transferred to the input box and the keyboard will start to animate.  If the magnifying glass icon is used to trigger the search mechanism instead, it's less bad.

Here's the set of potential changes we could make, all of which will definitely want comments in the code:
- Trigger the search by listening for mousedown on the triggering input box ('.msg-search-text-tease') and using preventDefault to stop the box from actually gaining focus.
- (Speculative): Have the Cards helper add an additional event it will invoke on a card that is only invoked after the card has fully animated into place.  For example, afterVisible() (and then maybe rename postInsert to afterInsert too.  I'm thinking postVisible could be very confusing, suggesting I made the wrong word choice there).  We currently focus the input box during postInsert, and that might be complicating what's happening by having the keyboard animation happening at the same time we are animating our card into place.
- (VERY speculative; try an ugly hack first): As discussed elsewhere in terms of focus management, potentially detect when we are running on a device that is using a space-stealing on-screen keyboard and in those cases trigger a blur/focus-loss before transitioning to another card AND wait for the keyboard to disappear before actually starting the transition.  We already have a 'click eating' DOM node in place to stop mis-clicks during transitions, so that should protect us from other weird stuff.

Comment 2

[Mila Davydova]

This issue also reproduces on Leo build: 20130610070206
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/8e3f39363c54
Gaia: ce3b99781d182ad550a325206990c249b0dbcf0e
Platform Version: 18.0

When user cancels out of the search mode by selecting the cancel option, email app twitches, before the user is returned to the mail message view.

UCID: email-058
Link to the failed TC: https://moztrap.mozilla.org/runtests/run/1475/env/314/?&pagenumber=1&pagesize=20&sortfield=order&sortdirection=asc&filter-id=2603

Comment 3

[John Hammink]

What is the status on this?   As it makes the product annoying, I'm nomming for koi?

Comment 4

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

(In reply to John Hammink from comment #3)
> What is the status on this?   As it makes the product annoying, I'm nomming
> for koi?

Bug states and assignees are generally quite accurate in the e-mail app; this isn't being worked.  Bug 866899 to make the search UX more like the new search UX for the music app may moot this bug, but that bug is currently dead in the water.

Comment 5

[James Burke [:jrburke]]

In triage, decided to use 866899 to address this issue as it has ux involvement, and will resolve this as duplicate of that bug.