scrollToHashedElement inconsistent due to page load and loading content

[JasonHowellSlavin]

Hi community,

Magma has a ticket to ensure that # anchors in URLs actually scroll to the parts of the pages where the id resides. For most pages, this is not an issue, for instance, https://business.adobe.com/#business-solutions-from-adobe--the-digital-experience-leader will scroll to the correct location. However, as soon as you attempt to scroll to, or scroll past, long loading content--like Marketo forms or CaaS--the viewport does not scroll to the correct location. For example, this page where we are attempting to scroll past a fragment with CaaS. .

I have noticed that the scrollToHashedElement inconsistency occurs with the following conditions:

• Scrolling to content loading on a shorter page. See this page
• Setting the scroll ID to blocks that load content from elsewhere. On some longer pages, this works fine, see marketo engage
• Setting the scroll ID past blocks that load external content. See resources

What is odd, is when logging out or debugging the value that is used in the window.scrollTo function, it is often correct. If you take the value that scrolledToHashedElement uses and place it in the console in your own call of scrollTo, it often works.

I have tried several approaches:

• Moving scrollToHashedElement out of loadArea, and placing it in consumer scripts after loadArea is called.
• Adding metadata to add to the value passed to scrollToHashedElement.
• Adding a window load event listener and calling scrollToHashedElement.
• In order to test that it was a timing issue, used setTimeout to fire scrollToHashedElement (which solves the issue when waiting for ~1.5 seconds, but is not a reliable or good solution).

Nothing was really satisfactory, and so I wanted to know if anyone had any additional insight that could help with this issue? Another thought I had is if CaaS or Marketo fired events when they loaded, we could add some logic to the scroll to wait for those if those blocks are present as they seem to be the main culprits.

Please let me know your thoughts, and thank you!

[auniverseaway]

There are parts that Milo can control for load and parts that it cannot.

I would probably advocate that Milo fires an event after footer is visible.

There's a small chance there's still content in the middle to load, but you would also have CLS issues (or intersection observers) if that was the case.

I think this would get you further than anything else, but it may take too long. You visitors probably scrolls before the event fires.

This is an age old problem with dynamic content we assemble in real-time.

[JasonHowellSlavin]

After testing a "post Footer load" scroll, the results were not acceptable for good UX (~3s for cached, ~5s for non-cached).