Home/ Questions/Q 7553781
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-30T11:09:17+00:00

I was delighted to discover that Android 2.2 supports the position:fixed CSS selector. I’ve

  • 0

I was delighted to discover that Android 2.2 supports the position:fixed CSS selector. I’ve built a simple proof-of concept, here:

http://kentbrewster.com/android-scroller/scroller.html

… which works like a charm. When I attempt to add an INPUT tag to my header, however, I hit trouble. On focus, every device I’ve tried so far clones the INPUT tag, gives it an infinite Z-index, and repaints it on top of the old tag. The clone is in roughly the right position, but most of its parent’s CSS (including, of course, position:fixed) is ignored. The cloned INPUT tag is the wrong size and shape, and when I scroll the body of the page, it scrolls up and off the screen.

Once it’s off screen, hilarity ensues. Sometimes the device will force the scrolling part of the body back down so the cloned blank is back in view; sometimes the keyboard goes away even though the visible box seems to remain in focus; sometimes the keyboard cannot be dismissed even though the INPUT blank is clearly blurred. Here’s an example you can run on your Android 2.2 device to see what’s happening:

http://kentbrewster.com/android-input-style-bug/

Styling input:focus has not done the trick for me yet, nor have many different brute-force attempts to listen for focus() and blur() with JavaScript and do the right thing with focus and the keyboard.

Thanks very much for your help,

–Kent

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This will probably not be resolved until Android switches to using Chrome for its WebView. The current Android browser creates an Android TextView on top of the page when an HTML input field is focussed. Apparently they don’t style or position it correctly. You can see it go more wrong on pages that use contentEditable.

    The current Chrome-for-Android implements the WebKit IME interface, so input fields are drawn by WebKit (and lose some of the niceties of the Android TextView on ICS) and shouldn’t have issues like this.

    • 0