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.

ios-safari-button

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.

ios-safari-button-airbnb

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:

design-options

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.

ios-safari-button_jackthreads

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.

modal-issues

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.

SIGH.

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:

success

19 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?

    Thanks!

  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.

  5. With all of this work, and the technical debt (not too much, but also not none), I’d have just abandoned the design! I have to respect the dogged approach, though.

  6. Unfortunately it seems that this stops scroll events from being emitted. How do you still catch the scroll events e.g. for fixing the footers on scroll?

  7. It’s fairly late and I could be dreaming… but I just stumbled upon this after searching and then went off to try something. I seem to be able to stop it happening if I add another div after my fixed footer, 1px high.

    e.g.


    #my-fixed-footer {
    position: fixed;
    bottom: 1px;
    width: 100%;
    z-index: 10;
    }

    #my-fixed-footer-gutter {
    position: fixed;
    bottom: 0px;
    height: 1px;
    width: 100%;
    z-index: 5;
    }

    The height of my fixed footer is set by it’s contents, which are just 4 “col-xs-4” divs, containing icons.

    I’m so tired I can’t try this properly but wanted to post it…. debunkers welcome!

    • Lol, no way! That is awesome. I was trying to get your support team to put me in contact with someone from the engineering team, but it never happened.

  8. This article is old but it’s relevant as long as people are still looking for a solution to this.

    This has ALWAYS been my biggest issue with mobile Safari. Since the dawn of that particular bottom nav bar.

    My question though is: How is the 5th picture on the far right in the design options you laid out not EXACTLY the solution you ended up doing? It shows the navbar left up and your bottom fix still attached just above it.

    That’s exactly the solution you ended up finding on JackThreads yet in the article you mention how you were having NONE of the design options you laid out.

    Confusing…

  9. Amazing to find this post, but it looks like this may no longer work? Checking eventbrite on my (11.3 running) iPhone and I’m still seeing this issue. An added wrinkle seems to be present in the “add to homescreen” version of safari as well with PWA support…where there is no bottom bar, but it STILL disables that lower area as if there were.

  10. I can see this is implemented on EventBrite’s checkout page but it is not on the events page – the browser nav hides on scroll down? Did you ultimately decide against it since this post 2 years ago?

  11. It is not working anymore both on eventbrite and Jackthreads.. Do you know if something changed? This solution not working more?! Thanks.

Leave a Reply

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