You can clone with
HTTPS or Subversion.
<form action="#" method="post">
<label for="key" class="ui-hidden-accessible">Activation Key:</label>
<input type="text" name="key" id="key" value="12345-12345-123456" placeholder="Enter your activation key" maxlength="18"/>
<div data-role="popup" id="popup" class="ui-content" data-position-to="window" data-theme="e" data-overlay-theme="a">
This popup is on a page with a text input and an anchor with data-role of 'button'. When the popup gets popped, it shows behind both the button and the input on a Galaxy S3 running Android 4.0.4, however on a Nexus N7, iPhone 4S, and desktop browsers it shows correctly.
Reproduced here: http://jsbin.com/welcome/29453 - this is with /mobile/latest/jquery.mobile.js
In Android ICS some z-index bugs show up when there is an element with position: fixed; on the page. We made changes to the popup widget to avoid those issues.
When testing your JS Bin test page I saw the bug. However, when I tested your code, including custom CSS and JS, on my local server the problem was gone. Difference: no "Edit in JS Bin" element at the right top with position: fixed;.
My device is on Android 4.1.1 so I could only test on the SDK. Do you see the issue on your S3 when testing on your server instead of using JS Bin?
Ahhh, you might be on to something there. The logon page where the issue is being encountered has a div that's position:fixed with some other styling in order to keep it stuck (vertically and horizontally) to the second of the screen.
Yes - the issue was originally raised on an S3 with my code and styling, and taking the position:fixed off the div makes the popup show on top of all other elements.
Other than removing the fixed positioning which I need on that page, is there any other workaround or fix?
A workaround is to set z-index 2 (or anything between 2 and 1098) for your element with fixed positioning and set position fixed for the popup overlay (selector: #IdOfYourPopup-screen).
I think there was a particular reason we used position absolute for the overlay and not fixed, but I can't recall at the moment. So you really would have to test this thoroughly.
Other solution is to just set z-index 1100 for your element with fixed positioning. Downside is that the element will be on top of the overlay.
I am closing the issue because this is about a browser bug that we can't fix.