Scenario contact: @javiercn
Scenario
This scenario validates that two reported bugs are fixed. Both were filed against .NET 10 enhanced navigation, and both are about the browser ending up somewhere the user did not ask for.
- A same-page anchor still fetched the page. With
data-enhance-nav="false" on the navigation container, clicking a link to an anchor on the current page, such as /#contact-us, still issued a fetch. Turning enhanced navigation off was meant to leave the browser to scroll natively. (#63396)
- Scroll reset ran before the new content rendered. Navigating from one page to another started the scroll immediately, so the user watched the old page scroll past before the new one appeared. (#64015)
Both are fixed in .NET 11. This validates the fixes, and the surrounding hash-link behavior while you are there.
Minimum build
.NET 11 Preview 7 or later.
Configurations to cover
Enhanced navigation belongs to Blazor Web Apps. Both reported bugs reproduce with statically rendered pages; Interactive Server is included because a circuit makes the destination content arrive in more stages, which is where the scroll timing bug was visible.
Also exercise
Setup
Throttle the network in the browser. The scroll timing bug is only visible when there is a gap between the navigation starting and the content arriving, and on a fast local connection there is not one.
What to build
Two pages, each several screens tall so the scrolling is real, with a heading part way down carrying an anchor such as #contact-us. Give the two pages obviously different backgrounds, so you can tell at a glance which one is on screen part way through a navigation.
Add two navigation containers holding the same three links:
- An ordinary nav menu.
- One marked
data-enhance-nav="false".
The three links are: an anchor on the current page, an anchor on the other page, and the other page with no anchor.
Things to try
The first two are the reported repros. Watch the network tab for the first, and the page itself for the second.
- From the
data-enhance-nav="false" container, click the link to an anchor on the current page and watch the network tab. This is the first reported bug.
- Scroll to the bottom of page one, then click a plain link to page two and watch what is on screen while the scroll happens. This is the second reported bug.
- The same same-page anchor link from the ordinary nav container.
- An anchor link pointing at the other page.
- Browser back and forward across each of those navigations.
- Reloading directly on an address that includes an anchor.
Expected behavior
The browser ends up where the link pointed, and never shows the previous page's content moving on the way there.
Must hold
- Clicking a same-page anchor link inside a
data-enhance-nav="false" container issues no request in the network tab, and the browser scrolls to the anchor natively.
- Navigating from the bottom of page one to page two shows no frame of page one's content scrolling. The new content appears first, then the position settles.
- An anchor link pointing at the other page loads that page and lands on the named anchor, not at the top.
- A plain link to the other page lands at the top of that page.
- A same-page anchor link in the ordinary nav container also lands on the anchor.
- Browser back and forward return to the positions the user was at.
Evidence to capture
A short screen recording of the throttled navigation between the two long pages. The reported symptom is a flash that a still screenshot cannot show. For the anchor case, a screenshot of the network tab showing no request.
Documentation to use
What to report
Report results using the format described in the validation testing manual. Include link to a repository with the test app.
Scenario contact: @javiercn
Scenario
This scenario validates that two reported bugs are fixed. Both were filed against .NET 10 enhanced navigation, and both are about the browser ending up somewhere the user did not ask for.
data-enhance-nav="false"on the navigation container, clicking a link to an anchor on the current page, such as/#contact-us, still issued a fetch. Turning enhanced navigation off was meant to leave the browser to scroll natively. (#63396)Both are fixed in .NET 11. This validates the fixes, and the surrounding hash-link behavior while you are there.
Minimum build
.NET 11 Preview 7 or later.
Configurations to cover
Enhanced navigation belongs to Blazor Web Apps. Both reported bugs reproduce with statically rendered pages; Interactive Server is included because a circuit makes the destination content arrive in more stages, which is where the scroll timing bug was visible.
Also exercise
Setup
Throttle the network in the browser. The scroll timing bug is only visible when there is a gap between the navigation starting and the content arriving, and on a fast local connection there is not one.
What to build
Two pages, each several screens tall so the scrolling is real, with a heading part way down carrying an anchor such as
#contact-us. Give the two pages obviously different backgrounds, so you can tell at a glance which one is on screen part way through a navigation.Add two navigation containers holding the same three links:
data-enhance-nav="false".The three links are: an anchor on the current page, an anchor on the other page, and the other page with no anchor.
Things to try
The first two are the reported repros. Watch the network tab for the first, and the page itself for the second.
data-enhance-nav="false"container, click the link to an anchor on the current page and watch the network tab. This is the first reported bug.Expected behavior
The browser ends up where the link pointed, and never shows the previous page's content moving on the way there.
Must hold
data-enhance-nav="false"container issues no request in the network tab, and the browser scrolls to the anchor natively.Evidence to capture
A short screen recording of the throttled navigation between the two long pages. The reported symptom is a flash that a still screenshot cannot show. For the anchor case, a screenshot of the network tab showing no request.
Documentation to use
What to report
Report results using the format described in the validation testing manual. Include link to a repository with the test app.