[Blazor] Scroll position persists during page navigation.

[rxelizondo]

Describe the bug

When navigating from page to page, the scroll position is persisted instead of resetting.

To Reproduce

1. Create a razor page and call it Page1.razor, then paste the following code on the page:

@for (int i = 0; i <= 1000; i++)
{
    <h1>I will pay attention in school</h1>
}
<a href="Page2">Go to page 2</a>

2. Create a second razor page and call it Page2.razor, then paste the following code on the page:

@for (int i = 0; i <= 1000; i++)
{
    <h1>1 + 1 = 3</h1>
}

3. Start the app, navigate to Page1 and scroll all the way down until you see the Go to page 2 link.
4. Click the Go to page 2 link.

The correct behavior (in my opinion) should be for Page2 scroll position to be at the top of the page. Instead, Page2 is scrolled down to the same scroll position Page1 was.

This happens at least in Chrome and Edge.

[Andrzej-W]

I have seen this many times. I agree that it is more natural to display a new page from the beginning. Current behaviour is especially confusing when you have a few pages with different length. From the point of view of app user each page is displayed with random scroll position.

[mkArtakMSFT]

Not pushing out of preview8, as this will result in behavior breaking change

[Andrzej-W]

For those who want to see this annoying behaviour I have found a demo of Blazor Strap here: https://chanan.github.io/BlazorStrap/
with two independently scrollable regions: menu on the left and main content on the right.

I was thinking a little bit about this and the problem is that people can design sophisticated layouts to create an impression that Blazor app is like a desktop app. To achieve this they can use flexbox, flexgrid, static/absolute positioning or other techniques. So the question is: for which HTML element should we reset vertical scroll position after navigation? I think that we should start searching from the first element in the layout which contains @Body and go up in the hierarchy. Scroll position should be reset in the first element which can be scrolled vertically, which is probably the one which has overflow-y set to auto or scroll (or inherits this setting).

If it is not easy or doesn't provide expected results in all possible layouts we should be able to configure application manually to reset vertical scroll position in specified element after each navigation. This element can potentially change at runtime if we have more than one layout defined in an application.

[SteveSandersonMS]

Done in #12423