1163218 - [Email][Search] Tapping on the search field in inbox causes the keyboard to awkwardly open, close, and open again during the screen transition.

Status: RESOLVED WONTFIX

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

Description

[Martin Shuman [:Marty]]

Attachment: logcat-email-search-selection.txt

Description:
When the user taps the search field at the inbox screen, a cursor appears on that field and the keyboard pops up. The screen then transitions to the Search screen, and the keyboard dismisses. Then the cursor reappears in the new search field at the top of the screen, and the keyboard is once again opened.

Notes:
-This only seems to occur the first time the search field is selected after the app has been launched.
-Attempting to type on the keyboard the first time it appears does not seem to do anything.

Prerequisites: Have an email account already set up on the device.

Repro Steps:
1) Update a Flame to 20150508010203
2) Launch the email app.
3) Pull down on the list of email messages in the inbox to reveal the search field.
4) Tap the search field.

Actual:
The keyboard appears, the screen transitions to the Search screen, the keyboard disappears, and then the keyboard appears again.

Expected:
The keyboard only appears once, after the screen has transitioned to the Search screen.

Environmental Variables:
Device: Flame 3.0 (Full Flash)
Build ID: 20150508010203
Gaia: bc5bfa18f795919b56b952bbf3637c235d0e13dc
Gecko: 356e735fa908
Gonk: a9f3f8fb8b0844724de32426b7bcc4e6dc4fa2ed
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

This issue occurs on 319MB and 512MB memory.

Repro frequency: 4/5
See attached: Logcat, Video (URL)

Comment 1

[Martin Shuman [:Marty]]

This issue DOES occur on Flame 2.2 builds.
The keyboard appears, the screen transitions to the Search screen, the keyboard disappears, and then the keyboard appears again.

Environmental Variables:
Device: Flame 2.2 (Full Flash)
Build ID: 20150507002500
Gaia: 83a63e0e6fcc22c6a74b06ef77b88d5049719cad
Gecko: 118ddfc76b60
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Comment 2

[James Burke [:jrburke]]

This happens because the HTML for the UI is restored quickly from cache, but the event handlers are not bound right away until the JS code finishes loading. So there is a window on app launch where this can be triggered, but it does take a bit of timing to get the tap in that window.

The long term fix would be to move away from a text input for that message_list card, so that the keyboard does not have a reason to appear. What stopped me from doing that before was some shared styling it was using for inputs to get that look, those styles would need to be replicated and kept up to date with shared style changes. 

Probably worth doing though to avoid early taps all together, and since that area is really a text entry area, but a trigger to the search card. 

There was some hope of creating a neater transition animation where the user would tap in that input, it would transition to the top of the screen while the rest of the background faded to the search UI. However, given that the longer term vision for the UX is not set for the next big release, it might make sense to just move away from an input field for that piece of the UI.

Comment 3

[Martin Shuman [:Marty]]

This issue does NOT occur on Flame 2.1 builds.
The keyboard only appears once, after the screen has transitioned to the Search screen.

Environmental Variables:
Device: Flame 2.1 (319MB)(Full Flash)
Build ID: 20150507001202
Gaia: b4a03b7ee61de5a479b3cf0916f47e91a43b0f50
Gecko: 4493015380ab
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 34.0 (2.1)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 4

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Regression of basic email feature. NI component owner if this should block 2.2

Comment 5

[Teri Wen [:twen]]

Nominate for V2.2. Base on James' comment in comment 2, it might be worth fixing this early instead of next release. From user's experience, it looks slow and lagged.

Comment 6

[Dylan Oliver [:doliver]]

triage: This is an annoyance and would be nice to have a fix available, but this late in the release is not something we'd block on.

Comment 7

[James Burke [:jrburke]]

Some other background: this change in behavior is a result of fixing bug 1137395, which was uplifted for 2.2, and I believe is a worse issue than this fix, and this resulting quirk. We definitely should do something more here, but since that fix was targeted for 2.2 the goal was to not be too invasive in the fix for bug 1137395.

Comment 8

[Edward Chen[:edchen]]

[Edward - Response comment instead of Teri]

Hi James,

I have verified the ticket and the result seems good. If you think this is final fixing, please mark it to RESOLVED. I will to do verify and change to status. 

Thanks,
Edward


[Environment]
Build ID               20150521160241
Gaia Revision          1126d8bee559f7cde675df2fcc6c196da9cfeba1
Gaia Date              2015-05-21 21:23:56
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/3e737d30f842
Gecko Version          41.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  75
Firmware Date          Tue Jan  6 12:24:47 CST 2015
Bootloader             L1TC100118D0

[Result]
PASS

Comment 9

[James Burke [:jrburke]]

I would like to keep this open to track changing the search box in the message list to a non-input field, just to avoid the possibility of a temporarily shown keyboard. Not something for the 2.x releases, but something for the future releases.

Comment 10

[BMO Automation]

Firefox OS is not being worked on