link to section replaces url with wrong id when section above is not visible anymore #1893

New Issue

claunia · 2026-01-29T17:59:51Z

claunia commented

2026-01-29 17:59:51 +00:00

Originally created by @Anspitzen on GitHub (Oct 29, 2025).

Describe the bug
When going to for example Layout - Breakpoints it jumps correctly to the section breakpoints. But the url points to the next section, Usage, after finishing automatic scrolling. So on reload you end up on wrong section. Correct url is only shown when scrolling up so text from above is visible (previous section content)

To Reproduce
Steps to reproduce the behavior:

Go to page
F5 / reload
See error
Scroll up and see correct url getting inserted when full block + somehting on top is visible
Click on the Link icon next to the section headline and see scrolling to align top of viewprot with headline and then again wrong url

Expected behavior
URL does not get replaced until the block is really going out of view

Desktop (please complete the following information):

OS: windows
Browser chrome
Version latest

Additional context
Does also happen on other points with sections to jump to, not only the breakpoints

Originally created by @Anspitzen on GitHub (Oct 29, 2025). **Describe the bug** When going to for example [Layout - Breakpoints](https://blazor.radzen.com/breakpoints?theme=material3#breakpoints) it jumps correctly to the section breakpoints. But the url points to the next section, Usage, after finishing automatic scrolling. So on reload you end up on wrong section. Correct url is only shown when scrolling up so text from above is visible (previous section content) **To Reproduce** Steps to reproduce the behavior: 1. Go to [page](https://blazor.radzen.com/breakpoints?theme=material3#breakpoints) 2. F5 / reload 4. See error 5. Scroll up and see correct url getting inserted when full block + somehting on top is visible 6. Click on the Link icon next to the section headline and see scrolling to align top of viewprot with headline and then again wrong url **Expected behavior** URL does not get replaced until the block is really going out of view **Desktop (please complete the following information):** - OS: windows - Browser chrome - Version latest **Additional context** Does also happen on other points with sections to jump to, not only the breakpoints

claunia closed this issue

2026-01-29 17:59:51 +00:00

claunia commented

2026-01-29 17:59:51 +00:00

@akorchev commented on GitHub (Nov 3, 2025):

Indeed this is the current behaviour when more than one section is determined to be visible at a time. We are open to suggestions for improvement. The relevant code is here: b98dffda8f/Radzen.Blazor/wwwroot/Radzen.Blazor.js (L2577-L2607)

@akorchev commented on GitHub (Nov 3, 2025): Indeed this is the current behaviour when more than one section is determined to be visible at a time. We are open to suggestions for improvement. The relevant code is here: https://github.com/radzenhq/radzen-blazor/blob/b98dffda8fd559a4e87b70ecd0d0acc6da2649cb/Radzen.Blazor/wwwroot/Radzen.Blazor.js#L2577-L2607

claunia commented

2026-01-29 17:59:52 +00:00

@Anspitzen commented on GitHub (Nov 4, 2025):

So current behaviour:
Section in Url is the lowest element.top above (vertical) center of viewport
One easy way to do would be moving that "center" line up, like lowest headline visible above the top quarter of viewport

One other way would be chcking if the previous element is still fully visible on page and then not taking any the new url/match closer to center.
Take the top most still visible rect.top (which is above center) as section:

const contTop = container.tagName === 'HTML' ? 0 : container.getBoundingClientRect().top;
const center = contTop + container.clientHeight / 2; 
  
 let min = Number.MAX_SAFE_INTEGER; 
 let match; 
  
 for (let i = 0; i < elements.length; i++) { 
   const element = elements[i]; 
   if (!element) continue; 
  
   const rect = element.getBoundingClientRect(); 
  
   if (!match && rect.top < center) { 
     match = selectors[i]; 
     min = rect.top; 
     continue; 
   } 
  
   if (match && rect.top >= center) continue; 
   
   if (match && (min < contTop || rect.top < min && rect.top >= contTop)) { 
     match = selectors[i]; 
     min = rect.top; 
   } 
 } 
  
 if (match !== currentSelector) { 
   currentSelector = match; 
   this.navigateTo(currentSelector, false); 
   ref.invokeMethodAsync('ScrollIntoView', currentSelector); 
 }

in words: If the previous match is above center (because the other two ifs) and either the previous match top is outside of container OR current rect is closer to top of container than the previous
Then take the new section. So topmost headline visible above center of container is the active section

Edit for edge case of two or more sections above center at the start an no possibility to scroll (page starts with two really short sections and fits completely on screen): Here the scroll will always take the first section as it can't go out of view. But at the same time the function will never run as there is no scroll and any link to the section will be visible anyways on page when jumpging to link with section

@Anspitzen commented on GitHub (Nov 4, 2025): So current behaviour: Section in Url is the lowest element.top above (vertical) center of viewport One easy way to do would be moving that "center" line up, like lowest headline visible above the top quarter of viewport One other way would be chcking if the previous element is still fully visible on page and then not taking any the new url/match closer to center. Take the top most still visible rect.top (which is above center) as section: ``` const contTop = container.tagName === 'HTML' ? 0 : container.getBoundingClientRect().top; const center = contTop + container.clientHeight / 2; let min = Number.MAX_SAFE_INTEGER; let match; for (let i = 0; i < elements.length; i++) { const element = elements[i]; if (!element) continue; const rect = element.getBoundingClientRect(); if (!match && rect.top < center) { match = selectors[i]; min = rect.top; continue; } if (match && rect.top >= center) continue; if (match && (min < contTop || rect.top < min && rect.top >= contTop)) { match = selectors[i]; min = rect.top; } } if (match !== currentSelector) { currentSelector = match; this.navigateTo(currentSelector, false); ref.invokeMethodAsync('ScrollIntoView', currentSelector); } ``` in words: If the previous match is above center (because the other two ifs) and either the previous match top is outside of container OR current rect is closer to top of container than the previous Then take the new section. So topmost headline visible above center of container is the active section Edit for edge case of two or more sections above center at the start an no possibility to scroll (page starts with two really short sections and fits completely on screen): Here the scroll will always take the first section as it can't go out of view. But at the same time the function will never run as there is no scroll and any link to the section will be visible anyways on page when jumpging to link with section

claunia commented

2026-01-29 17:59:52 +00:00

@akorchev commented on GitHub (Nov 4, 2025):

Hi @Anspitzen,

Feel free to submit a pull request with the suggested improvement.

@akorchev commented on GitHub (Nov 4, 2025): Hi @Anspitzen, Feel free to submit a pull request with the suggested improvement.

claunia commented

2026-01-29 17:59:52 +00:00

@akorchev commented on GitHub (Nov 25, 2025):

I think the scroll tracking can't work 100% in all cases - if more than one (or all) sections are visible at the same time the one closest to the center would be selected as "current". Even if we change that to be "the first visible one" things again would look wrong for some other scenarios such as clicking a different anchor and reloading the browser. I tested a few other implementations in different web sites and they all seem to fail in edge cases. There is just no way to determine which is the "current" section if more than one section meets the requirement.

This is why I think it would be best to add an option that disables scroll tracking altogether for people that don't want it.

@akorchev commented on GitHub (Nov 25, 2025): I think the scroll tracking can't work 100% in all cases - if more than one (or all) sections are visible at the same time the one closest to the center would be selected as "current". Even if we change that to be "the first visible one" things again would look wrong for some other scenarios such as clicking a different anchor and reloading the browser. I tested a few other implementations in different web sites and they all seem to fail in edge cases. There is just no way to determine which is the "current" section if more than one section meets the requirement. This is why I think it would be best to add an option that disables scroll tracking altogether for people that don't want it.

claunia commented

2026-01-29 17:59:52 +00:00

@akorchev commented on GitHub (Dec 8, 2025):

Hi @Anspitzen,

Some changes have been made in the scrolling code in #2370. Does it work for your case now?

@akorchev commented on GitHub (Dec 8, 2025): Hi @Anspitzen, Some changes have been made in the scrolling code in #2370. Does it work for your case now?

claunia commented

2026-01-29 17:59:52 +00:00

@akorchev commented on GitHub (Dec 10, 2025):

I am closing the issue since the original problem seems to be addressed.

@akorchev commented on GitHub (Dec 10, 2025): I am closing the issue since the original problem seems to be addressed.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/radzen-blazor#1893