Select Menus won't open when pages are within FORM element #2066

ryantofteland opened this Issue Jul 13, 2011 · 54 comments

I've recreated this issue on Android 2.2 and Android 2.3. It does not seem to be a problem on Android 2.1. I am using the default Android OS emulators provided by the Android SDK for testing:

The issue occurs when the data-role="page" DIVs are within a FORM element instead of directly within BODY. In my specific case I have a multi-page application where all pages are contained within a single FORM element. On Android 2.2/2.3 select menus will not open in this case. If I remove the FORM element, the issue goes away. This occurs when using both the default select menu as well as data-role="none".

This issue is similar to Issues #1051 and #1077 which have been closed. I can recreate this in both Beta1 and the current Latest build as of 7/12.

Test Page with FORM element (causes broken select menus on Android 2.2/2.3)

Test page without FORM (select menus work fine)


I just noticed Issue #2060 and this looks similar/related to that problem as well.


This should work as of Beta 2 - can you re-test and close if fixed?


This still appears to be an issue in Beta 2. I don't see any change in behavior. Here is a test page that will recreate it on Android 2.2 and 2.3 specifically using Beta 2:

The same page is also available pointing to the Latest jqm build here:


I can confirm that this bug still exists on Beta 2, testing on a Galaxy S with Android 2.2. Any idea if this problem will be fixed for the next Beta release?

@johnbender johnbender was assigned Aug 17, 2011

It's a high priority and will be fixed before 1.0.


Culprit commented out below. I'll need to talk with @toddparker about his tomorrow.

.ui-mobile [data-role=page], .ui-mobile [data-role=dialog], .ui-page { 
    top: 0; 
    left: 0; 
    width: 100%; 
    min-height: 100%;
    /* position: absolute; */ 
    display: none; 
    border: 0; 

There's the filed bug report.,html

And the jsbin to reproduce at a minimum. Now we need to find a workaround ...

♥ android


Wow - nice catch.


@scottjehl @toddparker @jblas


Wondering if anyone see's an issue there? [edit] It fixes the problem since, as described in the bug, its caused by a block level parent element with overflow-x: hidden.


@scottjehl @toddparker @johnbender

I gotta say that setting the ui-mobile-viewport (aka the body element of the document) to "inline" makes me a bit nervous. For one thing, it also means that folks won't be able to place background images on it since only block-level elements get that treatment. I forget, can inline elements have gradients too?

Does "inline-block" work too?


@scottjehl @toddparker @johnbender

... and then there's the fact that inlines are sized differently from block elements during layout/reflow.

@johnbender, you didn't see any noticeable rendering differences on iOS or any other platform?



We talked about this today and it doesn't look like we'll fix this before 1.0 just because of the semi-scary implications of setting inline on the mobile viewport. With that in mind, can you help me understand the reason why you have a form wrapping all your embedded pages?


Also wanted to note here that the following produces an alert on Android 2.2/2.3, so the click is being registered in the browser.

<!DOCTYPE html>
  <div style="overflow-x: hidden;">
    <div style="position: absolute">
      <select name="select-choice" id="select-choice">
        <option value="foo">foo</option>
        <option value="bar">bar</option>
        <option value="baz">baz</option>
  <script type="text/javascript">
    document.getElementById( "select-choice" ).addEventListener("click", function(){
@johnbender johnbender closed this Sep 1, 2011
@johnbender johnbender reopened this Sep 1, 2011

sigh wrong button


@johnbender, my application has a couple dozen form fields that I've broken down into 7 or 8 pages in a multi-step wizard type of approach. The full app comes down to the client on the initial request. The user then fills out each page (at which point all state is kept on the client). When they are finished I take the form and post it back to the server. Wrapping all of the pages in a single FORM element allows me to keep all of the input together on the client and prevents me from needing to go back to the server between each page request.

Also - the SELECT menus that I have right now are fairly small - so I've been able to work around this issue by using the "data_native_menu=false" option for the time being.


I seem to have a related issue. Not exactly the same - my data-role=page div is direct desc of body, & the first selectmenu on the page works. The ones after that doesn't though.

NOTE: The other (non-functional) selectmenus are being dynamically created based on the selection made in the first one (and some ajax), but I tested by creating one of them statically - still nothing. So I assume it's the fact that they're not the first on the page ...



That actually differs in an important way from our original bug report, can you post a jsbin or jsfiddle example here?


Here's a jsbin example:

The first selectmenu works. If you select something in it, a second one will be opened, which do not work.
(Android 2.3.3 only)


Any news on this issue? Is it clear from the jsbin example what happens?



I haven't had a chance to boil down your example to the actual cause as I was able to do with the original issue. Hopefully I'll be able to address it soon.


Thanks man - sorry for being so incessant ... deadlines. Shout if there's anything I can do to help.


This is still on our radar, but it's tricky to find a fix. Still looking at ideas.


Thanks a lot - much appreciated!


Yes, thanks for looking into this. I would like to add that in the way we architected our mobile app, we have a number of shared hidden variables (all with ids) that sit within a master form that is applied to all jQuery Mobile pages in our markup like so:

      <input type="hidden" id="one" name="one" value="1" />
      <input type="hidden" id="two" name="two" value="1" />
      <input type="hidden" id="foo" name="foo" value="1" />
      <!-- etc. -->
      <div data-role="page" id="Page1"></div>
      <div data-role="page" id="Page2"></div>
      <div data-role="page" id="Page3"></div>

So we would have to shift this to put a separate form inside each div (and somehow give the hidden variables unique ids inside each and change all of our JS that references those by id). So I'm just commenting to say that I'm looking forward to the solution. :)



It looks like you're running into the same issue. The stylesheet you've added includes

.ui-collapsible-content {
  position: absolute;

Which is nested under the ui content div with

.ui-content { 
  overflow-x: hidden; 

Quick note: I didn't see this problem in the 4.0 emulator.



If in the interim you can scope your selectors in two ways if you're working on the currently active page

$.mobile.activePage.find( "your selector" )


$( "your selector", $.mobile.activePage )

@ryantofteland, @toddparker, @jblas, @RAAK, @srkishy, and @gggit-esimon

After looking at a couple of workarounds for this issue, we'd like to ask you guys to try something for us. Add this style after the jquery mobile css:

form.ui-mobile-viewport { overflow-x: visible; }

That should correct the issue but you should be aware that we added that overflow to prevent the browser from scrolling horizontally when small adjustments to the children of the mobile viewport pushed it outside it's bounds.

Please report back if you run into issues or this doesn't solve the problem for you.

@Wilto Wilto added a commit that closed this issue Nov 1, 2011
@Wilto Wilto Fixes #2066 — Select menus now open normally on Android when the page…
… is wrapped in a form element. ♥ you, .NET.
@Wilto Wilto closed this in ab48625 Nov 1, 2011

Correction, we've added it to the library 👍


Chime in if you're seeing layout issues, especially horizontal scrollbars.


I am not seeing any layout issues on my app when adding 'overflow-x: visible' to my page.


@johnbender Thanks for this!

I'm still stuck at the same point, however (ie no change after add overflow-x: visible), but let me carefully go through everything you said, and see if I don't need to alter the workaround slightly for my case.



If you apply the same to your ui-content manually you should be fine. Eg,html

See the application of the overflow-x: visible to the data-role=content. Better would be to assign a selector that targets the page content like so:

#player div[data-role=content] { overflow-x: visible }

Though it should be noted that if you ever decide to namespace your data role attributes that style won't work/apply.


Great - got it! Was not thinking clearly ...

Thanks a lot!

I hear what you're saying on the namespace caveat - I'll address that, thanks.


Using the latest jquery mobile repository and adding "overflow-x:visible" to my data-role="content" div, I am still seeing this problem on my android phone. I also had a slight layout issue with a white bar appearing across my screen.


Ok, something isn't quite right. If you test the original jsbin using latest it's still not working on 2.3

I just added an inline style with this fix to the form tag and can confirm that this fixes it:

I can confirm that this CSS rule is here in structure.css in master:

But I don't see it if I open the minified latest js that is linked to in those 'bins:

So why isn't this showing up? It's in the source.


@srkishy For me this issue only manifested on a select that was within a container that I've positioned absolutely, with "position: absolute;"

If this is the same in your case, removing this, and then working your way downwards from there, might work. It did for me.


Turns out the latest js and css files are out of sync with the repo. Fixing now, issue should be fixed so this may just be a case of stale test files.


I can confirm that with the repo fix, the original test case is now fixed, however, the way I am using selects still does not work. I created a jsbin that mirrors the code we are using. I realize that it is extremely nested, but we are trying to utilize as much written code as we had on our normal web page for the mobile page. If anyone can see any fixes, I would greatly appreciate it.

JS bin example:


Woah, that is nested. I don't think we can do much right now to fix this, but we're looking at ways to be more flexible with nesting.


Understandable toddparker, I've done some messing around with it, and if we remove the table it actually works, so we're gonna try to figure out a way to remove it from our code, thanks for the help though and getting the fix in.

Edit: We were able to remove the table so now we officially have it working for our mobile site! Any chance that the current code will be in a release within the next two weeks?


phew, freaked me out this morning when my droid select menu's were acting funny/not working. the overflow-x property made it all better though, thank you for keeping this stuff documented!

UPDATE: this fixed our form on the home page, but the same form on a different page still reproduces the selectmenu bug. interestingly, our selectmenu bug is a "offset' bug, where clicking a select box, the values appearing are from 3 elements/selectmenus down. brand new showing today, the errors on both of these forms.

@timmywil timmywil pushed a commit to timmywil/jquery-mobile that referenced this issue Nov 5, 2011
@Wilto Wilto Fixes #2066 — Select menus now open normally on Android when the page…
… is wrapped in a form element. ♥ you, .NET.
@timmywil timmywil pushed a commit to timmywil/jquery-mobile that referenced this issue Nov 5, 2011
@johnbender johnbender added comment for Issue #2066 special case ec0b368

Sorry for my slow response - but things are looking good on my end after this fix. Thanks for taking care of this.


Sounds like the original issue is fixed, though @argyleink is still reporting an issue. @argyleink - can you look into your code and report back? I don't have a test page for your issue to confirm.


all my select menu's are behaving accordingly, thanks for following up =)

now i just need to find out why opening a select menu shifts my fixed footer to the right by 5px

@Wilto Wilto added a commit that referenced this issue Nov 8, 2011
@Wilto Wilto Additional work on #2066 — This change only applies overflow-x: hidde…
…n to body/div elements that receive the .ui-mobile-viewport class, as we can safely predict that style won’t interfere with native select funcitonality when attached to those elements. This will address the vast majority of use cases, and prevent this style from causing unpredictable Android issues in the event that the page is wrapped in an unusual element (a form, table cell, marquee tag, etc.).

This should officially be resolved by commit #8089317.

It seems setting overflow-x: hidden on certain types of elements were causing unpredictable issues in Android, in particular, with native selects. I’ve now ensured that only body.ui-mobile-viewport and div.ui-mobile-viewport (the vast majority of cases) will get that style. If the page is wrapped in a form, table, table-cell, etc.—any other sort of element, which could potentially trigger this issue—overflow-x: hidden will not be applied. This shouldn’t cause any issues for these users, apart from potentially introducing horizontal scrolling if elements are sized larger than the available viewport—pretty predictable behavior.

Since this is such a wide-spread and unpredictable issue, it would be great if the folks participating in this thread could grab the latest and see if they run into any strange issues.


Thanks a lot @Wilto, this fixed my issue (#2952) without causing any side effect.


all my selects are working as expected =)


Sorry to reopen! I'm actually trying to apply a flicker fix, and it seems to conflict with the select box. Someone posted a suggestion, which works great, but breaks select tags. The user "eehan" commented on the conflict as well.

Do you think there is a fix for both the flicker and the broken select, or should I chose one over the other?


Hello all,

Is there any hope for fixing this bug when the data-role="page" element is forced to be nested within another div? All our sites are on a shared platform that automatically inserts the outer divs.

I have added the following to my page:
form.ui-mobile-viewport, div.ui-mobile-viewport { overflow-x: visible; }

but I fear that may be somewhat dangerous.... Any suggestions?


Any of you come across the bug as it was reported upstream (to the Android Open Source Project)?

The problem is with certain form elements starting out life as children of hidden elements. Form elements that are "born in the light" have no issues, only those that are "born in shadow".

The work-arounds are:

  • never append form elements to hidden elements, or
  • tamper with form elements once their hidden ancestors are shown, to trigger a repaint

I’m not certain these overflow properties are necessary anymore, given some of the recent changes to page transitions—I can’t say I completely understand how they ties into Android’s bizarre issues with form elements, but I know they seem to be the cause of the problem.



I had problem with input type='tel' not showing numeric keyboard on android 2.3, offending line was tracked to above mentioned overflow property.


If you're getting this problem while using jQueryMobile, the solution is to set the data-native-menu attribute to false. Check item 18 here:

@AgDude AgDude referenced this issue in angular-widgets/angular-jqm Feb 8, 2014

feat(widget): select menu (native popup) #23

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