Hamburger Not Showing in Firefox

Hi @xtiana,

I’m seeing it fine in firefox in Mac. Can you try in a different computer?

So strange – you’re right, all seems to be well. I’d had an issue with it in Chrome/mobile as well, but now that’s fine, and a reload on the Firefox/PC actually now looks fine, too. I’m not sure what would have caused a temp glitch like that, but I’ll consider it fixed unless it does it again! Thanks for your time and help out.

@xtiana I’m glad it’s sorted.

Follow-up question about this same issue – I just presented a preliminary version of this website to the client and had the icon show up as just a tall rectangle in both Chrome and MS Edge. It lasted for a few minutes but did seem to start showing up as a hamburger again after we navigated to another page. The menu functionality itself is fine, but can you think of any reason why there might be some kind of delay in loading the hamburger for the first time on a new computer/browser? Thanks for your help.

@xtiana The final site is this URL https://muirseattle.com/new/ ?

Or it’s a different one?

Yep, same site. I generally pull up that page and then navigate from there to the other sub-pages. I believe yesterday it was on the third page that we finally saw the hamburger icon show up.

I can’t replicate that situation. The HTTPS settings seem fine, the certificate is showing as valid so nothing that could block the loading of the WebFont.

The first time the site is visited you can see a temporary rectangle while the font isn’t loaded but that’s it.

Hmm. I guess we must just have a bit of a slow load time on our work connection. I’ll see if we can optimize the load speed in other ways to speed up the rectangle conversion. Thanks for your help!

This should only happen the 1st time you visit the webpage, after that the fonts stay in cache till someone delete the browser cache.

Sorry to keep bringing up this same issue, but it looks like we are running into the problem of the hamburger not loading in Chrome, even on very high-speed connections outside our office. It does cache and begin loading lightning-fast after the first page (if you click out to anywhere else in the menu, or come back to that same page), but it’s continuing to sit there as a rectangle until you either switch pages or refresh the current one.

I thought it might be related to the video on our home page (muirseattle.com/new) taking up more load time, but we do run into the same thing on sub-pages with no video content. Is there anything else we can check to prevent this? The client would prefer not to launch until this is resolved. Thanks for your help.

I could only see it once when I access it. Somehow the HTTP version was being loaded instead of the HTTPS with the secure Padlock.

I would say that something in the redirection from HTPP to HTPPS may be wrong.

Can you see this article and check if your URL are both using HTTPS ?
https://www.wpmobilemenu.com/knowledgebase/common-errors/cant-load-wp-mobile-menu-using-https/

Hmm, I do have both of those set to use the HTTPS. Would an HTTPS rewrite rule in the .htaccess file make any difference? I tried adding that, but I’m not quite sure how to check whether it’s loading the HTTP or HTTPS version. Can you check on your end? Any other ideas if that doesn’t do the trick? Thanks for your help out on this!

@xtiana
That’s good that you have both URLs with HTTPS. Can you also check if the links are the same because sometimes one URL has the WWW and the other doesn’t and that makes the difference.

Any settings in the HTACCESS can make a difference.
You should test with the default settings.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

I can assure that the issue isn’t in our side since we use those addresses you have in settings like is recommended as a best practice.

They are exactly the same. I was using the default HTACCESS settings originally, but added the rewrite rule for HTTPS yesterday before my last response because I was still seeing the issue; I was just hoping to find out if whatever you saw on your end to indicate it was pulling from HTTP before had changed (I don’t know how to see what you were seeing). I think it may be fine now but I’m hesitant to launch the site until I can somehow verify it’s resolved.

I could only replicate the issue a couple weeks ago.
If the redirect from HTTP to HTTPS is correct I guess you shouldn’t worry about.

My suggestion is to push it to production and we will see if you still can replicate it.