[RUM-14619] Add setViewLoadingTime() public API

[MaelNamNam]

Motivation

Allow developers to manually report view loading time for complex async patterns (SPAs with deferred fetching, skeleton screens) where auto-detection is inaccurate.

Brings Browser SDK to parity with iOS/Android SDKs.

Changes

New experimental public API: DD_RUM.setViewLoadingTime()

• Marked as [Experimental] via JSDoc annotation (no runtime feature flag required)
• Loading time = elapsed since current view start
• First call suppresses auto-detected loading time
• Last call always wins
• Pre-start buffering supported (calls before init() are drained with preserved timestamps)
• Works with startView() / manuallyTrackViews — timer resets for each new view
• Telemetry sends feature: 'addViewLoadingTime' only (browser omits overwritten, no_view, and no_active_view — kept optional in schema for mobile compat)

Note: The enableExperimentalFeatures: ['set_view_loading_time'] runtime gate has been removed. The API is available without any flag, consistent with other experimental APIs (startAction, stopAction, startResource, stopResource).

Upstream dep: rum-events-format#352 has been merged, submodule updated to 5ddfd3b, types regenerated, and [MANUAL] annotation removed from this PR. AddViewLoadingTime is now auto-generated from the schema.

Test instructions

yarn test:unit --spec packages/rum-core/src/domain/view/trackViews.spec.ts
yarn test:unit --spec packages/rum-core/src/boot/rumPublicApi.spec.ts
yarn test:unit --spec packages/rum-core/src/boot/preStartRum.spec.ts
yarn test:e2e:init && yarn test:e2e -g "manual loading time"

Checklist

• Tested locally
• Tested on staging
• Added unit tests for this change.
• Added e2e/integration tests for this change.
• Updated documentation and/or relevant AGENTS.md file

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[cit-pr-commenter-54b7da]

Bundles Sizes Evolution

📦 Bundle Name	Base Size	Local Size	𝚫	𝚫%	Status
Rum	174.43 KiB	174.85 KiB	+430 B	+0.24%	✅
Rum Profiler	6.16 KiB	6.16 KiB	0 B	0.00%	✅
Rum Recorder	25.24 KiB	25.24 KiB	0 B	0.00%	✅
Logs	56.84 KiB	56.84 KiB	0 B	0.00%	✅
Flagging	944 B	944 B	0 B	0.00%	✅
Rum Slim	130.12 KiB	130.50 KiB	+399 B	+0.30%	✅
Worker	23.63 KiB	23.63 KiB	0 B	0.00%	✅

🚀 CPU Performance

Action Name	Base CPU Time (ms)	Local CPU Time (ms)	𝚫%
RUM - add global context	0.004	0.0041	+2.50%
RUM - add action	0.0131	0.0133	+1.53%
RUM - add error	0.0134	0.0127	-5.22%
RUM - add timing	0.0032	0.0027	-15.63%
RUM - start view	0.013	0.0132	+1.54%
RUM - start/stop session replay recording	0.0008	0.0006	-25.00%
Logs - log message	0.0185	0.015	-18.92%

🧠 Memory Performance

Action Name	Base Memory Consumption	Local Memory Consumption	𝚫
RUM - add global context	27.26 KiB	27.00 KiB	-266 B
RUM - add action	51.75 KiB	51.78 KiB	+35 B
RUM - add timing	26.51 KiB	26.61 KiB	+99 B
RUM - add error	55.32 KiB	54.72 KiB	-611 B
RUM - start/stop session replay recording	25.65 KiB	26.03 KiB	+390 B
RUM - start view	452.33 KiB	463.29 KiB	+10.96 KiB
Logs - log message	45.05 KiB	44.75 KiB	-308 B

🔗 RealWorld

[datadog-datadog-prod-us1]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
• Patch Coverage: 85.00%
• Overall Coverage: 76.78% (-0.41%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 0188cfa | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback!}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: f4e10304d9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[MaelNamNam]

I have read the CLA Document and I hereby sign the CLA

[mormubis]

Overall the implementation is clean and well-tested — moving the state into trackCommonViewMetrics was the right call. A few things worth addressing.

[mormubis]

Since you're already hand-editing this block under [MANUAL], worth renaming the interface to SetViewLoadingTime to match the feature string ('set-view-loading-time') and the public API (setViewLoadingTime). AddViewLoadingTime is a leftover from the old name.

[MaelNamNam]

Woooooops, sorry, I missed this one. Thanks & renamed in 4bb65b3.

[MaelNamNam]

Actually, I went too fast on this and I'm reverting it (cf 00a28dc): the telemetry event is called add-view-loading-time because it was define as such in the Mobile SDKs. As this setViewLoadingTime is an experimental API, I feel it's best to re-use already existing event names rather than add a new one just for Browser that might eventually get removed.

[bcaudan]

Nice work 👍

[mormubis]

setLoadingTime is only ever called from the public API — auto-detection writes directly to commonViewMetrics.loadingTime via its own callback and never touches this function. so by the time hasManualLoadingTime is true, the only way to get here again is the user explicitly calling setViewLoadingTime() a second time. that's already an unambiguous intent to update the value, which makes the overwrite param redundant.

the guard if (hasManualLoadingTime && !overwrite) only makes sense if some internal code path could also call setLoadingTime — but nothing does. the parameter exists because the no-op behavior was pushed down into trackCommonViewMetrics instead of being handled higher up where the intent is clear.

a cleaner design would be to remove overwrite entirely and just always apply the new value — or if first-call-wins is genuinely desired, enforce it at the rumPublicApi level where the user's options are already resolved, rather than leaking it down through the whole call chain as a boolean flag.