Auto scrolling is not working

[mohanbabu-zumen]

Current behavior

Initially, auto-scrolling is enabled. When we run the scripts, it's automatically disabled in the run time.

Desired behavior

It's shouldn't be automatically disabled

Test code to reproduce

chrome_KYAzJ7OCeX.mp4

Cypress Version

11.2.0

Node version

16.17.0

Operating System

Windows 11

Debug Logs

No response

Other

No response

[WORMSS]

Yes, this is highly annoying for me also..
It wasn't too bad when "auto scroll" was a checkbox on the toolbar, but now that it's hidden in a sub menu with NOTHING ELSE.. It's a massive hinderance.

[romankhomitskyi]

Yeah 10.11 same issue so annoying

[mohanbabu-zumen]

yes, It's very annoying. Even If it is a radio button like the older version, It does not affect us much.

[emilyrohrbough]

I've tried to reproduce this and have not been able to. I believe it is happening for you - I feel like I have noticed this behavior though...It'll be hard for us to track down the root issue and be confident in a fix if we aren't able reproduce this.

@mohanbabu-zumen @romankhomitskyi @WORMSS is this happen in a specific browser or all browsers? also what browser versions are you using?

@romankhomitskyi @WORMSS can you share your OS?

[romankhomitskyi]

I've tried to reproduce this and have not been able to. I believe it is happening for you - I feel like I have noticed this behavior though...It'll be hard for us to track down the root issue and be confident in a fix if we aren't able reproduce this.

@mohanbabu-zumen @romankhomitskyi @WORMSS is this happen in a specific browser or all browsers? also what browser versions are you using?

@romankhomitskyi @WORMSS can you share your OS?

OS version: Big Sur 11.6.5
Browser: Chrome, it has been reproducing since Cypress 10, during this time browser version have been constantly changing from 102(not sure, could be 101) to 108 (currently)
Cypress version: 10.11

Not sure about firefox because I dont run tests in it as much

[romankhomitskyi]

I mean to reproduce it you might need to have a test with commands logs more than 300 lines

Then do some hover over commands, clicking, messing arround, than move mouse over the Application under test, than retry test, leave mouse on the command log, something like that

[romankhomitskyi]

It might have smth to do with this issue Issue

[emilyrohrbough]

@romankhomitskyi If you are clicking on the command logs while the test is executing that will disable the auto-scroll when tests are running. That behavior is expected. Is the issue you are seeing that the next run isn't restoring the autoscroll behavior?

[mohanbabu-zumen]

I've tried to reproduce this and have not been able to. I believe it is happening for you - I feel like I have noticed this behavior though...It'll be hard for us to track down the root issue and be confident in a fix if we aren't able reproduce this.

@mohanbabu-zumen @romankhomitskyi @WORMSS is this happen in a specific browser or all browsers? also what browser versions are you using?

@romankhomitskyi @WORMSS can you share your OS?

Hi @emilyrohrbough It's happened in all browsers frequently. My chrome version is 108.0.5359.125

[mohanbabu-zumen]

@romankhomitskyi If you are clicking on the command logs while the test is executing that will disable the auto-scroll when tests are running. That behavior is expected. Is the issue you are seeing that the next run isn't restoring the autoscroll behavior?

@emilyrohrbough Yes. If we click command logs or anything else, then the disable behavior is expected. In my case, I haven't clicked anything. But, It's disabled.

[romankhomitskyi]

@romankhomitskyi If you are clicking on the command logs while the test is executing that will disable the auto-scroll when tests are running. That behavior is expected. Is the issue you are seeing that the next run isn't restoring the autoscroll behavior?

Hmmm interesting, I guess I have expirienced both cases

[emilyrohrbough]

@romankhomitskyi any browser or all? what is your OS?

[romankhomitskyi]

@romankhomitskyi any browser or all? what is your OS?

I gave a details a couple of comments above

[emilyrohrbough]

@romankhomitskyi whoops. Missed those details. thanks.

[emilyrohrbough]

I reached out to @marktnoonan to see if he had any insights to this issue. He said:

I’ve never been able to reproduce it but I think I do understand the issue, which is that lots of stuff filling up the command log quickly can be cause this scroll listener we have on there to fire and disable the auto scroll, even though it’s not actually user scrolling. When this issue was first reported in run mode, where it’s impossible to be the user’s action, I made this PR to avoid reacting to the scroll event in run mode and that fixed it.

Sounds like we understand the basics of the issue at least which should be enough to route this. and Mark has a few ideas on how we might be able to improve this.

[marktnoonan]

Linking up to the previous issue that mentioned this: #24171

Also noticed this morning that there’s already a rubric, which looks arbitrary, that we could change based on trying to avoid "false positives" in scroll listeners: https://github.com/cypress-io/cypress/blob/develop/packages/reporter/src/lib/scroller.ts#L48-L49

That would be a good place to do another checks we think are needed, or we could just beef up the threshold for how many scroll events are needed to prove it's the user and not the browser reacting to elements populating the log.

[scottohara]

For what it's worth, I'm still experiencing this issue.

I added some logpoints and confirmed that, without any user scrolling at all (hands completely away from all pointing devices), I do see a number of scroll events within a 50ms window which is enough to nullify the "false positive" guard and disable autoscrolling.

In my case, anecdotally it seems to occur at a particular test that has a slow-ish set of commands (enough to exceed the 1s threshold and automatically expand the command log), and after the test passes and the command log is automatically collapsed, the appState.autoScrollEnabled flag that was previously true is now false and all scrolling ceases.

It would seem that the assumption of "3 or more scroll events within a 50ms timeframe === user is scrolling" is an unreliable one, and that some browsers (in my case, Chrome) may trigger scroll events without any intentional user activity.

Perhaps instead of counting scroll events, another heuristic might be if the scroll position indicated in the scroll event is a certain distance away from the scroll position calculated by the scroller? (i.e. user must actually scroll a minimum threshold before autoscrolling is disabled?)