Hamburger menu position shifting on iOS 15.1?

[dylanelliott27]

Hello everyone, big fan of this theme, have been using it for all of my WP builds.

Recently with one of my newest builds, I've noticed that the hamburger menu acts very odd, ONLY on two devices that I've tested with iOS 15.1, in three different browsers, Chrome, Safari and Firefox. I've honestly spent hours troubleshooting, switching the css from flexbox to auto margins to align the hamburger menu and branding, but for some reason, I can't get it figured out. This is what happens:

Intermittently, on page load, the hamburger menu will be pressed up against the branding on the left (as seen in the attached picture). When placing finger over the button, it zaps over to it's correct position, on the far right. It is completely random. Sometimes it will even load in it's correct position, to the far right.

I honestly don't even know the next steps to begin to troubleshoot this, but thought I'd open up this issue as I continue to look for an answer, and also to see if anyone else may have an idea what could be going on.

Thanks everyone!

[ronilaukkarinen]

Thanks for opening an issue about this. We have encountered some iPhone related bugs with Safari 14 in projects (they have not been existing in the demo) as it doesn't support all flex properties properly. But iOS 15.1 should have Safari 14.1 or newer where those properties have been fixed. display: flex; and justify-content: space-between; should be a no-brainer.

It's really hard to replicate because I don't have an iPhone and have to guess the circumstances. However I'm quite sure it's related to the mobile Safari browser. For now I can only guess though. Have you tried to set up width: 100%; for .site-header?

Can you copy the browser information link for us on your mobile phone where this issue exists and we'll go from there. I'll then try to look for the specfici iPhone or emulated one. Currently we're on Christmas holidays but let's look in to this on better time in January. Merry christmas! 🎄

[dylanelliott27]

No problem! It's so bizarre, because it is not browser specific. I tested it on two iOS 15.1 devices with three separate browsers, and it did the same, never seen this before.

I also tried the width 100% on .site-header, unfortunately no change :(

I am at this point led to believe it is actually some Javascript causing this, as without the front-end.js and navigation.js enqueued, and manual styling of the navbar through CSS, it retains correct position.

I am hoping sometime over the holidays I can dive more deep into this and figure it out, and will report back here. I can also get the browser information for all three if it is needed.

Merry christmas!

[dylanelliott27]

Just an update:

Incase anyone comes across this and is having the same issue, I found a workaround for the time being.

.js.js-nav-active .nav-primary { opacity: 1; pointer-events: all; visibility: visible; display: block; }

ADD: display: block

@media screen and (max-width: 959px) {
  .nav-primary {
    background-color: var(--color-background-nav-mobile-layer);
    display: none;
    height: calc(100vh - var(--height-navigation-mobile));
    margin: 0;
    opacity: 0;
    overflow: auto;
    pointer-events: none;
    transition: all 0.18s ease-in-out;
    visibility: hidden;
    width: 100vw;
  }
}

ADD: display: none;

Everything navigation wise seems to still be working on all the devices I've checked, including the problematic ones (iOS 15, multiple browsers). No idea why I need to do this fix, but hopefully I can eventually dive deeper and understand the root problem.

[ronilaukkarinen]

@dylanelliott27 Cool, thank you. Can you share the full code or better yet a diff and/or PR to get the better picture of the change? Because I'm kind of confused since there is already display: block; there:

air-light/sass/navigation/_nav-mobile.scss

Lines 127 to 138 in cc5b5ec

	.nav-primary {
	background-color: var(--color-background-nav-mobile-layer);
	display: block;
	height: calc(100vh - var(--height-navigation-mobile));
	margin: 0;
	opacity: 0;
	overflow: auto;
	pointer-events: none;
	transition: all $transition-duration ease-in-out;
	visibility: hidden;
	width: 100vw;
	}

[ronilaukkarinen]

Status:

This is kinda low priority for us right now because we don't currently have a physical iOS 15.1 at the office. I'll test these things out anyway soon enough but feel free to do your own research if you have time :)

We still haven't been able to reproduce this reliably and/or figured out a bulletproof fix that is safe for screen readers. Will probably wait for iOS 15.1 to go out of fashion, I'll keep the ticket open until hat happens.

[ronilaukkarinen]

We encountered this bug on a project again today.

My observations after discussing the issue with @Tumppex: Because some attributes are under .js class, it must mean that the iOS browser does not have any initial value for the element, that's why it only counting them after javascript has loaded. Other browsers have the initial value so that's why it doesn't occur on all devices. It's still very strange because the position should come from here:

air-light/sass/layout/_site-header.scss

Lines 5 to 8 in 04165f5

	display: flex;
	justify-content: space-between;
	margin-left: auto;
	margin-right: auto;

But I also suspect the .nav-primary for same reason reserves the space on iOS and if it's hidden with display: none; it somehow shrinks the site-header in that moment.

We will test this out soon, today, with a proper iPhone device. We could also try setting up hamburger icon with margin-left: auto; or something and see if it changes anything.

I'll keep this issue updated.

[ronilaukkarinen]

We have figured out the exact issue by narrowing it down with outlines. Our navigation is originally built inside site-header so we can use the same element in both desktop and mobile. In mobile viewports the navigation has been forced to full width with width: 100vw; but it's hidden with visiblity: hidden; and opacity: 0 so that we can animate it with transition: all $transition-duration ease-in-out;. For some obscure reason iOS Safari uses that width: 100vw; to actually expand the parent element. Let me show you what I mean:

That yellow wrapper where the nav-toggle (hamburger) is contains the nav-primary and that's why it's so wide. For some reason iOS doesn't make it as initial block inside the flexbox, it doesn't wrap to the next level as hidden full width element, instead it reserves the space and pushes the hamburger icon left. This issue sounds very similar. We tried margin-left: auto;, max-width to parent element etc, but none worked. The 100vw inside is enough to push it back.

So, we experimented with display-attributes, transition attributes and widths in nav-primary. Removing the width alltogether from nav-primary and adding transition only for opacity fixes the problem but breaks the "out" animation as it only animates when "all" is set. You can't animate visibility but for some reason transition: 300ms all; makes the out animation. However when width is not set it also animates the width as well and that we don't want, it looks buggy. If you add width: 0; or other visibility related attritubtes, the opacity animation won't show at all because the element is already hidden before it has time to animate...

So, tl;dr;: If you want it to work on iOS, you can't do any animations.

We ended up disabling out animation on iOS so that it still works like it used to on other devices. A new release coming soon.

Thanks @dylanelliott27 and @Tumppex for the thoughts.