Select on Android 2.2/2.3 not working with fixed positioning #3712

Closed
felipegs opened this Issue Mar 2, 2012 · 38 comments

Comments

Projects
None yet
9 participants

felipegs commented Mar 2, 2012

On select box(native) on android you need to click twice to show the options.

Which version of Android, and what browser? Which version of jQM? Are you using jQM with PhoneGap or on its own?

FWIW, I can't reproduce this problem with the stock Android 4 browser, mobile Chrome beta, or HTC's version of the stock browser for Android 2.3.5.

Contributor

Wilto commented Mar 3, 2012

@felipegs Please submit a reduced test case using this template: http://jsbin.com/omacox/edit

felipegs commented Mar 3, 2012

Tested on Android 2.3.6 and 2.3.7 , I'm using jQM of branch master.
No, I'm not using PhoneGap
http://jsbin.com/umaseb/2/

felipegs commented Mar 3, 2012

It's a WebView app, but on native browser the same occur

Contributor

johnbender commented Mar 3, 2012

@felipegs

What version of Android are you testing on? I'll take a look at this come Monday.

felipegs commented Mar 3, 2012

Android 2.3.6 and 2.3.7

Contributor

johnbender commented Mar 5, 2012

@felipegs

Ugh, not sure how I missed that you had posted this earlier :(

I couldn't get select menus to come up at all in the example that @felipegs provided using my HTC Incredible running Android 2.3.5 or with a 2.3.3 virtual device. I started stripping things out of the example, testing as I went to see when things would start working again.

I finally got select menus to come back when I removed data-position="fixed" from both the header and footer (before and after). I then went back to the original example, made only that one change, and found that it also fixed the problem there.

Note: this bug also exists in v1.0.1.

Contributor

johnbender commented Mar 7, 2012

@scottjehl @Wilto

You guys might want to take a look at this one.

Wilto was assigned Mar 7, 2012

Contributor

Wilto commented Mar 7, 2012

Android.

I’ll dig into this first thing tomorrow.

Any news?

Contributor

johnbender commented Mar 13, 2012

@felipegs

I've labeled it as critical until we can sort out what the problem is. This will get handled one way or another before the 1.1 release.

Contributor

Wilto commented Mar 13, 2012

Sorry for the delay, guys. Looking into this issue now.

Contributor

Wilto commented Mar 15, 2012

Alright, after no small amount of investigation, I’ve figured out the issue here. This is a particularly strange Android bug, independent of jQuery Mobile—I’ve put together a test case here: http://wil.to/android-positioning

A fixed element that contains an absolute positioned element, which itself contains an absolute positioned element, will cause select menus on the page to stop responding altogether. So, in relation to jQM: a fixed header that contains a button that contains an icon, as in @felipegs’ jsbin ( http://jsbin.com/umaseb/2/ ).

By removing that nested absolute element (the red square in the demo link above) the select menu will work normally. Alternately, by removing the fixed positioning of the parent element—either by not disabling user-scalable in one’s viewport tag or by removing the fixed positioning.

Note that this behavior—intermittently working on the second tap but more frequently not working at all—seems to be limited to 2.3 in terms of select menus. With 2.2 nothing on the demo page responds to user interaction. 3.0 is unaffected (though, interestingly, interacting with the select menu on our Xoom running 3.0 causes the absolute positioned element to jump around by a few pixels, triggering nightmarish flashbacks to the days of IE6).

I’m working on this now, and may open a new issue related to this problem shortly. Just wanted to post an update for all involved.

@Wilto Something odd that's been bugging me since I last looked into this issue -- my current project uses a fixed header with an icon-containing button, but the pages with select menus have no problems working. The project is on 1.0.1 right now, and I'm in the midst of moving it to 1.1 RC1.

I'll try to get a simplified test case that mimics the page structure up on jsbin when I get a chance. FWIW my fixed header actually has three icon-bearing buttons -- two are children of a div.ui-btn-left and have data-iconpos="notext", and the third is a a.ui-btn-right with the header div as its parent. The header also contains a short h1.ui-title.

Contributor

scottjehl commented Mar 16, 2012

Adam, 1.0.1 didn't use position: fixed CSS, so that's probably why you saw no problem.

On Mar 16, 2012, at 9:48 PM, Adam Messinger wrote:

@Wilto Something odd that's been bugging me since I last looked into this issue -- my current project uses a fixed header with an icon-containing button, but the pages with select menus have no problems working. The project is on 1.0.1 right now, and I'm in the midst of moving it to 1.1 RC1.

I'll try to get a simplified test case that mimics the page structure up on jsbin when I get a chance. FWIW my fixed header actually has three icon-bearing buttons -- two are children of a div.ui-btn-left and have data-iconpos="notext", and the third is a a.ui-btn-right with the header div as its parent. The header also contains a short h1.ui-title.


Reply to this email directly or view it on GitHub:
#3712 (comment)

@scottjehl I know, but when I altered @felipegs's test case to use 1.0.1 I could reproduce the same problem he described on my HTC Incredible running 2.3.5 and an emulated device runnning 2.3.3: http://jsbin.com/umaseb/22

Could there be something else at work here besides position: fixed?

Contributor

johnbender commented Mar 16, 2012

I believe @Wilto has got this sorted but we'll need some more testing, maybe he can comment.

Contributor

Wilto commented Mar 16, 2012

Hey, sorry, should’ve referenced this issue in the commit message: there is a fix in master, but I can’t guarantee it’s going to cover every possible case. After many, many hours of testing and attempts at a fix, I’ve managed to turn up a particularly nasty Android bug pertaining to fixed positioning.

While it’s a decent implementation of fixed positioning itself, Android 2.2/2.3’s implementation of position: fixed is so fundamentally broken as to potentially render the surrounding page inoperable to the end user. This is most glaring in the case of form elements—select menus in particular, it seems—which will either require multiple taps before they fire correctly, or won’t fire at all. On Android 2.2, this behavior extends as far as entire pages: tapping form elements and links, highlighting text, etc. simply will not work with some combinations of CSS and markup, and it’s impossible to nail down a fix given the number of ways this can be caused.

One statistically significant trigger I’ve turned up in every example of this bug (though not in every case) is: an absolute positioned element as the child of a fixed element, anywhere on the page. I’ve put together a test case: http://wil.to/android-positioning/

Unfortunately, that means our header buttons with icons will trigger the issue. In many cases, adding some form of content to icon solved this problem, nonsensically (commit af46c6c uses non-breaking space like it’s 1999). While we work on a long-term solution, I’m currently updating the documentation with some of the “gotchas” I’ve turned up. There are several other triggers: for example, an absolute positioned image within a fixed element with an explicit height or width set in CSS or an invalid source will cause this issue. A fixed element anywhere on a page will also cause some CSS transforms to fail completely if the parent of the fixed element doesn’t have an explicitly set opacity.

I’ve had a fun couple of days.

I’m likely going to close out this issue soon, and reference it from a larger “rethink fixed positioning in Android 2.2/2.3” issue. In the meantime, I really appreciate your patience on this. It’s a big one.

For my particular use case, the new fix is working great in Android 2.2 & 2.3. Thanks!

Contributor

toddparker commented Mar 22, 2012

Closing as resolved.

toddparker closed this Mar 22, 2012

It was resolved? I get the last version from master and it still occurs

Contributor

toddparker commented Mar 22, 2012

Sorry, @Wilto will post more details here in a bit - I thought that already happened when I closed this. The short answer is that we were able to get selects in the page to work fine on Android 2.x with fixed toolbars by injecting a blank space into any icon div inside out button to work around Android's super buggy behavior. It seems that asking Android to support selects inside a fixed header isn't going to be possible. We're planning on adding info in the docs today about all this, but please chime in with what you're seeing.

Great work guys!

Contributor

Wilto commented Mar 22, 2012

👍

@gseguin gseguin pushed a commit to gseguin/jquery-mobile that referenced this issue Mar 23, 2012

@Wilto Wilto Closes #3712 - Updated documentation with several caveats about fixed…
… headers/footers in conjunction with form elements and various user styles.
467a465
Contributor

rbdcti commented Mar 23, 2012

Given the degree of issues that android 2.2/2.3 has with fixed headers/footers, is there a way to just disable fixed positioning for 2.2/2.3? I'd like to have a quick way to turn that off if it becomes a problem.

Contributor

toddparker commented Mar 23, 2012

It wouldn't be too hard for you to use a bit of UA detection to shut off fixed toolbars (or revert to the older polyfill behavior) in Android 2.x. We don't currently have an option to flip this switch because it's not the type of thing we'd want to have in the API. The closest we came to this was using a feature detect for 3D support to catch Android (and other) poorly performing platforms.

Contributor

rbdcti commented Mar 23, 2012

@toddparker ok, that's the approach I was planning to take. just wanted to make sure there wasn't something built-in before I reinvented the wheel. Thanks, and thanks for all the hard work especially with the transitions and fixed positioning!

Contributor

toddparker commented Mar 23, 2012

Our pleasure. If you work out an approach, post a link to the gist and/or demo page and we can link it up from the docs.

Contributor

scottjehl commented Mar 23, 2012

best way is probably to override the supportBlacklist with whatever function you prefer.

You can bind to mobileinit and override the option like this:

$.mobile.fixedtoolbar.prototype.options.supportBlacklist = function(){
  //to blacklist a browser, return true
};

I'd suggest copying the existing function and modifying the Android part to include 2.3 and under.

If you'd rather not copy all of it, you could also monkey patch your own addition on top of the supportBlacklist. Something like..

var oldSB =  $.mobile.fixedtoolbar.prototype.options.supportBlacklist;
 $.mobile.fixedtoolbar.prototype.options.supportBlacklist = function(){
    //add logic here for additional blacklisting, return true to blacklist

    // call the former blacklist
    oldSB.call( this );
};

Hope that helps!

On Mar 23, 2012, at 9:51 PM, Todd Parker wrote:

Our pleasure. If you work out an approach, post a link to the gist and/or demo page and we can link it up from the docs.


Reply to this email directly or view it on GitHub:
#3712 (comment)

jabeer commented Jun 19, 2012

The issue is because of the Webkit-transform css. I have removed the webkit-transform and its worked perfectly.

Contributor

johnbender commented Jun 19, 2012

@scottjehl @Wilto

Any thoughts on the transform? I'm under the impression that it's used to pull the navbar down from the top but I might be mistaken.

Contributor

toddparker commented Jun 21, 2012

@jabeer - Can you point us to the line number with the transform you're referring to here?

Contributor

collinforrester commented Nov 15, 2012

@jabeer @johnbender

Hey, I realize this issue is kind of old.. does any one have any more progress/workarounds for it? We're trying to do an absolute positioned select element and it doesn't work in android 2.3.x.

Contributor

toddparker commented Nov 15, 2012

@collinforrester - From all the research we've done into this topic, selects menus are just incredible brittle and break with any number of CSS properties in play including position:fixed. See: scottjehl/Device-Bugs#3

We have recently landed a bunch of improvements for fixed header that will ship with 1.3 but you just need to be careful about fixed and test thoroughly.

@ghost

ghost commented Dec 19, 2012

To my experience select elements are killed on android < 2.3.5 by any element in the parent hierarchy that would trigger GPU acceleration, like any translate3d property for exemple.

Contributor

toddparker commented Dec 20, 2012

When developing panels for 1.3, we ran into this issue again because we use translateX for animating them and fixed positioning. That broke selects in Android 2.x. To work around this, we used the same 3D support test as page transitions to not apply these rules to non-3D browsers like 2.x.

Happy to report that selects seem to work well in the new panels.

Contributor

collinforrester commented Dec 20, 2012

I ended up looking into how you guys did it for the panels and that solution end up working for me as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment