Closed seantbrady closed 13 years ago
Same issue applies to text inputs
Added a JSBin version of this code for easier testing: http://jsbin.com/arehu4/edit
I'm wondering why there is this pre-condition: 1) scrolling/dragging is disabled
...is that a custom thing for your app? Disabling scrolling is a pretty dangerous thing to do. I'm guessing that the header is still there, but that the browser's auto-scroll for the the select happens, it leaves you at a different scroll position and since you've disabled scrolling, you can't get back to it.
Actually, in iOS, if you tap on the top bar (where the clock is) to initiate the "scroll to top of page" gesture, the header re-appears (i.e. scrolls into view).
Closing since this doesn't seem to be an issue, everything is working as intended.
Thanks for the quick feedback. After further consideration, I realize that I crossed some wires in my assumptions. My assumption was that "no scroll" was a common/supported approach by jQuery Mobile. Upon review, I realize that this approach is actually referenced by PhoneGap docs -- not jQuery Mobile. I understand the browser behavior that you are describing and will just plan to use the silentscroll onblur workaround that I described -- at least for iOS.
Agree with closure. Keep up the great work!
Environment: 1) iOS Safari Browser 2) jQuery Mobile 1.0a3
Pre-conditions: 1) scrolling/dragging is disabled 2) select input field has data-native-menu="true" attribute 3) page content fills most of screen real estate
Expected Behavior: 1) Header is visible before and after use of native select menu
Actual Behavior: 1) Page scrolls to hide header after use of native select menu 2) Since scrolling is disabled, the user can no longer use the header
Workaround: 1) Add silentScroll onblur() of select input field