Fixed Persistent Header and Scroll to Focussed Input Fields

Fixed persistent header and scroll to focussed input fields

You should check out this answer -
fixed position div freezes on page (iPad)

And here is a really good article by Brad Frost that I've desperately read through a few times myself over the years hoping for an answer to this dilemma. -
https://bradfrost.com/blog/post/fixed-position/

It answers what you're asking pretty thoroughly. Fixed positioning is broken on mobile, it can be massaged with JS, but not really even completely fixed.

You can fix one problem, your "header glitch" in demo 2 is just the fixed header hiding behind the absolutely positioned #page. Give your header a z-index of 1+ and that will fix that issue.

As far as the header losing positioning when the keyboard comes in; I'm not even sure that's actually a bug, just the nature of the browser. What's happening is that the keyboard is gaining focus, at that point you're now dealing with ios' UI not the web browser and everything in the background is freezing (including fixed positioned elements and all other elements). Notice how the entire screens scrolls, that's not a web feature it's a built in browser feature.

focus on input in sticky bar force page to scroll to top

It turns that there is a bug with position fixed in iOS 8+

Here's what I used to fix the problem: https://gist.github.com/AlexanderOMara/8747f59b6450878e78c7

How can I prevent wild scrolling when a fixed position text input form field gains focus?

I managed to prevent the momentary overlay shift by setting outline: none on my input element.

I got the wild page scrolling and disappearing keyboard to settle down by setting overflow: hidden on the html body when showing the dialog, and then removing it again when hiding the dialog. This has a nasty side effect of resetting the page's scroll position, so I save it and restore it as necessary, and wrap all this hackery in conditionals so it only runs on Android. (I hope my Android users won't be too distracted when they see the page contents change beneath the semi-transparent overlay while the dialog is open.)

Interestingly, I was also able to prevent the wild page scrolling by catching the touchstart event on my overlay element and calling preventDefault(). This makes me wonder if all this madness was caused by a sequence of events like this:

• touchstart bubbles up to the document root
• browser sees touchstart where the duplicate input field was placed
• browser gives focus to the input field
• soft keyboard appears to allow typing in the input field
• viewport gets resized to accommodate the soft keyboard
• resized viewport during touch event looks like a touch drag to the browser
• spurious drag causes the page to scroll and dismisses the keyboard

I didn't end up catching touchstart to solve the problem, because it prevented the input field from gaining focus, and calling focus() from javascript just didn't work. I have read that the Android browser disables the focus() method on input fields, which would explain this behavior. Perhaps it does this because it wouldn't work with the duplicate text widgets it creates over the html-defined fields.

---

Related Topics