Report scroll metrics when page is resized

[hamza-kadiri]

Motivation

We currently have an issue in scrollmaps, as you can see in this widget, many users reach a scroll depth of 100% when the page scroll height is way lower than what it should be.

This is because when the user doesn't scroll, the scroll metrics are only reported once: at loading time.

Since loading time can be reached before the page is fully loaded, it means that we collect wrong scroll metrics

This PR aims to fix this issue by decorrelating scroll height reporting from scroll depth reporting.

Changes

• Use a ResizeObserver to report scroll height increase

Testing

Visit this page with the dev version of the sdk enabled and don't scroll. Clear the search, you should notice that the scroll height has increased

• Local
• Staging
• Unit
• End to end

---

I have gone over the contributing documentation.

[codecov-commenter]

Codecov Report

Merging #2399 (293a046) into main (a639866) will decrease coverage by 0.04%.
Report is 2 commits behind head on main.
The diff coverage is 94.28%.

@@            Coverage Diff             @@
##             main    #2399      +/-   ##
==========================================
- Coverage   94.01%   93.98%   -0.04%     
==========================================
  Files         219      219              
  Lines        6299     6317      +18     
  Branches     1402     1408       +6     
==========================================
+ Hits         5922     5937      +15     
- Misses        377      380       +3     

Files Changed	Coverage Δ
...lection/view/viewMetrics/trackCommonViewMetrics.ts	100.00% <ø> (ø)
...sCollection/view/viewMetrics/trackScrollMetrics.ts	95.23% <94.28%> (-4.77%)	⬇️

... and 1 file with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[bcaudan]

❓ question: ‏what about IE11? ResizeObserver is not supported there

[hamza-kadiri]

For IE11, the fallback solution is to collect data on the scrolling at regular intervals:

browser-sdk/packages/rum-core/src/domain/view/viewMetrics/trackScrollMetrics.ts

Lines 121 to 122 in 9ddc001

	const id = setInterval(notify, throttleDuration)
	return () => clearInterval(id)

[bcaudan]

oh right, so fallback to setInterval for IE 11 🤔
Do you see any pros / cons to have those two implementations rather than just always using setInterval?

[hamza-kadiri]

• cons:
  • we have two different implementations, which can be troublesome
• pros:
  • even if we have two implementations, the two still produce the same values, the only difference lies in the frequency with which these values are produced. For IE we're going to produce new values every second, for other browsers, we're going to produce them only when the page is scrolled or resized
  • on modern browser, since we produce values less often, we have less changes of causing layout shifts/reflows caused by scroll/viewport calculation

[bcaudan]

Indeed, the resize observer approach seems more "polite" than recomputing the values every second, I am wondering if it is not even too agressive for IE 😕
It could worth to double check that it does not degrade performances there.

Did you look into approaches taken by some resize observer polyfills?
In case there is some interesting alternate approach that could be used everywhere

[hamza-kadiri]

Do we have a way to test the SDK on IE?

I can definitely try an approach with a resize observer polyfill.

[bcaudan]

Do we have a way to test the SDK on IE?

Yes, with browserstack