[RUM-14619] Add AddViewLoadingTime telemetry to browser schema

[MaelNamNam]

What does this PR do?

Adds AddViewLoadingTime to the shared telemetry features schema (common-features-schema.json), enabling both Browser and Mobile SDKs to track usage of the addViewLoadingTime API.

Why?

The Browser SDK is adding a new setViewLoadingTime({ overwrite }) API for manually reporting view loading times (DataDog/browser-sdk#4180). This schema change enables telemetry tracking aligned with the mobile SDK's existing pattern.

The type is placed in the common schema (not browser-only) because both mobile and browser SDKs share the same addViewLoadingTime API surface and telemetry fields.

Changes

• Added AddViewLoadingTime entry to schemas/telemetry/usage/common-features-schema.json with:
  • feature: "addViewLoadingTime" (const, required)
  • overwritten: boolean (optional) — whether this call overwrote a previously set loading time
  • no_view: boolean (optional) — API called with no view tracking (mobile only)
  • no_active_view: boolean (optional) — API called when no view is active (mobile only)
• Removed duplicate AddViewLoadingTime from schemas/telemetry/usage/mobile-features-schema.json (moved to common)
• Regenerated TypeScript types in lib/cjs/generated/telemetry.d.ts and lib/esm/generated/telemetry.d.ts
• Added browser and mobile event samples

Why are all fields except feature optional?

• no_view / no_active_view: The browser SDK always creates a view on init(), so these are mobile-only. The browser omits them entirely rather than sending false.
• overwritten: The browser SDK does not send this field for now. Mobile SDKs already report it. Kept optional so each SDK can adopt it independently.

Impact

• Shared across Browser and Mobile SDKs via common schema
• Additive change — no breaking changes to existing telemetry types
• After merge: Browser SDK schema sync will replace the manually-added AddViewLoadingTime type in telemetryEvent.types.ts

[bcaudan]

The approach looks good to me however:

• ❗ warning: the ci is failing, you should ensure to regenerate the types for every update
• 💬 suggestion: you could add event samples to demonstrate mobile and browser usages‏

[bcaudan]

💭 thought: ‏Looking at your implementation, I think it could be interesting to introduce an overwrite property, to capture the customer intent and know if this API option is used, independently of if a loading time was actually overwritten.

[MaelNamNam]

The approach looks good to me however:

• ❗ warning: the ci is failing, you should ensure to regenerate the types for every update
• 💬 suggestion: you could add event samples to demonstrate mobile and browser usages‏

@bcaudan this is done, thanks

[MaelNamNam]

💭 thought: ‏Looking at your implementation, I think it could be interesting to introduce an overwrite property, to capture the customer intent and know if this API option is used, independently of if a loading time was actually overwritten.

@bcaudan I feel it's a bit overkill to be completely honest. We didn't have this intent captured in the telemetry coming from our mobile SDKs, so I'd rather keep it simple. It's an experimental feature in our Browser SDK anyway. Do you have a strong opinion here? Or was this more of a idea?

[mormubis]

Clean move — the schema diff is minimal and the generated types look exactly right. Adding browser and mobile samples is a nice touch for documenting the difference between the two payloads.

Left a couple of inline questions before approving.

[mormubis]

Quick alignment check: are these tracking call-site options (what the caller explicitly passed) or runtime state (what the environment looked like at call time)? The browser-sdk guidance says addTelemetryUsage should be for static call-site info only and specifically calls out "whether a view was active" and "whether a value was overwritten" as examples of runtime state that shouldn't go there. If overwrite is an explicit option passed to the API, overwritten is fine — but no_view/no_active_view feel more like environmental state. Worth a quick check with the team to make sure we're aligned.

[MaelNamNam]

These are mobile-only fields that track environmental state at call time. Indeed, they don't fit the "call-site info only" principle. That said, they already ship in the mobile SDKs and we're just moving them to the common schema for consolidation, while making them optional so the browser SDK can omit them entirely.

I feel changing the mobile behavior would be out of scope here, but let me know 🙇

[bcaudan]

💭 thought: ‏Looking at your implementation, I think it could be interesting to introduce an overwrite property, to capture the customer intent and know if this API option is used, independently of if a loading time was actually overwritten.

@bcaudan I feel it's a bit overkill to be completely honest.

Yes, it was just a thought, we could do that later if we feel the need.

[bcaudan]

💬 suggestion: ‏I think we could set overwritten as optional as well to not implement it on the browser side for now.

[MaelNamNam]

We already send overwritten on the browser side, it's mapped from the overwrite API option. That said, it currently reflects customer intent rather than actual runtime state (i.e. we send true if the user passed @
overwrite: true, and even if no loading time was previously set). So I agree that the current implementation isn't the best.

I can:

1. Make overwritten optional
2. Change the browser SDK implementation so we trigger the telemetry event with overwritten set to true or false based on the outcome and not the intent
3. Keep it like this as the browser SDK setViewLoadingTime is experimental

Let me know what you would prefer 🙇

[bcaudan]

I'd go with 1 as

• I don't think we are interested by monitoring overwritten for now on the browser side, so it does not worth the extra bytes
• it can be confusing to use overwritten to monitor overwrite

If we later feel that we are interested in either overwritten or overwrite on the browse side, we could easily update the schema and the implementation.

[MaelNamNam]

Done. See commits 1292d02 below and 28e56e6 in the browser SDK PR

[bcaudan]

LGTM

[mormubis]

Previous comments all addressed. LGTM.