Mobile Safari (Whyyyy?!)

Have you ever felt the fear when someone from the Executive team finds a bug on your site? I have. Recently. It’s all because of mobile Safari.

I’m one of the engineers on the Listings team at Eventbrite. We work on the event page, which I like to think of as the heart and soul of Eventbrite. All was well in the land of Listings, until one day someone on our E-team noticed while scrolling the event page, the “Get Tickets” button required two clicks to get to the ticket purchase modal.


And thus began the month long saga of finding a solution to this problem. It turns out that the normal behavior of mobile Safari is to shrink the top address bar and hide the bottom navigation bar on scroll. When an approximately 44px high space on the bottom of the window is touched, the bottom navigation bar reappears.

I started by doing a ton of research on the problem, but was only able to find a series of unanswered questions:

Note: You’ll notice me attempting to collect Stack Overflow points on all of these posts after finding a CSS solution.

Even Airbnb, whom I consider web design pioneers, seemed unable to find a code-based to this problem. They instead use a floating button, avoiding the dead space the mobile Safari menu created.


The Eventbrite design team was having none of that, but we quickly realized that the dreaded floating button might be our future if I wasn’t able to find a solution. Here were some of the designs that we considered should I fail in my quest:


UGH. No one was happy about that.


Now What?

I thought it was a hopeless, but then a determined designer on the team discovered that the JackThreads website forced the mobile Safari bottom navigation bar to always show.


How?! I scrambled to figure out how they were forcing the nav to show, but couldn’t pinpoint the fix. I spent a bunch more time researching this new potential solution. Desperate to find an answer, I even tweeted at JackThreads!

After much blood, sweat, and tears (or dogged investigation), I stumbled onto a CSS solution. If I set the following styles onto an element containing the button – in our case, <html> and <body> – the button would remain at the bottom of the page and the Safari nav would remain.

/* Allows content to fill the viewport and go beyond the bottom */
height: 100%;

/* Allows you to scroll below the viewport; default value is visible */
overflow-y: scroll;

/* To smooth any scrolling behavior */
-webkit-overflow-scrolling: touch;


Success! Or Not…

This solution interfered with our workaround for `position: fixed` elements on, you guessed it: mobile Safari.

Our pop up ticket modal was using the fixed-fixed workaround described above and my newly found solution was making the modal impossible to use to access the ticket purchase flow.


To sidestep this conflict, we tacked onto existing JavaScript that checks if the modal is shown on the page. That way, our CSS solution would only be applied to our event pages when the modal was hidden.


Last But Not Least

Unfortunately, we also discovered that our solution interfered with the window height calculation on scroll in iOS Chrome. When scrolling down the page in iOS Chrome, the “Get Tickets” button would disappear further up the screen. Only when scrolling was completed would the button appear at the bottom of the page.


Turns out iOS Chrome uses an older Apple browsing engine which included outdated details like the one causing our button move with a scrolling page.

Our CSS only solution targeted any WebKit browser. Back to the drawing board!

In the end, because we couldn’t reliably target all versions of iOS Safari (and not iOS Chrome) with CSS only, we chose a JavaScript based solution to find the user agent, then target and apply the CSS styles mentioned above.

We did it! Check out the results:


7 thoughts on “Mobile Safari (Whyyyy?!)

  1. Hi, thanks for detailing your struggle. I came across exactly the same iOS Safari issue and you helped me solve my problem.

    It did create another problem though. If I use the meta tag so that when users ‘Add To Homepage’ they get a full-screen app rather it just appearing in the standard looking Safari browser. Unfortunately the fixed positioning doesn’t work any more when you open it up from the new homescreen icon. The fixed areas scroll up and down when you lift your finger off after scrolling.

    I noticed you don’t have the ‘web-app-capable’ meta tag on Eventbrite. Is this because you didn’t want a full-screen iOS app or because you encountered similar problems too?


  2. Thank you for taking the time out to write this article and provide the GIFs! You’ve just saved me a lot of time researching and presenting why this solution might be tricky. Fantastic!

  3. Thanks soooo much for this! Struggling with the same issue here and scratching our head on how to work around it.
    Very much appreciated.

  4. iOS Safari really is the new IE8. It’s so tiring constantly having to find solutions to its numerous rendering inconsistencies. Pages are increasingly becoming javascript hackfests as webdevs desperately try and implement workarounds for things that work on every other browser.

Leave a Reply

Your email address will not be published. Required fields are marked *