currently, when is possible scroll in the new message composer, input message field may be hidden by the keyboard. See image attached

Marking UX-P2 ("should fix for release")

Usability issue with not just email, but in general; sometimes you have to scroll to see the field before typing anything in.

This isn't just for email, it happens in browser as well as other forms. changing the title and moving to keyboard.

Triage: BB+, P3, C4 - very annoying for almost any input.

Does anyone have reliable STR for this? Seems strange to me marked as bb+ being such a vaguely defined problem.

I agree with Tim. By what criteria can we tell if this bug is fixed?

1) Going to http://people.mozilla.org/~nhirata/html_tp/formsninput.html 2) have one of the fields to click on in the lower portion of the screen 3) click in the input Expected: field ends up being pushed by keyboard Actual: field doesn't move, keyboard lays on top Note: work around: to scroll the field, and look for the blinking cursor or typed info.

Naoki: can you post a screenshot of this? Is onlythe "word suggestion" part of the keyboard overlapping or the whole keyboard?

I can reproduce two different bugs on this page. - the URL bar show/hide logic fights gecko's scroll-into-view logic. This can be seen by trying to focus the textarea at the bottom of the page when at natural zoom level. I couldn't find reliable STR. - gecko doesn't know to scroll into view zoomed content. This doesn't reproduce 100% either (depends on the scroll offset gecko chooses), but zooming far in and moving an input field to the bottom of the screen, then focusing it, will reproduce.

(In reply to Chris Jones [:cjones] [:warhammer] from comment #9) > I can reproduce two different bugs on this page. > - the URL bar show/hide logic fights gecko's scroll-into-view logic. This > can be seen by trying to focus the textarea at the bottom of the page when > at natural zoom level. I couldn't find reliable STR. Yes, I've seen that, too. Also, if you click the password field and then the "User" field at the bottom it gets overlapped by the word suggestion bar because we don't get a resize event for that.

The whole keyboard is shown over the field. My steps are 100 % reproducible. It's best seen with a video instead of a screenshot: http://www.youtube.com/watch?v=zbvyeHKWJ3w&feature=youtube_gdata_player

I also find that even when the field _does_ reposition itself to remain visible, it takes +1000ms to do so. There's a pause, and then it suddenly snaps into view. The resulting feel is extremely unresponsive.

(In reply to Josh Carpenter [:jcarpenter] from comment #12) > I also find that even when the field _does_ reposition itself to remain > visible, it takes +1000ms to do so. There's a pause, and then it suddenly > snaps into view. The resulting feel is extremely unresponsive. The 1000ms is due to round trip time of the inter-process communication, and other factors (IPC shouldn't take that long). (changing component given the fact this is a gecko/b2g/mozkeyboard bug)

Is this still invalid? Thanks!

Hi Tiffanie, I can repro this bug on latest Flame KK v2.5&2.6 and Aries KK v2.5&2.6 by the STR in comment 7 and comment 9. I am not sure whether this bug is still invalid, but it expects that the input field should not be covered by keyboard as user experience. Could you please help confirm this? Thank you. --------------------------------------------------------------------------------------------------- Actual results: When the browser search bar is not hiden, inputting some characters into the textarea at the bottom, the input field doesn't move to display the inputted characters which is covered by keyboard. Please see attachments: Flame_v2.6.3gp and logcat_1901.txt. Reproduce rate: 10/10 Device: Flame KK 2.5 512mb (affected) Build ID 20151119161153 Gaia Revision 28d63cf3bdc4417f7ad8cab2230f096bf9f6d3b5 Gaia Date 2015-11-17 07:35:12 Gecko Revision http://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/497118efc1414c2825a8bd17b38721888c3875ca Gecko Version 44.0a2 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.worker.20151119.152146 Firmware Date Thu Nov 19 15:21:56 UTC 2015 Firmware Version v18D v4 Bootloader L1TC000118D0 Device: Flame KK 2.6 (master) 512mb(affected) Build ID 20151119224634 Gaia Revision 94a821b49f4dca3f9321cd80e13c44c4a6696952 Gaia Date 2015-11-19 15:35:33 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/cc325db44f6f8a58604d60b746c140e73f3d8216 Gecko Version 45.0a1 Device Name flame Firmware(Release) 4.4.2 Firmware(Incremental) eng.worker.20151119.220436 Firmware Date Thu Nov 19 22:04:46 UTC 2015 Firmware Version v18D v4 Bootloader L1TC000118D0 Device: Aries KK 2.5 (affected) Build ID 20151119161838 Gaia Revision 28d63cf3bdc4417f7ad8cab2230f096bf9f6d3b5 Gaia Date 2015-11-17 07:35:12 Gecko Revision http://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/497118efc1414c2825a8bd17b38721888c3875ca Gecko Version 44.0a2 Device Name aries Firmware(Release) 4.4.2 Firmware(Incremental) eng.worker.20151119.152025 Firmware Date Thu Nov 19 15:20:33 UTC 2015 Bootloader s1 Device: Aries KK 2.6 (master)(affected) Build ID 20151120061630 Gaia Revision 94a821b49f4dca3f9321cd80e13c44c4a6696952 Gaia Date 2015-11-19 15:35:33 Gecko Revision https://hg.mozilla.org/mozilla-central/rev/3835b568092ae3b71adc931d24928670ad7141a7 Gecko Version 45.0a1 Device Name aries Firmware(Release) 4.4.2 Firmware(Incremental) eng.worker.20151120.052332 Firmware Date Fri Nov 20 05:23:39 UTC 2015 Bootloader s1

Yep, we expect the field to scroll into view more rather than remaining partly obscured by the keyboard. Thanks for testing this out Shally!

Firefox OS is not being worked on