AppFlowy-IO/AppFlowy

Fork 0

mirror of https://github.com/AppFlowy-IO/AppFlowy.git synced 2026-03-24 12:56:59 +00:00

[GH-ISSUE #2170] [FR] Remember the position of the previous viewed page #877

New issue

Open

opened 2026-03-23 20:42:25 +00:00 by mirror · 8 comments

mirror commented

2026-03-23 20:42:25 +00:00

Owner

Originally created by @annieappflowy on GitHub (Apr 3, 2023).
Original GitHub issue: https://github.com/AppFlowy-IO/AppFlowy/issues/2170

Originally assigned to: @richardshiue on GitHub.

Description

It would be useful if the current position of a scrolled page would be saved when changing pages so that I don't have to scroll from top to bottom when I come back to the previous page. Especially with long pages this would be a great advantage

Impact

Users who switch across pages to work on a project or write a document

Additional Context

No response

Originally created by @annieappflowy on GitHub (Apr 3, 2023). Original GitHub issue: https://github.com/AppFlowy-IO/AppFlowy/issues/2170 Originally assigned to: @richardshiue on GitHub. ### Description It would be useful if the current position of a scrolled page would be saved when changing pages so that I don't have to scroll from top to bottom when I come back to the previous page. Especially with long pages this would be a great advantage ### Impact Users who switch across pages to work on a project or write a document ### Additional Context _No response_

mirror added the

mobile

new feature

editor

labels

2026-03-23 20:42:25 +00:00

mirror commented

2026-03-23 20:42:26 +00:00

Author

Owner

@Xazin commented on GitHub (Jul 12, 2023):

I'm not sure if we need this. With tabs, you can now just open two tabs and the scroll persists unless you change the view in that tab.

This should be fine for now, right @annieappflowy ?

@Xazin commented on GitHub (Jul 12, 2023): I'm not sure if we need this. With tabs, you can now just open two tabs and the scroll persists unless you change the view in that tab. This should be fine for now, right @annieappflowy ?

mirror commented

2026-03-23 20:42:26 +00:00

Author

Owner

@annieappflowy commented on GitHub (Jul 13, 2023):

I guess your solution does improve the current experience

@annieappflowy commented on GitHub (Jul 13, 2023): I guess your solution does improve the current experience

mirror commented

2026-03-23 20:42:26 +00:00

Author

Owner

@richardshiue commented on GitHub (Jul 13, 2023):

While I think tabs does improve the experience, I still think this is still a feature that's nice to have for those who don't use tabs

@richardshiue commented on GitHub (Jul 13, 2023): While I think tabs does improve the experience, I still think this is still a feature that's nice to have for those who don't use tabs

mirror commented

2026-03-23 20:42:27 +00:00

Author

Owner

@Xazin commented on GitHub (Jul 13, 2023):

From my perspective it's a bit weird, I have never seen this in an application before.

I believe this request came from a lack of organisational features, however the proposed solution defies the norm and can lead to confusing UX.

@Xazin commented on GitHub (Jul 13, 2023): From my perspective it's a bit weird, I have never seen this in an application before. I believe this request came from a lack of organisational features, however the proposed solution defies the norm and can lead to confusing UX.

mirror commented

2026-03-23 20:42:27 +00:00

Author

Owner

@hyj1204 commented on GitHub (Sep 14, 2023):

I feel the core of this request depends on what is the user's intention when leaving a page.
When a user chooses to leave a page, they may fall into one of the following scenarios.

Scenario 1: The user has completed their tasks on the current page. They want to open a new page and close the previous one. In this case, the user expects every page to open from the beginning.
Scenario 2: The user has not completed their tasks on the current page. Becuase they can only view one page at a time(at least for 0.3.1 version), they has to open a new page to access different content. In this case, they want to back to their previous location to continue from where they left off. This occurs because their initial tasks on the first page remain unfinished.

When contemplating whether to display a page from the last viewed position, we must consider which scenario it caters to: For the users who have completed their tasks (Scenario 1) or the users who have unfinished work (Scenario 2).

It is important not to mix these two scenarios. Additionally in Case 2, it is essientail to include a close button that allows users to confirm the completion of their tasks

From my perspective, in the recent 0.3.1 version:

The normal way to open a new page from clicking the title in the sidebar is to serve Scenario 1.
The Tabbar view mode is to serve Scenario 2.

In the future, when considering the implementation of a new page view mode (#2312), we can utilize this approach to determine whether it's necessary to show the last viewed location.

@hyj1204 commented on GitHub (Sep 14, 2023): I feel the core of this request depends on **what is the user's intention when leaving a page**. When a user chooses to leave a page, they may fall into one of the following scenarios. - Scenario 1: The user has **completed** their tasks on the current page. They want to open a new page and close the previous one. In this case, the user expects every page to open from the beginning. - Scenario 2: The user has **not completed** their tasks on the current page. Becuase they can only view one page at a time(at least for 0.3.1 version), they has to open a new page to access different content. In this case, they want to back to their previous location to continue from where they left off. This occurs because their initial tasks on the first page remain unfinished. When contemplating whether to display a page from the last viewed position, we must consider which scenario it caters to: For the users who have completed their tasks (Scenario 1) or the users who have unfinished work (Scenario 2). It is important not to mix these two scenarios. Additionally in Case 2, it is essientail to include a close button that allows users to confirm the completion of their tasks From my perspective, in the recent 0.3.1 version: - The normal way to open a new page from clicking the title in the sidebar is to serve Scenario 1. - The Tabbar view mode is to serve Scenario 2. In the future, when considering the implementation of a new page view mode (#2312), we can utilize this approach to determine whether it's necessary to show the last viewed location.

mirror commented

2026-03-23 20:42:27 +00:00

Author

Owner

@Xazin commented on GitHub (Sep 14, 2023):

I feel the core of this request depends on what is the user's intention when leaving a page.

When a user chooses to leave a page, they may fall into one of the following scenarios.

Scenario 1: The user has completed their tasks on the current page. They want to open a new page and close the previous one. In this case, the user expects every page to open from the beginning.

Scenario 2: The user has not completed their tasks on the current page. Becuase they can only view one page at a time(at least for 0.3.1 version), they has to open a new page to access different content. In this case, they want to back to their previous location to continue from where they left off. This occurs because their initial tasks on the first page remain unfinished.

When contemplating whether to display a page from the last viewed position, we must consider which scenario it caters to: For the users who have completed their tasks (Scenario 1) or the users who have unfinished work (Scenario 2).

It is important not to mix these two scenarios. Additionally in Case 2, it is essientail to include a close button that allows users to confirm the completion of their tasks

From my perspective, in the recent 0.3.1 version:

The normal way to open a new page from clicking the title in the sidebar is to serve Scenario 1.

The Tabbar view mode is to serve Scenario 2.

In the future, when considering the implementation of a new page view mode (#2312), we can utilize this approach to determine whether it's necessary to show the last viewed location.

I agree.

One of the reasons I was partly against this request, is because I primarily experience scenario 1, and it would frustrate me. Considering I come back to a document which might have been closed for long, and end up in a previously scrolled to position, not to mention that this position might have become outdated, as the document content could have been modified since my last visit. (By someone else or myself on another device)

Users are already trained for handling scenario 2, as this is how most editors, and all web browsers work.

@Xazin commented on GitHub (Sep 14, 2023): > I feel the core of this request depends on **what is the user's intention when leaving a page**. > > When a user chooses to leave a page, they may fall into one of the following scenarios. > > > > - Scenario 1: The user has **completed** their tasks on the current page. They want to open a new page and close the previous one. In this case, the user expects every page to open from the beginning. > > - Scenario 2: The user has **not completed** their tasks on the current page. Becuase they can only view one page at a time(at least for 0.3.1 version), they has to open a new page to access different content. In this case, they want to back to their previous location to continue from where they left off. This occurs because their initial tasks on the first page remain unfinished. > > > > When contemplating whether to display a page from the last viewed position, we must consider which scenario it caters to: For the users who have completed their tasks (Scenario 1) or the users who have unfinished work (Scenario 2). > > > > It is important not to mix these two scenarios. Additionally in Case 2, it is essientail to include a close button that allows users to confirm the completion of their tasks > > > > From my perspective, in the recent 0.3.1 version: > > > > - The normal way to open a new page from clicking the title in the sidebar is to serve Scenario 1. > > - The Tabbar view mode is to serve Scenario 2. > > > > In the future, when considering the implementation of a new page view mode (#2312), we can utilize this approach to determine whether it's necessary to show the last viewed location. I agree. One of the reasons I was partly against this request, is because I primarily experience scenario 1, and it would frustrate me. Considering I come back to a document which might have been closed for long, and end up in a previously scrolled to position, not to mention that this position might have become outdated, as the document content could have been modified since my last visit. (By someone else or myself on another device) Users are already trained for handling scenario 2, as this is how most editors, and all web browsers work.

mirror commented

2026-03-23 20:42:27 +00:00

Author

Owner

@hyj1204 commented on GitHub (Sep 14, 2023):

@Xazin Totally understandable, I also feel creating a distinct UX experience for these two scenarios is important too so that users won't get confused by its purpose.
For example, for scenario 2, no matter whether the page view is a tab, panel, or other type of window, we can consider always putting page titles on the top of the page(like a web browser style). For scenario 1, put titles on the left side instead.

@hyj1204 commented on GitHub (Sep 14, 2023): @Xazin Totally understandable, I also feel creating a distinct UX experience for these two scenarios is important too so that users won't get confused by its purpose. For example, for scenario 2, no matter whether the page view is a tab, panel, or other type of window, we can consider always putting page titles **on the top of** the page(like a web browser style). For scenario 1, put titles **on the left side** instead.

mirror commented

2026-03-23 20:42:28 +00:00

Author

Owner

@emmggi commented on GitHub (Apr 22, 2024):

I'd like to add my use case here as I asked for the same feature.

My reasoning behind using this feature is that I have a long document with sections that I will come back to work on in multiple occasions and looking for where I last was could be frustrating because it either may have been a long time ago so I forgot, or the document is just big.

For those that don't want this behavior, we could just not preserve the location of the cursor if it's at the end of the document, or just have a switch in settings to not use it at all.

Tabs aren't a complete replacement for this because they will lose scroll position after the app is reopened.

It is important not to mix these two scenarios. Additionally in Case 2, it is essientail to include a close button that allows users to confirm the completion of their tasks

From my perspective, in the recent 0.3.1 version:

The normal way to open a new page from clicking the title in the sidebar is to serve Scenario 1.
The Tabbar view mode is to serve Scenario 2.

What I think would also work is adding a special attribute to a node, through an option in the existing node menu. So then you could just label a document node in a page and the page will open at that position. If there's more of these special nodes then you'd open at the last one that was created.

By node menu I mean this

@emmggi commented on GitHub (Apr 22, 2024): I'd like to add my use case here as I asked for the same feature. My reasoning behind using this feature is that I have a long document with sections that I will come back to work on in multiple occasions and looking for where I last was could be frustrating because it either may have been a long time ago so I forgot, or the document is just big. For those that don't want this behavior, we could just not preserve the location of the cursor if it's at the end of the document, or just have a switch in settings to not use it at all. Tabs aren't a complete replacement for this because they will lose scroll position after the app is reopened. > It is important not to mix these two scenarios. Additionally in Case 2, it is essientail to include a close button that allows users to confirm the completion of their tasks > >From my perspective, in the recent 0.3.1 version: > > The normal way to open a new page from clicking the title in the sidebar is to serve Scenario 1. > The Tabbar view mode is to serve Scenario 2. What I think would also work is adding a special attribute to a node, through an option in the existing node menu. So then you could just label a document node in a page and the page will open at that position. If there's more of these special nodes then you'd open at the last one that was created. By node menu I mean this ![image](https://github.com/AppFlowy-IO/AppFlowy/assets/45419292/5e4a51e5-8225-480d-a9dc-90ac2f5ebcf6)

mirror referenced this issue

2026-03-23 21:37:40 +00:00

[PR #877] [MERGED] chore: fix some bugs and add more tests #4407