solidtime-io
Scrolling resets when opening project and time edit menus
Description
When scrolling down a record and then attempting to change the project, the scroll position resets to the top after the menu opens. Similarly, when editing the time, the scroll adjusts so that the time editing form is positioned at the very bottom of the screen.
Steps To Reproduce
- Add entries so they don't fit on the screen
- Refresh the page just in case
- Try to change the project or time
Self-hosted or Cloud?
Self-Hosted
Version of solidtime: (for self-hosted)
main
solidtime self-hosting guide: (for self-hosted)
https://docs.solidtime.io/self-hosting/guides/docker
Summary:
Commit 15ac3e9a resolved the main issue, but several scroll-related bugs remain when interacting with drop-down menus.
Environment:
- OS: Fedora Linux 42
- Commit
10a8310e - Browsers: Firefox (issue 1 & 2), Chrome, Edge (issue 1 only)
Issue 1: Scroll Restoration After Drop-down Menu Disappears from View
Browsers: Firefox, Chrome, Edge
Steps to Reproduce:
- Open a drop-down menu (Project or Tag selector).
- Scroll the screen, so the menu is no longer visible.
- Click again to close the menu.
Expected Behavior: No scroll changes should occur.
Actual Behavior: The scroll position jumps back to where the menu was originally opened.
Note:
- The Time Change menu does not exhibit this behavior.
- The "Additional Options" menu (Delete Entry) blocks scrolling entirely when open.
Issue 2: Firefox Only — Menu Closure Repositions Entry to Middle of Screen
Browser: Firefox only
Steps to Reproduce:
- Scroll so that a list item is barely visible at the edge of the viewport.
- Open any drop-down menu (except Time Change).
- Close the menu.
Expected Behavior: Minimal scroll adjustment, ideally just enough to make the item fully visible (as seen in Chrome).
Actual Behavior: The page scrolls, so the affected list item is repositioned to the middle of the screen.
Notes:
- This behavior is exclusive to Firefox.
- Chrome shifts the view only slightly to fit the item.
We changed a lot in the latest commits regarding dropdowns. Could you please check if the problem is still relevant in the current main tag?
Yes, there have been noticeable improvements to dropdown behavior, and the issue described in the title has been resolved.
I’ve just re-checked the remaining issues mentioned in my previous comment on both the main and latest branches — they are still reproducible on my end.