Created attachment 8516294 [details] 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
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
QA Whiteboard: [QAnalyst-Triage?]
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.
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?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(jrburke)
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
status-b2g-v2.0: unaffected → ---
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.
NI to email owner to making a blocking call
I cannot reproduce in my device, I will keep going to trace this issue.
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.