798695 - Can't see body <textarea> after opening keyboard

Status: RESOLVED DUPLICATE of bug 785663

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

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

STR
 (1) Start composing an email
 (2) Focus body <textarea>

The VKB pops up and completely obscures the <textarea>.  It's not possible to scroll the <textarea> into view.

After entering the first letter, the <textarea> becomes partially visible, but it's still partially obscured.

Comment 1

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

There may be a few things at play here:

- Because of the way our card display and animations still work (bug 799682 to fix that for acceleration purposes), we need to manually resize the cards when we get the resize event.  This may be hosing up the built-in scrollIntoView logic for the DOM node.

- Some platform issues maybe.  I know I've had trouble with the cursor not painting on the first line or two of a textarea when the textarea is empty on b2g-desktop builds some weeks ago.

- General UX complications.  Right now, I try and dynamically size the textarea so that there is no scrolling within the textarea, just scrolling of the entire page.  The explicit goal there is to avoid the scrolling-an-iframe-with-a-scrolling-page problem.  The textarea is dynamically sized so it tries to always have at least one line more than the text in there; I think the base case is 2 lines tall so the click region is not super small.  I'm not sure that the layout engine actually honors my request to make a super-tall textarea one a threshold is reached; there may be a system max-height CSS rule or something else capping us at some point.  I am verrrrry open to improvements in how to improve this.

Comment 2

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

I just realized that my quick hack with setting the height of the area only counts newlines, and does not compensate for line-wrapping.  I'm not sure if we can use scrollHeight in a textarea and just set the CSS height to deal with things, but that is quite possibly the better solution.

Comment 3

[Alex Keybl [:akeybl]]

blocking+ as a P2 because this is very user facing, but the feature is still functional (while confusing).

Comment 4

[Chris Peterson [:cpeterson]]

This bug is fixed by bug 785663:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3de447b1c396
https://hg.mozilla.org/releases/mozilla-aurora/rev/a498c73be0fa

Comment 5

[Dylan Oliver [:doliver]]

Clearing blocking flag based on dup.