Created attachment 262961 [details] Screenshot #1 Original Bootstrap bug: https://github.com/twbs/bootstrap/issues/14975 This bug has also been reproduced on iOS 9.1 in the iPad Simulator. Steps to reproduce: (See the video attachment for proof) 1. Open http://output.jsbin.com/jinuda/1 in Safari on iPad Air 2 running iOS 9.0 2. Scroll to the bottom of the page 3. Tap the green button 4. Observe that a dialog appears (see 1st screenshot) 5. Tap the blue button to confirm that hit-testing of the button is working correctly. 6. Observe that an alert() box appears 7. Dismiss the alert() box 8. Tap the "Open this list" <select> menu 9. Observe that the dialog moves upward a bit (see 2nd screenshot) 10. Choose an option from the <select> menu so as to close the menu 11. Observe that the modal moves downward, back to its original position as in the 1st screenshot 12. Tap on the "Ut enim" text in the dialog. Expected results: Nothing should happen. Actual results: An alert() box is showing, indicating that the blue button was somehow clicked. It seems as if, for hit-testing purposes, the dialog didn't get moved back downward again in step 11. Also, if you tap on the blue button, the dialog closes as if you had tapped outside of the dialog.
Created attachment 262962 [details] Screenshot #2
Created attachment 262965 [details] Video of the bug being reproduced
The video can also be viewed at: http://gfycat.com/DampWaryEuropeanpolecat
<rdar://problem/23082521>
When you focus the list, we change the layout rect used for position:fixed elements. When it's unfocused, we don't undo that correctly.
Easy fix.
Created attachment 286608 [details] Patch
Comment on attachment 286608 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=286608&action=review > LayoutTests/fast/forms/ios/ipad/unfocus-inside-fixed-hittest.html:37 > + function getSingleTapUIScript(x, y) Don't love the 'get' prefixes.
https://trac.webkit.org/r204728