-
Notifications
You must be signed in to change notification settings - Fork 4.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
Color Presets: Unexpected scroll to color presets when selecting a style variation #61841
Comments
Hi @andrewserong, I think the bug mentioned in the issue is fixed in this PR. I also tried to replicate it but couldn't. Let me know if I'm missing anything. |
Thanks @amitraj2203, but after re-testing trunk after #61617, this issue still appears to be present: 2024-05-27.14.49.52.mp4In case it helps, I found it easier to reproduce on a smaller window size, e.g. a 13" laptop screen, where the Styles sidebar scrolls quite a long way. On larger screen sizes where both the style variations and color palettes are visible at the same time, the scroll issue doesn't appear to occur (I suspect because the elements are all visible?), so it's just when the other components aren't visible where the unexpected scroll seems to be happening. |
I'm pretty sure this existed before #61334. Let's target a fix for 6.6. |
Hey @andrewserong, I tested the above issue and can reproduce this issue But I wanted to confirm whether the scroll on changing the style variation is expected or not. I think that updating the style variation should automatically scroll to the colour palette associated as the next step so that we can confirm the colour palette and typography to be used I will be working on the fix for the focus not being placed correctly on the style variation that the user clicked on. |
Thanks for the ping!
I believe the scroll is unexpected. In this case we can't know whether a user wishes to continue toggling through the style variations, so to me it would be unexpected to be scrolled immediately to another part of the UI as these screens aren't explicitly step based. |
I can no longer reproduce this, can you @andrewserong ? |
Thanks for the ping! I can still reproduce this @scruffian. It can be a little tricky to reproduce if your theme only has a couple of presets as the issue only occurs when there's enough style variations and palettes that the buttons are out of view. To reproduce / emulate a theme that has a lot of presets, I've reduced my browser window down so that it's very short. I'm testing on Chrome on macOS. Here's how it's looking for me: Gutenberg
|
I can confirm that it still occurs. It's weird - almost as if the currently-focussed element doesn't like focus being taken. I have to click twice to "force" it. Kapture.2024-10-02.at.16.28.26.mp4I removed all the focus-related props on the variations and it didn't change much. |
Note: it's not occurring in Firefox for me. Maybe related to: https://issues.chromium.org/issues/40846304 |
Same, can reproduce in Chrome but not Firefox. Copying this over from the TT5 isssue: I can reproduce this. I select a style variation at the top of the list for example "Noon". style-selection-october-18.mp4 |
Description
Related to #61213 and possibly introduced in #61334
While testing the new color presets in
trunk
, I noticed that if you select one of the color presets and then go to select a style variation, the first time you click the style variation, the site editor's browse mode side bar unexpectedly scrolls down to the already selected color preset.Step-by-step reproduction instructions
Screenshots, screen recording, code snippet
2024-05-21.18.44.54.mp4
Environment info
Please confirm that you have searched existing issues in the repo.
Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
Yes
The text was updated successfully, but these errors were encountered: