1093339 - [Email] After typing in a name and email address going to password page causes visual issue

Status: RESOLVED WONTFIX

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

Description

[[:RJ]]

Attachment: logcat_20141103_1441.txt

Description:
After typing in a name and email address going to password page causes screen to be cut in half for a few moments before the keyboard reappears.  


Repro Steps:
1) Update a Flame to 20141103001220
2) launch email app with one email already signed in.
3) Go to email settings > add new email.  
4) Type in name and email address > press next. 


Actual:
Visual issue occurs


Expected:
No visual issue occurs

Environmental Variables:
Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
Build ID: 20141103001220
Gaia: 027a7de0c95320cea0579bfd1a4ceef3e9038f34
Gecko: ffecb2be228b
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 34.0 (2.1)
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0


Repro frequency:75%
See attached: logcat, video clip:https://www.youtube.com/watch?v=8jkJM9gkBNM

Comment 1

[[:RJ]]

This issue Does not occur on flame 2.2 (319mb)(Kitkat Base)(Full Flash) 

 graphic issues does not occur

Flame 2.2


Device: Flame 2.2 Master (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141103040202
Gaia: bc168c17474dabbcceaa349e9bc7c95654435aec
Gecko: 5999e92e89ff
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 36.0a1 (2.2)
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0

or  2.0 (319mb)(Kitkat Base)(Full Flash)
the page giving error did not exist in this version 
 
Flame 2.0

Device: Flame 2.0 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141103000201
Gaia: 7b8df9941700c1f6d6d51ff464f0c8ae32008cd2
Gecko: 82a6ed695964
Gonk: 48835395daa6a49b281db62c50805bd6ca24077e
Version: 32.0 (2.0)
Firmware Version: v188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 2

[James Burke [:jrburke]]

This happens because we are blurring any input field as part of the page transition, to avoid the keyboard staying around too long, fix tracked in bug 1073788.

In general, I have wanted a better transition with the keyboard, where we wait until it is hidden, then do the transition to the next card. Ideally there would be some event we could register for keyboard visibility, and key off of that, but in the absence of that, we could just use a setTimeout guess at the usual transition time.

Internal dev notes: this means cards._showCard could complete its work asynchronously. Need to measure its impact on things like "immediate" transitions, and for any code assuming that the showCard is a more immediate action.

If there was a magic system fix for this where they made this sort of animation while animating the keyboard away smoother looking, that would be great too, and likely more applicable for other cases outside of email.

Comment 3

[Joshua Mitchell (Inactive)]

Is the fix tracked in bug 1073788 responsible for this bug not being 2.2 affected and if so are there plans to uplift that fix to 2.1?

Comment 4

[Joshua Mitchell (Inactive)]

striking regression keyword - just noted comment 1 that says  "2.0 (319mb)(Kitkat Base)(Full Flash)
the page giving error did not exist in this version "

not really a regression if the feature was not in that version

Comment 5

[James Burke [:jrburke]]

Applying the patch in bug 1073788 would probably help for 2.1, but I would need to apply it for sure and test. If this seems like something that would get approved for 2.1 then I can look more into applying a patch.

I was hoping to get to really smooth keyboard out, then card animation by going the extra steps in comment 2. Even with bug 1073788 I think we can do better long term.

Comment 6

[Joshua Mitchell (Inactive)]

NI to email owner to making a blocking call

Comment 7

[Edward Chen[:edchen]]

I cannot reproduce in my device, I will keep going to trace this issue.

Comment 8

[BMO Automation]

Firefox OS is not being worked on