Remove default Svelte scroll reset on navigation while on "Browse" page #100

Closed
opened 2026-05-22 00:43:43 +02:00 by Lanchon · 4 comments

IMHO, the grid should never auto refresh nor auto scroll unless specifically requested. it is very annoying to try to browse the grid while grindr refreshes it on the background. not letting easily you exhaust you search is one more anti-feature grindr uses to have you believe there is more value hidden in the app that you have already found.

right now, a second tap on "browse" will take you to the top of the grid. this is IMHO very annoying. please consider refreshing/returning to the top on some specific gesture. long tapping "browse" is acceptable. a button on the top would also be acceptable.

IMHO, the grid should never auto refresh nor auto scroll unless specifically requested. it is very annoying to try to browse the grid while grindr refreshes it on the background. not letting easily you exhaust you search is one more anti-feature grindr uses to have you believe there is more value hidden in the app that you have already found. right now, a second tap on "browse" will take you to the top of the grid. this is IMHO very annoying. please consider refreshing/returning to the top on some specific gesture. long tapping "browse" is acceptable. a button on the top would also be acceptable.
Owner

But Open Grind does not refresh grid automatically? It's not implemented and there are no issues/plans to implement it.

Regarding tapping "browse" scrolling to top, your feedback is appreciated and this will probably be fixed in the next update.

I'll now rename this issue for the second point.

But Open Grind does not refresh grid automatically? It's not implemented and there are no issues/plans to implement it. Regarding tapping "browse" scrolling to top, your feedback is appreciated and this will probably be fixed in the next update. I'll now rename this issue for the second point.
hloth changed title from [RFE] grid refresh and UI to Remove default Svelte scroll reset on navigation while on "Browse" page 2026-05-22 14:16:44 +02:00
hloth closed this issue 2026-05-22 14:23:48 +02:00
Author

It's not implemented and there are no issues/plans to implement it.

great! i did not know this.

will probably be fixed in the next update.

thank you!

> It's not implemented and there are no issues/plans to implement it. great! i did not know this. > will probably be fixed in the next update. thank you!
hloth added this to the v0.1.0-alpha.4 milestone 2026-05-27 23:28:03 +02:00

It think the the button immediate scroll to the top is useful the auto refresh after adding a favorite and the auto reposition to the rop were not so useful

It think the the button immediate scroll to the top is useful the auto refresh after adding a favorite and the auto reposition to the rop were not so useful
Author

right now (alpha 4), when i tap on "inbox", and then back to "browse", the grid is reset to the top position.

IMHO (and this is very subjective) i think this behavior is detrimental. in my case, i want to be able to go back to the browse tab and continue where i was.

i also noticed this while browsing the grid: wherever i go from there, say "inbox", if i tap "back" instead of "browse", it does return to the place i left off, which is what i always want. it seems as if i tap on "browse", a new browser level is added to the top of the browsing stack with the grid in the top position, but from there if i tap "back" and can go back to the "old grid" in the old position.

this is ok... i understand the dynamics and i can use the back button to return to the previous grid position when desired, got it.

however from the perspective of UI design, i don't know if the mental load of having to deal with the idea of different grids in different states is justified. maybe you desire to simplify the mental model and have just one grid in the browser stack; then IMHO such grid should never return to top or refresh by itself, but only after a specific user action. (a long tap on the "browse" icon could be a reasonable way to invoke a refresh; and i probably still would not return to top in that case.)

just food for thought.

right now (alpha 4), when i tap on "inbox", and then back to "browse", the grid is reset to the top position. IMHO (and this is very subjective) i think this behavior is detrimental. in my case, i want to be able to go back to the browse tab and continue where i was. i also noticed this while browsing the grid: wherever i go from there, say "inbox", if i tap "back" instead of "browse", it does return to the place i left off, which is what i always want. it seems as if i tap on "browse", a new browser level is added to the top of the browsing stack with the grid in the top position, but from there if i tap "back" and can go back to the "old grid" in the old position. this is ok... i understand the dynamics and i can use the back button to return to the previous grid position when desired, got it. however from the perspective of UI design, i don't know if the mental load of having to deal with the idea of different grids in different states is justified. maybe you desire to simplify the mental model and have just one grid in the browser stack; then IMHO such grid should never return to top or refresh by itself, but only after a specific user action. (a long tap on the "browse" icon could be a reasonable way to invoke a refresh; and i probably still would not return to top in that case.) just food for thought.
Sign in to join this conversation.
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
open-grind/open-grind#100
No description provided.