Today, another funny adventure developing HTML/CSS applications for android... I built a simple application called wrapper that people can install on their device to run our HTML app. This wrapper is very useful as it can be deployed to the market place so that potential users can find it. This application consists of a simple Webview pointing to our service (a public URL basically). This seems quite straightforward from an developer perspective and you'd expect this to run straightway but... we experienced weird stuff (for a change...)
In the HTML app, we've got a login pop up with 2 fields (login/password) displayed on top of the page when the use clicks the big login button in the app. It seemed to be working fine in the device browser but not in the wrapper...(?!) The input fields were properly focused when the user taped on them though the device refused any input from the keyboard. Mmmmm... Doesn't sound good really...
Well, let's be honest, in this very case there is not a lot of options. I unluckily googled the problem and nothing interesting came out... So, I rolled my sleeves and broke down the HTML page to an absolute minimum in order to reproduce the bug and... I got to the source of the problem! Hence the following rule someone should send to Google so that they can fix the bug:
If in your page you've got a fixed positioned div with none-default positioned nested divs (i.e. absolute, fixed, etc.) any of the following absolute positioned div containing input fields will get the unexpected behaviour.
So, how can we fix it now? Actually, there is no real fix from my point of you as this is unsupported valid HTML/CSS but here's some ideas for you:
In the HTML app, we've got a login pop up with 2 fields (login/password) displayed on top of the page when the use clicks the big login button in the app. It seemed to be working fine in the device browser but not in the wrapper...(?!) The input fields were properly focused when the user taped on them though the device refused any input from the keyboard. Mmmmm... Doesn't sound good really...
Well, let's be honest, in this very case there is not a lot of options. I unluckily googled the problem and nothing interesting came out... So, I rolled my sleeves and broke down the HTML page to an absolute minimum in order to reproduce the bug and... I got to the source of the problem! Hence the following rule someone should send to Google so that they can fix the bug:
If in your page you've got a fixed positioned div with none-default positioned nested divs (i.e. absolute, fixed, etc.) any of the following absolute positioned div containing input fields will get the unexpected behaviour.
So, how can we fix it now? Actually, there is no real fix from my point of you as this is unsupported valid HTML/CSS but here's some ideas for you:
- Use static positioning inside absolute or fixed divs in your page. This is good practice anyway as this is easier to understand and lighter for the phone to render. Most of the time you can position your elements using extra divs + margin/padding auto, width %, etc.
- Put absolute divs containing input fields before the fixed div containing extra funny positioned divs (or put the fixed positioned divs at the end of the page if possible)
- Don't use fixed positioning if that's possible for you - this mostly depends on the client doesn't it?
Hopefully this will work. Please don't hesitate to comment on this as obviously I'd enjoy some feedback from you guys... Speak soon!
No comments:
Post a Comment