Skip to content

Conversation

@Anspitzen
Copy link

Referencing #2328, take the top most visible section as url reference instead of the clostest element.top to and above center line of app container

Referencing radzenhq#2328, take the top most visible section as url reference instead of the clostest element.top to and above center line of app container
@akorchev
Copy link
Collaborator

akorchev commented Nov 4, 2025

Hi @Anspitzen,

Thank you for the pull request. For some reason I still see similar behavior as before - reloading the page scrolls to the wrong section. Here is what I see breakpoints

@akorchev
Copy link
Collaborator

akorchev commented Nov 5, 2025

I did further investigation and it seems that most of the problem is the initial scroll - when the browser itself scrolls to the current anchor. Then our code runs and may detect a different section. Thus I propose this change which simply ignores the first scroll provided the conditions are met:

--- a/Radzen.Blazor/wwwroot/Radzen.Blazor.js
+++ b/Radzen.Blazor/wwwroot/Radzen.Blazor.js
@@ -2573,7 +2573,19 @@ window.Radzen = {
       const elements = selectors.map(document.querySelector, document);
 
       this.unregisterScrollListener(element);
+      let suppressInitialScroll = false;
+
+      if (selectors.indexOf(location.hash) !== -1) {
+        currentSelector = location.hash;
+        suppressInitialScroll = true;
+      }
+
       element.scrollHandler = () => {
+        if (suppressInitialScroll) {
+          suppressInitialScroll = false;
+          ref.invokeMethodAsync('ScrollIntoView', currentSelector);
+          return;
+        }
         const center = (container.tagName === 'HTML' ? 0 : container.getBoundingClientRect().top) + container.clientHeight / 2;

You can test the changes in the suppress-initial-scroll branch.

@akorchev
Copy link
Collaborator

Hi @Anspitzen,

Could you please test my change in the linked branch? It seems to work fine but I want to be sure your case works too.

@Anspitzen
Copy link
Author

I did check it, and it still has some unwanted behaviour. Still thinking on how to possible solve that here.
Scrolling does not happen only on initial scroll, another programmical triggered scroll is also when copying a link for a section. That is also scrolling the section to the top, which will trigger scrolling detection and may replace section again. Which is equally confusing as you have copyed a link to url, it scrolls to that url and then shows another section

@Anspitzen
Copy link
Author

Another trigger would be when you have some scrolling in a component (like datagrid)
Example for demonstration purposes: https://blazor.radzen.com/example-upload?theme=standard&rtl=false#url
Scroll to the point that the "Upload multiple files" Headline comes into the URL (#multiple as url parameter)
Then just select two pictures to upload in the "Upload files to a server" part. The EventConsole will grow as it shows 5 lines. This growing in turn shoves the Multiple part below the halfline, so it should ge off the url and the #url-part should be the active on scrolling. The growing itself will not trigger it, only a scroll.
Now the point: The EventConsole now has 6 entries, so it allows scrolling inside the component, no scroll on the body itself! This scrolling will trigger the script also and url will update.

I do confess, this handling is pretty unlikely to happen in the wild, but I did it to check when the scrolling scrippt will be triggered.
Possible handling for it to happen would be jumping to the url-section, having a scroll-component and scrolling inside the grid you jumped to. When another section is showing above the middle of viewport the scrolling inside a component will update url even if you never moved the headlines

@akorchev
Copy link
Collaborator

Those observations are valid but I don't have a solution for them. Sometimes just more than one section is "visible" so there is no clear way to determine what to highlight. Not to mention the case when all items are visible (sections are too short).

Perhaps we should just add an option to disable active element tracking on scroll.

@akorchev
Copy link
Collaborator

I am closing this PR since the proposed solution doesn't seem to address the original problem completely.

@akorchev akorchev closed this Nov 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants