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:
- Stack Overflow – Buttons Aligned to Bottom of Page Conflict with Mobile Safari’s Menu Bar
- Stack Exchange – Safari iOS Menu Bar Conflicts with Buttons in Loer 10 of the Screen
- Stack Overflow – Deadzone in iPhone 6 Plus Safari
- Stack Overflow – Overriding the Bottom and Top Touch Area on iOS7 Safari Landscape
- Stack Exchange – iOS7 Safari and Footer Buttons
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.
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,
<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.
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!
We did it! Check out the results: