Observations on a Scrolling Bug

[ampurr]

The Bug

In Firefox (but not in Edge), there's a curious scrolling bug where some webpages with some animints scroll up by themselves. It's like the webpage is possessed by an especially boring ghost.

You can experience it for yourself. Open Chapter 7 in the animint2 Manual in Firefox, scroll all the way down, and watch the webpage just slowly scroll up by itself.

Since it's browser-dependent, I'm actually not sure that this counts as a bug for animint2 instead of, say, Firefox. But this seemed to be the best place to document it, and I wanted to write down my observations before I forget them.

When Does the Bug Happen?

It seems to become visible when all these criteria are met:

1. The selection menu for an animint is open.
2. The selected value/s for the variable change/s while you are on the webpage.
3. Your viewport is below the selection menu (so you don't see the animint or the selection menu anymore).
4. Your viewport either does not contain the selection menu or is sufficiently far away from it. In other words, if your viewport is very close to the selection menu, the bug may not occur.
5. If the webpage has more than one animint, your viewport does not contain all selection menus that change.

The Fix

How do you stop it from happening? Either:

1. Hide the selection menu, or
2. Pause the animation (under animation controls), or
3. Change updates (under animation controls) to some absurdly large number—that way, you finish reading the webpage before the animint updates.

What's the Cause?

The scrolling seems to happen every time the selected value/s change. The quicker they change, the quicker the scrolling. The more they are, the faster the scrolling occurs. When they stop changing, the scrolling stops, too. Furthermore, the bug doesn't show itself on all browsers.

Therefore, it seems reasonable to conclude that the scrolling bug is caused by some combination of browser contribution and either:

1. The selected values visibly changing on the webpage, or
2. Some unknown variable that causes both the visibly changing values and the scrolling bug. (For example, maybe the JavaScript code causes it to happen.)

graph LR;
    changing_values-->scrolling_bug;

Loading

graph LR;
    unknown_variable-->scrolling_bug;
    unknown_variable-->changing_values;

Loading

[tdhock]

Thanks for the report! this is definitely on the roadmap for fixing this summer during GSOC.

[ampurr]

Great—thank you! 🐈

[Faye-yufan]

Hi @ampurr, thanks for really breaking down the 'How do you stop it from happening?' part. I've made some tweaks to the JS code for the selection menu and it seems to have solved the issue on my side. Could you give it a spin and see if it works for you too?

[ampurr]

Thanks! It's the weekend, so I'll take a look at it later. Super appreciate it. 🌈🐱

[ampurr]

@Faye-yufan, I finally got a chance to test it. Thanks for your work—it works! :>

There's still a very minor bug remaining, but for most practical purposes the bug has been fixed [1]. 🌱

[1] What's the minor bug? It's this: Given a set of animints {1, 2, ... n}, animints {2 ... n} exhibit the scrolling bug only when a selection menu is partly (but not wholly) outside the viewport.

[tdhock]

Hey @ampurr thanks for your analysis of the minor bug. Would it be possible/easy to write a test case that fails for that minor bug with the current code?

[ampurr]

@tdhock: To be honest, I don't know! My initial thought was no, but then I did a little bit of research and now it's a maybe.

Why the Initial No

The most obvious difficulty is that both the major and minor bugs only appear through interaction. For example, the minor bug only comes out when:

• The user is using Firefox;
• The viewport doesn't wholly contain all the animints; and
• The selection menu is partially outside the animint.

Since the particulars of the viewport are part of the bug, I'm not sure how we could automate testing. We'd need to automate doing things like scrolling through a webpage and have the tester somehow notice when it isn't scrolling right.

Why the Current Maybe

Automated testing may be more sophisticated than I first thought. For example, selenium (which I know we use) has scroll wheel actions. Unfortunately, they don't have scroll wheel actions for Firefox. They do have keyboard actions available. This is an excellent substitute for automated testing of the major bug, but manual testing suggests it may be too fragile for the minor bug. It's possible for the arrow keys to skip past the bug-inducing parts of the selection menu.

Conclusion

I think it's probably possible, but it won't be easy. (For me, anyway—you're much more competent than I am.) A large part of that is because I'll need time to learn how to do things with selenium, but the lack of scroll wheels actions might mean that we'd need to find something other than selenium to test with.

[Faye-yufan]

Hi @ampurr thank you for the feedback and thorough analysis! I appreciate it. Regarding the test case, I encountered a difficulty on my end. I cannot reproduce the bug because I don't have the code or command line for generating the animint manual, and I noticed that you built it using pkgdown. I think selenium can do the work, but to proceed with the test case, I would need to understand how to generate a chapter of the animint manual. Could you please share some info on that? Thanks!

[tdhock]

to generate a chapter of the animint manual, this script uses an old version of bookdown::render with html_chapter() https://github.com/tdhock/animint-book/blob/master/_plugins/knit.R
To simplify I would check to see if you can render the Rmd using current version of rmarkdown::render or knitr, does that make sense? (I bet you would still get the bug even using the current version of rmarkdown)

[Faye-yufan]

Got it thank you, will try!

[ampurr]

@Faye-yufan: Sorry, I'm a little confused. Toby built the animint2 Manual, not me. 😅

Where You may be Referring To

You may be referring to the preliminary animint2 reference website I built using pkgdown. But it doesn't exhibit any scrolling problems cuz it doesn't have any animints on it.

The bugs show up on my exam. Is that what you're referring to? If you are:

• This version of my exam exhibits the major bug. Let's call the bug "Big Bug." Let's call the webpage "Big Bug House." Here's the repo. It's built via Quarto, which is the successor to R Markdown.
• This version of my exam includes your fix and therefore exhibits the minor bug. Let's call the bug "Little Bug." Let's call the webpage "Little Bug House." Here's the repo. It's also built with Quarto.

Reproducing Big Bug and Little Bug

As you know, Big Bug is easy to reproduce in Big Bug House. Jump to the bottom of the page and watch it scroll up. You fixed this one. 🐈

Little Bug House's bug is subtler. You can reproduce it like this:

1. Start in this section of Little Bug House.
2. Very slowly and softly scroll up with your mouse wheel or trackpad.
3. At some point, you'll notice that you can't softly scroll up anymore. You'll scroll up a little bit and then the webpage will bounce you down. That's Little Bug.
4. If you scroll up faster or harder, you'll notice that you can mostly avoid Little Bug. It very subtly affects scrolling.

Hope this helps. Thank you again! :>

[Faye-yufan]

In Firefox, the selector widget (<table class="table_selector_widgets">) exhibits an overflow behavior when it shows at the top of the webpage. This behavior is not observed in Chrome. This might be the reason of the Little Bug, and this is the only inconsistency I've been able to identify so far.

[ampurr]

@Faye-yufan, thanks for noticing the overflow thing. 😺

I experimented with

.table_selector_widgets {
    overflow: whatever;
}

but changing overflow didn't do anything [1].

Furthermore, I'm not sure why Firefox is saying that the element is overflowing while other browsers like Edge aren't. It sure looks like both <table>s are overflowing. I wonder if Chrome-based dev tools are missing something. Or maybe I am...

But if I'm right, then the problem unfortunately isn't overflowing content. 😖

---

[1] I also tried playing around with a child element of the overflowing element:

.foobar_variable_selector_widget {
    overflow: whatever;
}

Didn't work. 😔

[ampurr]

It might have something to do with browser support for certain CSS elements, though. In fact, that seems to be the most plausible explanation and I'm embarrassed I didn't think of it till now. I originally thought the most plausible explanation was Firefox-exclusive JS stuff.

[ampurr]

Did some testing. I thought it might've been zoom, since Chrome and Edge support it, but Firefox doesn't. (Why are we using zoom: 1; anyway? 😕) Unfortunately, this doesn't appear to be the problem, either. Pretty frustrating.

[ampurr]

Why are we using zoom: 1; anyway? 😕

Apparently it's to fix an Internet Explorer bug. 🔵