Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: do not magically set user preferences for auto-scroll #26102

Merged
merged 25 commits into from
Mar 15, 2023

Conversation

AtofStryker
Copy link
Contributor

@AtofStryker AtofStryker commented Mar 14, 2023

Additional details

Fixes a critical bug where the user's auto-scroll preference is being implicitly set by the app when auto-scroll is implicitly toggled. User preferences should be explicitly set by the user and not implicitly mutated by the app.

The application turns off auto-scroll when the user:

  • scrolls through the command log
  • presses the a key as a shortcut to toggle the user preference
Before

What was happening, is that we were conflating the user preference's auto scroll switch (explicit setting) with that of implicitly setting auto scroll. When the above behavior to scroll the command log disabled auto scroll, it was then synced to the preference when:

  • the preference menu was opened
  • the command log was clicked
    If autoscroll was "temporarily" disabled, the preference would get toggled back on at the end of the run (seen in GIF). However, if the user refreshes the run before the test is over, auto scroll would be turned off in preferences

a

After

Implicit auto scroll behavior and explicit user preferences should be separate configurations/concepts. Now, if auto scroll is enabled as a user preference, auto scroll will happen unless:

  • the user disables it under preferences (explicitly)
  • presses the a key as a shortcut to toggle the user preference (explicitly)
  • the user scrolls the command log (implicitly). With implicit auto scroll disabled, the user preference flag is NOT overridden. If auto scroll is implicitly disabled, and the test is rerun, the test will start auto scrolling again. If the user explicitly turns off auto scroll in preferences and reruns the tests, auto scroll will be disabled. If it is re enabled as the test is running, auto scroll will automatically start happening again. The user preference flag, when set, will override any current behavior

Steps to test

A few edited tests to adjust for the behavior plus manual test as seen in GIF.

How has the user experience changed?

Users should no longer see side effects from auto-scroll implicitly configuring their user preferences. Instead, users now need to explicitly enable / disable auto scroll under user preferences, which is enabled by default. This behavior is more predictable and desired by users.

PR Tasks

…havior is disabled when a user scrolls or clicks inside the reporter or opens user preferences. Users must explicitly toggle auto-scroll on/off inside the user preferences menu and any implicit behavior will be overidden when this configuration value is set.
@AtofStryker AtofStryker changed the title Spike scroll fix: do not magically set user preferences for auto-scroll Mar 14, 2023
@AtofStryker AtofStryker self-assigned this Mar 14, 2023
@AtofStryker AtofStryker marked this pull request as ready for review March 14, 2023 14:51
@AtofStryker
Copy link
Contributor Author

we will likely need to patch this with 12.8.1 later this week

@cypress
Copy link

cypress bot commented Mar 14, 2023

Passing run #44768 ↗︎

0 84 0 0 Flakiness 0

Details:

Merge branch 'spike_scroll' of github.com:cypress-io/cypress into spike_scroll
Project: cypress Commit: 9ad1f6f493
Status: Passed Duration: 14:40 💡
Started: Mar 15, 2023 3:42 PM Ended: Mar 15, 2023 3:57 PM

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings.

cli/CHANGELOG.md Outdated
@@ -15,6 +15,7 @@ _Released 03/14/2023 (PENDING)_
- Fixed an issue where using `Cypress.require()` would throw the error `Cannot find module 'typescript'`. Fixes [#25885](https://github.com/cypress-io/cypress/issues/25885).
- The [`before:spec`](https://docs.cypress.io/api/plugins/before-spec-api) API was updated to correctly support async event handlers in `run` mode. Fixes [#24403](https://github.com/cypress-io/cypress/issues/24403).
- Updated the Component Testing community framework definition detection logic to take into account monorepo structures that hoist dependencies. Fixes [#25993](https://github.com/cypress-io/cypress/issues/25993)
- Fixed an issue where the reporter auto-scroll configuration inside user preferences was being set implicitly. User's must now explicitly enable/disable auto-scroll under user preferences, which is enabled by default. Fixes [#24171](https://github.com/cypress-io/cypress/issues/24171) and [#25084](https://github.com/cypress-io/cypress/issues/25084)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

was this a regression? if so do you know when it was introduced?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was a v10 regression

Copy link
Contributor

@marktnoonan marktnoonan Mar 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm glad to see this fix, but I'm not sure it lets us close those issues. For example in #25084 the setting being changed is a side-effect of another problem. I think it goes like this in the gif for that issue:

  1. Cypress incorrectly detects user scrolling over the command log with no mouse activity when many commands are added close together. The is open-mode version of Auto scroll is turned off sometimes  #16098, possibly caused by false positives mentioned here.
  2. Cypress incorrectly mutates the saved user preference for scrolling <-- the thing we are fixing now in this PR
  3. User moves the mouse again and opens the settings panel to show that auto scrolling was turned off

But in #16098 what's being reported is the first problem, because the user has not intended to enter the "temporarily disable autoscrolling" state.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marktnoonan that's a good point. I don't think we can close #25084 (maybe note on the issue that the config should no longer be mutated?) for the false positive scroll issues, but would we be able to close #24171? I'm not sure #24171 is referring to the false positive scroll listener or the preference behavior.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the comment in #24171 refers to the setting being turned off and the person being unaware. But the issue itself refers to "Users are reporting that the command log stops auto-scrolling during test execution unexpectedly."

We could close it as a dupe. Is there any open issue that is just about the preferences being set implicitly? That's what I would link to here, for clarity especially when reading the changelog later. We might need an new issue that isolates this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marktnoonan I'll create a new issue and link it here and update the changelog

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marktnoonan created #26113. will link in the PR and update the changelog

cli/CHANGELOG.md Outdated Show resolved Hide resolved
Copy link
Contributor

@marktnoonan marktnoonan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haven't tested yet but looks good.

It's unfortunate that this regression happened in the same release that moved this setting out of view at the top of the command log, the incorrect behavior would have been easier to catch if something visible was changing unexpectedly.

Thinking about it more, it seems odd to me that there is a keyboard hotkey to modify this setting but there's no visible feedback that you have done so. So like, you hit the a key at the wrong time and place and you have saved a preference for scrolling behavior in your tests.

I'm going to suggest we lift this setting back up to the top level instead of being the only item in a menu that needs to be expanded, so users can have a better idea of what their scrolling preference is set to. (Not a suggestion for this PR, just tracking the observation here).

Co-authored-by: Emily Rohrbough <emilyrohrbough@users.noreply.github.com>
@AtofStryker
Copy link
Contributor Author

Thinking about it more, it seems odd to me that there is a keyboard hotkey to modify this setting but there's no visible feedback that you have done so. So like, you hit the a key at the wrong time and place and you have saved a preference for scrolling behavior in your tests.

@marktnoonan I very much agree with this. A user could toggle this off without even knowing.

I'm going to suggest we lift this setting back up to the top level instead of being the only item in a menu that needs to be expanded, so users can have a better idea of what their scrolling preference is set to. (Not a suggestion for this PR, just tracking the observation here).

I also agree with this. I am going to make a github issue for this.

@AtofStryker AtofStryker requested a review from mjhenkes March 14, 2023 17:19
@AtofStryker
Copy link
Contributor Author

@marktnoonan I created #26107 to track the auto scroll proposed UI changes. Should I route this to CT?

@marktnoonan
Copy link
Contributor

Thanks @AtofStryker - no need to route it yet, I'll add it for review as a feature request and hopefully we can move it through pretty quick.

@AtofStryker AtofStryker requested a review from marktnoonan March 14, 2023 18:23
@AtofStryker
Copy link
Contributor Author

should fix the persisting of user preferences for #25084 but does NOT fix the phantom scroll detection

Copy link
Contributor

@marktnoonan marktnoonan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

However, if the user refreshes the run before the test is over

I suspect this detail is why this hasn't presented itself more widely as a bug, if it's largely self correcting unless you refresh at the wrong time. Combined with the fact that the on/off state isn't visible in the runner.

packages/reporter/src/lib/events.ts Outdated Show resolved Hide resolved
Copy link
Contributor

@astone123 astone123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worked well in my testing 👍🏻

@marktnoonan
Copy link
Contributor

This has the expected effect. In the PR description you mention

A few edited tests to adjust for the behavior

But I don't see any test that would catch a regression here. If we want to get this out quickly I understand. Could we get a follow up task for an automated test that would fail on the old code and pass on the new?

Co-authored-by: Mark Noonan <mark@cypress.io>
@AtofStryker
Copy link
Contributor Author

@marktnoonan I'm working on writing a cy-in-cy test currently since circleci is currently down

@AtofStryker
Copy link
Contributor Author

@marktnoonan I added a regression test in 19c738b in the form of a cy-in-cy test. It's not the prettiest looking test, but it does function as a e2e regression test for this behavior. @mjhenkes @emilyrohrbough @astone123 would you all mind taking another look as well with this test added. Figured I can add it as we wait for circleCI to recover 😅

develop

scroll-cy-in-cy-before

this branch

scroll-cy-in-cy-after

…nt-scrollable-commands.spec.js

Co-authored-by: Emily Rohrbough <emilyrohrbough@users.noreply.github.com>
cy.get('[data-cy="reporter-panel"] .reporter > header + .container').its('0').then(($runnableContainer) => {
// scroll the container to the top.
// fire multiple scroll events so our scroller component believes the scroll came from an actual user.
[...Array(10).keys()].forEach(() => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wonder if it's work a comment linking to https://github.com/cypress-io/cypress/blob/develop/packages/reporter/src/lib/scroller.ts#L37 to explain why this works?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would think so. My only concern is if the file changed and the reference became out of data

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah and thinking about it, if you are doing something that breaks this test, you've almost certainly been in that exact function, probably no need for comment.

@AtofStryker AtofStryker merged commit ef430e9 into develop Mar 15, 2023
@AtofStryker AtofStryker deleted the spike_scroll branch March 15, 2023 16:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants