Android Browser Textarea Scrolls All Over The Place, Is Unusable

wild scroll input android

Remove the meta viewport tag from your markup and add this immediately after the opening body tag:

<script type="text/javascript">
<!--
    (function() {
        var meta = document.createElement("meta");
        meta.setAttribute('name','viewport');
        var content = 'initial-scale=';
        content += 1 / window.devicePixelRatio;
        content += ',user-scalable=no';
        meta.setAttribute('content', content);
        document.getElementsByTagName('head')[0].appendChild(meta);
    })();
//-->
</script>

This will give you the best experience on mobile (amazing image rendering too!). I noticed on my device (which isn't Android) I had some weird scrolling/zooming issues and this eliminates that. Let me know if it works :)

How can I prevent wild scrolling when a fixed position text input form field gains focus?

I managed to prevent the momentary overlay shift by setting outline: none on my input element.

I got the wild page scrolling and disappearing keyboard to settle down by setting overflow: hidden on the html body when showing the dialog, and then removing it again when hiding the dialog. This has a nasty side effect of resetting the page's scroll position, so I save it and restore it as necessary, and wrap all this hackery in conditionals so it only runs on Android. (I hope my Android users won't be too distracted when they see the page contents change beneath the semi-transparent overlay while the dialog is open.)

Interestingly, I was also able to prevent the wild page scrolling by catching the touchstart event on my overlay element and calling preventDefault(). This makes me wonder if all this madness was caused by a sequence of events like this:

• touchstart bubbles up to the document root
• browser sees touchstart where the duplicate input field was placed
• browser gives focus to the input field
• soft keyboard appears to allow typing in the input field
• viewport gets resized to accommodate the soft keyboard
• resized viewport during touch event looks like a touch drag to the browser
• spurious drag causes the page to scroll and dismisses the keyboard

I didn't end up catching touchstart to solve the problem, because it prevented the input field from gaining focus, and calling focus() from javascript just didn't work. I have read that the Android browser disables the focus() method on input fields, which would explain this behavior. Perhaps it does this because it wouldn't work with the duplicate text widgets it creates over the html-defined fields.

input textbox hidden behind keyboard on android Chrome

I was hoping for a CSS only solutions, but I don't think there is one. Gaunt Face's answer is a good way of doing it. Unfortunately in my case, this would require a few changes and has the possibility of breaking automation among other things (since the url has #targets added to it).

I solved this by changing the position type in 2 click handlers.

I have a click handler for any input/textarea field. In that click handler, I change the position style of the form container div to be static. Note this will push the footer to the bottom if the container field has a scrollbar. This, in my case is not a problem as when the keyboard pops up, only a couple of fields are visible. The user cannot visibly see any difference.

I have a second handler for when the user clicks out of an input field - page click handler - where I restore the the position type to absolute, making the page appear just as it was before.

This has one unintended consequence - The scroll position is lost. I fixed this by getting the offset of the input field and calling scrollTop on the parent div with that offset, thus restoring the position.

I've seen a few questions about this, but did not find an answer. I hope this helps someone.

Can webpage be aware of android virtual keyboard

From what I've seen, when the virtual keyboard pops up, the page is not resized (to fit the smaller view-area, visible with the virtual keyboard on). So this will not give your page a hint on whether the keyboard is up or not. And I don't really think there's another way of getting that info either.

You can make a setup where you look at the user agent, and if it's for an Android phone, when the user clicks various text input elements, you make some room at the bottom of the screen for the virtual keyboard.

For the size of the keyboard, the stock Android might have a standard size or ratio or percentage, but combined with the fact that there are a lot of Android mods out there plus the fact that there are multiple screen resolutions and screen ratios out there translates into not being able to have a fixed number for this (like keyboard is x pixels tall or y percent of screen estate). However, you can make a common sense assumption that it takes about half of the screen at the bottom.

So basically, using the user agent, screen resolution and the fact that the user has "clicked" on a text input field, you can get a decent idea of whether a virtual keyboard is displayed or not, and how much room to leave aside for it.

Scrollable vertically and horizontally EditText that doesn't automatically break text to the next line

EditText actually has scrolling already built in, so you don't have to use a ScrollView. The only thing is that it doesn't support flings.

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical">

    <EditText
        android:id="@+id/some_edittext"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:gravity="top|left"
        />

    <Button
        android:id="@+id/submit_button"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="Submit"/>

</LinearLayout>

To stop the automatic wrapping, you can activate horizontal scrolling:

EditText editText = (EditText) findViewById(R.id.some_edittext);
editText.setHorizontallyScrolling(true);
editText.setMovementMethod(new ScrollingMovementMethod());

QML TextArea scroll events

Textarea inherits from ScrollView which has a Flickable item to control the visible area. Such an item is available as the (readonly) property flickableItem. Among the other properties Flickable provides the contentY:

These properties hold the surface coordinate currently at the top-left
corner of the Flickable. For example, if you flick an image up 100
pixels, contentY will be 100.

Hence you can check this property change and, once a certain threshold is reached, update your text. Mind that you should adjust the contentY after setting the text, to simulate the addition. Otherwise the text shown will be exactly the one just added. A nice approach, as proposed by the OP, would be to save the original contentHeight and set the contentY to the difference between the updated contentHeight and the saved one - also considering the applied threshold.

import QtQuick 2.4
import QtQuick.Window 2.2
import QtQuick.Controls 1.3

Window {
    visible: true
    width: 400
    height: 200

    TextArea {
        id: chat
        anchors.fill: parent
        property int threshold: 10

        text: "Current\ntext\n\\to\nmove\ndown\ndown\ndown
               \ndown\ndown\ndown\ndown\ndown\ndown\ndown"
        Component.onCompleted: cursorPosition = text.length

        flickableItem.onContentYChanged: {
            if(flickableItem.contentY <= threshold) {
                var oldHeight = flickableItem.contentHeight
                text = "Lorem ipsum dolor sit amet, consectetur adipiscing elit,
                            sed do eiusmod tempor incididunt ut labore et dolore magna
                            aliqua." + text
                flickableItem.contentY = threshold + flickableItem.contentHeight - oldHeight  // leave flickable in old position
            }
        }
    }
}

Fixed element problem in mobile browser when keyboard get on screen

Unfortunately that's the expected behavior of Safari in iOS when using fixed elements on the page.

Take a look at this article providing a possible solution:
https://medium.com/@im_rahul/safari-and-position-fixed-978122be5f29

---

Related Topics