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

Widgets styled with a :hover can sometimes end up with their styles sticking #1372

Closed
davep opened this issue Dec 15, 2022 · 3 comments · Fixed by #1659
Closed

Widgets styled with a :hover can sometimes end up with their styles sticking #1372

davep opened this issue Dec 15, 2022 · 3 comments · Fixed by #1659
Assignees
Labels
bug Something isn't working

Comments

@davep
Copy link
Contributor

davep commented Dec 15, 2022

It's not 100% clear to me yet exactly what happens, but this can be seen with 5x5 from our examples, where a :hover style can get stuck after the mouse has left the widget. See here for example:

Screenshot 2022-12-15 at 16 05 58

In the image 3 cells have the hover style (the background slightly lighter than the background for the other "off" cells). One of them, at the time of the screenshot, had the mouse over it, the other 2 didn't.

This seems to happen if you're a bit quick with mouse movements.

Needs some investigation and a proper route to reproduction found.

@davep davep added the bug Something isn't working label Dec 15, 2022
@davep
Copy link
Contributor Author

davep commented Dec 15, 2022

After a wee bit more playing, it looks like the issue mainly crops up if the mouse cursor passes out of the terminal window pretty quickly (suggesting that the removal of :hover relies on seeing that some other widget now has the mouse over it, but the mouse isn't over anything?).

rodrigogiraoserrao added a commit that referenced this issue Jan 24, 2023
This is the fix for #1372 because the styles that were sticking had nothing to do with `:hover` per se.
The issue was in the fact that we were trying to start a second animation (back to the default background color) while the first animation hadn't started yet, so we would skip the creation of the new animation but the old one would still run to completion.

This issue also affects animations that start with a delay. If we set an animation A -> B with a delay of 10s and 1s later we set an animation B -> A, then the animation A -> B will run after 9s but the animation B -> A will not run because it was not created in the first place.
@rodrigogiraoserrao
Copy link
Contributor

The real issue was in the fact that we were trying to start a second animation (back to the default background color) while the first animation hasn't started yet, so we skip the creation of the new animation but the old one still runs to completion.

This issue also affects animations that start with a delay. If we set an animation A -> B with a delay of 10s and 1s later we set an animation B -> A, then the animation A -> B will run after 9s but the animation B -> A will not run because it was not created in the first place.

@github-actions
Copy link

Don't forget to star the repository!

Follow @textualizeio for Textual updates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants