[Resolved] Back to top is “sticky” in Firefox

[ideawrights]

Very strange issue here.

Short version: in Firefox, on one site and one site only, if you click the back to top button, it then no longer allows you to scroll. It’s like scrolling fires the back to top function and you keep going back to the top.

Details
– tried with two different machines, two different Firefox installs including a minimalist FF profile run in incognito with no browser plugins and get that behavior in all cases.
– tried three other GP sites with the same browser and none exhibit that behavior.
– Chrome does not have that behavior
– I disabled all WordPress plugins including GP Premium and still observed the behavior.

So I see the problem in multiple instances of Firefox on one site only and with nothing active except the base Generatepress theme.

Also, this is a minimal site. It’s basically a fresh install with only one demo content page, no history of other plugins or themes or other weird things.

I looked in the browser console for any obvious Javascript issues, but didn’t see anything jump out.

Ideas?

[Leo]

Hi Tom,

It’s a strange one for sure.

I can see the issue in the site you’ve linked but cannot replicate it on my install either.

Any chance you can duplicate the problematic install on a new staging site environment so we can go through some debugging steps?

Let me know 🙂

[ideawrights]

Stranger and stranger – I used WP Duplicator to put the code on a staging server for you to look at, but the problem cannot be replicated there.

So it is something peculiar to the live server setup, which is so strange because this is a client-side problem due to a client-side script. So there must be some other script that is getting loaded or something that is causing this.

In any case, this does not appear to be a Generatepress issue, so I am marking this as resolved. If I ever figure out what is causing this and determine that GP could/should be modified to prevent it, I will let you know.

[ideawrights]

Sorry… marking this as “not resolved.” Stupidly, I forgot the details of my own problem and tested the staging site in Chrome, which obviously works because that works on the live site.

In fact, I can replicate this on the staging site with Firefox. So the behavior is consistent in this install.

I’ll provide login details privately and I definitely understand if this is not something you want to devote much time to. It’s such an odd case, but since this is a minimalist GP install at this point and the same code causes the same problem on two servers, I now think this might be some strange conflict with a specific set of settings in GP.

[ideawrights]

PS – the staging server I gave you in the login details is just for you. Change plugins, settings, customizer settings or anything at all that you want to do. Once you’re done looking, it will be deleted. Nothing will ever get pushed from this server to the live site, so have no fear. If you break something, no worries.

[Leo]

Have you tried activating the parent theme to test if the issue still exists?

[ideawrights]

Stupid me! I should have done that first.

So here’s the really crazy part. The client added some custom CSS via the customizer in the Additional CSS section. What did she add? Just this

body {border-top:1px solid #7ab9bc;}

Somehow that causes the problem in Firefox. It doesn’t matter how you add it. I removed it from the Additional CSS and added the rule to the style.css of the child theme and the problem comes back.

So it appears that if you add a border to the body element in Firefox, the scroll issue appears. You can see it in the Firefox inspector by adding that rule to that site.

I tested this on two other Generatepress sites. Indeed, if you go into the inspector in Firefox and add a top border, every one of them will have the problem that it continually scrolls to the top.

Here’s where it gets interesting.

With the 1px top border, when I go into the console in Firefox and enter document.body.offsetTop, the value is -1. If I remove it, the value is 0.

In Chrome, with or without the top border, document.body.offsetTop has a value of 0.

Now when I look at your code in back-to-top.js, the stopAnimation() function checks the following condition:

if ( travelled <= (endLocation || 0) )

In Chrome, the top of the page will be 0, so the endLocation is 0 and so is your default condition.

In Firefox, endLocation in our case will be -1. So when it hits the conditional, it stops the animation when travelled = 0, but travelled is still greater than endLocation. So I think that results in it getting confused and continuing to fire.

I did not set breakpoints and trace execution, but I think the implicit assumption in your code is that endLocation can never be less than zero, but that turns out to be wrong in Firefox in the edge case where there is a border on the body (and bizarely, not when there is a margin).

[Leo]

Thanks for helping to debug!

I’ll mention this issue to our team.

For now, maybe try this CSS to achieve the same effect?

.site-header {
    border-top: 1px solid #000	
}

[ideawrights]

Thanks Leo. And thanks for the tip to try the parent theme. Obvious debug step that I would normally do first thing, but I thought the child theme didn’t have any changes to style.css or functions.php so I just discounted that possibility.

I think it will be a simple change to the JS if Tom and crew want to account for this situation.

Thanks

[Leo]

I’ll mention it.

Thanks 🙂

[Author]

Posts