Footnote links no longer working properly

[frankhecker]

Environment

I am using Minimal Mistakes 4.15.2 and Jekyll 3.8.5, recently upgraded from 4.12.0 and 3.8.3 respectively. For more information see the attached Gemfile.lock files for the old and new environments.

Gemfile.lock-old.txt
Gemfile.lock-new.txt

Expected behavior

In pages generated under the old environment Markdown footnote links behaved as expected: clicking on a footnote numeral link in text would cause the page to scroll to the footnote in question. Once there, clicking on the reverse link arrow would cause the scroll back to the original place where the footnote was referenced.

In pages generated under the new environment this behavior is broken: clicking on either the forward link or revise link causes the page to scroll to the top.

I have tested this under Safari 12.0.3, Firefox 65.01, and Chrome 72.0.3626.121 on MacOS Mojave. All show the same incorrect behavior.

Steps to reproduce the behavior

You can compare the behavior of the old and new generated pages by looking at the following two pages, the first one on my production server generated under MM 4.12.0, and the second on my staging server generated under MM 4.15.2; the underlying Markdown for the pages is unchanged from one to the other:

OLD: https://civilityandtruth.com/2018/03/22/seven-answers-social-democracy/
NEW: http://frankhecker.net/2018/03/22/seven-answers-social-democracy/

Other

If and when I have time I will try to create a minimal reproducible test case. The generated HTML for the pages themselves doesn't seem to differ in the HTML code for the footnotes, so it's possible the problem is in the included CSS files.

[frankhecker]

Update: The problem appears to be somewhere in main.min.js. If I modify assets/js on my staging server to replace the new MM 4.15.2 version of main.min.js with the old MM 4.12.0 then the problem goes away (after clearing browser cache and reloading the page in question). Similarly, if I replace the old 4.12.0 version of main.min.js on my production server with the new 4.15.2 version, the problem occurs (again, after clearing browser cache and reloading the page).

If I have time later I'll try to narrow down which line(s) in main.min.js appear to be causing the problem.

[frankhecker]

Update 2: I've narrowed this down further, by forcing use of a particular version of MM in the Gemfile on my staging server (frankhecker.net), doing a bundle update, regenerating the entire site from scratch, and then using the test page linked to above. (I don't use incremental update because in the past I've had problems with one of the plugins when I do that.)

I've determined that 4.14.2 is the last version for which footnote links work properly. Apparently one of the changes introduced in main.min.js for 4.15.0 broke footnote links.

I don't have time right now to debug this further. For now I'm going to stay on 4.14.2 until/unless someone finds a fix for this.

P.S. That means the test page above will not show the incorrect behavior. You can see it yourself by creating a page using Markdown footnote links and then generating it both in 4.14.2 and 4.15.0.

[mmistakes]

I haven’t tested this yet, but seeing how it seems to have broken in 4.15 and up, it is likely related to #2019 and #2023.

Ccing @edemaine as they did this work and might have some insight as to the issue.

[mmistakes]

I've confirmed that this is definitely a bug.

Perhaps dropping jQuery Smooth Scroll, the custom hash rewriting, and scrollspy implementation and going with Smooth Scroll + Gumshoe as noted in #2050 would be a better solution. Seems that it doesn't break footnote links.

[mmistakes]

I put up a proof of concept that fixes the issue by using Smooth Scroll + Gumshoe. It needs some work yet as the scrollspy .active classes trigger as you scroll to a header, but turns off as you scroll pass it.

To test out the PR brand you can replace gem "minimal-mistakes-jekyll" in your Gemfile with the following:

gem 'minimal-mistakes-jekyll', :git => 'https://github.com/mmistakes/minimal-mistakes.git', :branch => 'smooth-scroll-gumshoe'

[frankhecker]

The change you made appears to fix the problem with footnotes, at least on the browsers I tested: Chrome, Firefox, and Safari for MacOS (for versions see above) and Safari on iOS 12.1.4.

However I will note that on Chrome scrolling to the footnote and from the footnote back to the original test seems slower than normal with the fix; there is a noticeable lag until scrolling starts. (I didn't notice any substantial difference with the other browsers.)

Thanks for working on this!

[mmistakes]

The delay is part of the new Smooth Scroll script. It has different easing settings that I haven't tried adjusting yet to fine tune the scroll speed.

[edemaine]

Sorry I haven't had a chance to look this over yet (a busy week) but thanks @mmistakes for taking the lead here! Relying more on off-the-shelf packages seems like a generally good idea, so I'm happy to see this in the works. If you let me know when you tweak the settings, I'm happy to take the second testdrive.

[mmistakes]

Sounds good @edemaine. I'm struggling with getting Gumshoe's scroll spy to work correctly. So if you have any suggestions please let me know.

Seems like it was designed to have the anchor id on a <div> element wrapped around each TOC section. So what happens is the scrollspy hits a header with an id that matches the TOC link, activates the active class, but turns it off as soon as you scroll by the header.

I'm sure there's a way to keep it active until you hit the next id, but haven't figured that part out. Guessing we'd need to tap into Gumshoe's event API somehow.

[edemaine]

@mmistakes Ah, that is unfortunate. It indeed seems that the Gumshoe code doesn't handle this case of headers implicitly defining sections. Surprising! I've opened an issue on the Gumshoe Github: cferdinandi/gumshoe#97