fix(browser): Ensure pageload trace remains active after pageload span finished

[Lms24]

While working on integration tests for #11599, I found that initial pageload traces still ended after the pageload root span was ended due to us actively resetting the propagation context this way.

This PR removes the now incorrect propagationContext resetting logic for pageload spans and adds tests to cover this (and closely related) scenario.

ref #11599

[Lms24]

moved this test to the trace-lifetime directory where I plan on putting all tests from #11599

[lforst]

nice find

[github-actions]

size-limit report 📦

Path	Size
@sentry/browser	22.16 KB (0%)
@sentry/browser (incl. Tracing)	31.74 KB (-0.04% 🔽)
@sentry/browser (incl. Tracing, Replay)	67.06 KB (-0.02% 🔽)
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	60.47 KB (-0.02% 🔽)
@sentry/browser (incl. Tracing, Replay with Canvas)	70.89 KB (-0.02% 🔽)
@sentry/browser (incl. Tracing, Replay, Feedback)	80.78 KB (-0.03% 🔽)
@sentry/browser (incl. Feedback)	35.71 KB (0%)
@sentry/browser (incl. Feedback, Feedback Modal)	35.71 KB (0%)
@sentry/browser (incl. Feedback, Feedback Modal, Feedback Screenshot)	37.74 KB (0%)
@sentry/browser (incl. sendFeedback)	26.95 KB (0%)
@sentry/react	24.84 KB (0%)
@sentry/react (incl. Tracing)	34.64 KB (-0.03% 🔽)
@sentry/vue	25.73 KB (0%)
@sentry/vue (incl. Tracing)	33.45 KB (-0.06% 🔽)
@sentry/svelte	22.29 KB (0%)
CDN Bundle	24.48 KB (0%)
CDN Bundle (incl. Tracing)	32.97 KB (-0.03% 🔽)
CDN Bundle (incl. Tracing, Replay)	66.59 KB (-0.02% 🔽)
CDN Bundle (incl. Tracing, Replay, Feedback)	82.8 KB (-0.01% 🔽)
CDN Bundle - uncompressed	72.9 KB (0%)
CDN Bundle (incl. Tracing) - uncompressed	98.9 KB (-0.06% 🔽)
CDN Bundle (incl. Tracing, Replay) - uncompressed	208.55 KB (-0.03% 🔽)
@sentry/nextjs (client)	34.01 KB (-0.02% 🔽)
@sentry/sveltekit (client)	32.25 KB (-0.03% 🔽)
@sentry/node	120.17 KB (-0.01% 🔽)

[mydea]

Hmm, do we not need to extend this then to ensure we also update the propagation context when a navigation span starts? And add a test to cover this scenario:

1. Pageload starts trace A
2. Pageload is over - spans are still added to trace A
3. Navigation starts trace B
4. Navigation is over - spans are still added to trace B --> I think with the current logic this case would again attach to trace A?

--> I guess this is this test here: #11601 if that passes, all good I guess 😅

[Lms24]

do we not need to extend this then to ensure we also update the propagation context when a navigation span starts

We already do this and #11601 adds a test for this scenario (already verified locally - the test passes).

Pageload is over - spans are still added to trace A

Do you mean standalone spans? I'm not sure what the scenario is here and how we best test this, given that currently the only standalone spans are INP spans and they're not yet in v8 and a bit unpredictable afaict 🤔

[mydea]

do we not need to extend this then to ensure we also update the propagation context when a navigation span starts

We already do this and 11601 adds a test for this scenario (already verified locally - the test passes).

Pageload is over - spans are still added to trace A

Do you mean standalone spans? I'm not sure what the scenario is here and how we best test this, given that currently the only standalone spans are INP spans and they're not yet in v8 and a bit unpredictable afaict 🤔

All good, I saw the other test that covers this!

Only thing missing then (which we can do in a follow up) is to also keep the DSC from the pageload/navigation spans on the propagation context when they end, but that's a further improvement 🚀