Add browser page view event

[martinkuba]

Changes

This adds a new event for capturing the page view event from browser/web applications.

Related to https://github.com/open-telemetry/opentelemetry-js-contrib/issues/2372

Merge requirement checklist

• [x] CONTRIBUTING.md guidelines followed.
• [ ] Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• [ ] schema-next.yaml updated with changes to existing conventions.

[github-actions[bot]]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions[bot]]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[github-actions[bot]]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions[bot]]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[github-actions[bot]]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions[bot]]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions[bot]]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[github-actions[bot]]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[github-actions[bot]]

Closed as inactive. Feel free to reopen if this PR is still being worked on.

[danielgblanco]

Thinking about the notion of combining hard and soft navigation on browser.page_view. As specified here, the intention is not to measure any timings, and instead use browser.navigation_timing, and I agree that's necessary if we want to represent purely counts of both types of navigations, otherwise there would be too many condition measurements depending on one or the other.

However, this brings up a follow up question. Do we expect to follow the same pattern for soft navigations? i.e. having a separate event to report timings for soft navigations (i.e. the time from interaction to render/stabilising). I think that'd make sense to me.

[martinkuba]

I have made a few changes based on feedback:

• switched from using body fields to attributes
• all new attributes are in the browser.* namespace
• for the URL field, I am now using the existing url.full attribute
• renamed page_view.title to page.title , since that seems to be really a property of the page
• updated the type enum to use human readable values (page_load and soft_navigation - I felt these make most sense, but open to other ideas)

There are a couple of things that still need to be resolved

• per @david-luna’s comment, the page title attribute could contain PII values, which complicates the instrumentation. It is also not clear if it provides much value. I am open to removing it (at least for now). lmkwyt
• I think the change_state attribute needs clarification. Is it intended to capture the mechanism of how the URL was changed or whether the new URL was added to the history stack? There are other ways of changing the URL than using the history API, so if it complicates things, I am also open to removing this for now.