-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Conversation
…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.
we will likely need to patch this with |
Passing run #44768 ↗︎
Details:
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) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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:
- 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.
- Cypress incorrectly mutates the saved user preference for scrolling <-- the thing we are fixing now in this PR
- 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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this 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>
@marktnoonan I very much agree with this. A user could toggle this off without even knowing.
I also agree with this. I am going to make a github issue for this. |
@marktnoonan I created #26107 to track the auto scroll proposed UI changes. Should I route this to CT? |
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. |
should fix the persisting of user preferences for #25084 but does NOT fix the phantom scroll detection |
There was a problem hiding this 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.
There was a problem hiding this 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 👍🏻
This has the expected effect. In the PR description you mention
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>
@marktnoonan I'm working on writing a cy-in-cy test currently since circleci is currently down |
@marktnoonan I added a regression test in 19c738b in the form of a developthis branch |
system-tests/projects/cypress-in-cypress/cypress/e2e/dom-content-scrollable-commands.spec.js
Outdated
Show resolved
Hide resolved
…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(() => { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
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:
a
key as a shortcut to toggle the user preferenceBefore
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:
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
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:
a
key as a shortcut to toggle the user preference (explicitly)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
cypress-documentation
?type definitions
?