feat: Add Browser click event

[joaquin-diaz]

Changes

Added a new event for browsers named user_action.click. This event captures the "click" action in browsers

Prototype instrumentation:
open-telemetry/opentelemetry-browser#35

Important

Pull requests acceptance are subject to the triage process as described in Issue and PR Triage Management.
PRs that do not follow the guidance above, may be automatically rejected and closed.

Merge requirement checklist

• 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]
• Links to the prototypes or existing instrumentations (when adding or changing conventions)

[thompson-tomo]

This seems too generic and instead I feel we should aim for tailored click, key etc events. Ideally at a mimum following https://www.w3schools.com/jsref/obj_events.asp but also potentially splitting a couple ie mouse & click. That way we can easily tailor attributes based on the trigger.

Also for click events Why not extend https://opentelemetry.io/docs/specs/semconv/app/app/#event-appwidgetclick but keep the same name?

[thompson-tomo]

Have we considered using https://opentelemetry.io/docs/specs/semconv/registry/attributes/app/#app-screen-coordinate-x etc

[thompson-tomo]

Could we use https://opentelemetry.io/docs/specs/semconv/registry/attributes/app/#app-widget-name?

[joaquin-diaz]

This seems too generic and instead I feel we should aim for tailored click, key etc events. Ideally at a mimum following https://www.w3schools.com/jsref/obj_events.asp but also potentially splitting a couple ie mouse & click. That way we can easily tailor attributes based on the trigger.

Yeah.. I think having multiple events makes sense. It would make it easier to know which attributes to expect vs a bunch of mixed possible attributes depending on type

Also for click events Why not extend https://opentelemetry.io/docs/specs/semconv/app/app/#event-appwidgetclick but keep the same name?

I wasn't part of the original discussion but it seems they preferred to use browser terminology instead of translating e.g. event.pageX -> app.screen.coordinate.x.

Some of these app attributes as easy to translate from browser APIs but some are not as straight forward. app.widget.id and app.widget.name are hard to understand in a browsers perspective. Based on their definitions:

• app.widget.id: An identifier that uniquely differentiates this widget from other widgets in the same application. Examples: f9bc787d-ff05-48ad-90e1-fca1d46130b3; submit_order_1829
• app.widget.name: The name of an application widget. Examples submit; attack; Clear Cart

A widget is an application component, typically an on-screen visual GUI element.

Component is a loaded term in web, it can be confused for example with a React component that can be composed of multiple dom elements.

app.widget.id is marked as required in app.widget.click but there's no equivalent in the browser that is always present, you may have an id, but not always. You also have xpath but that can change if dom elements are added or removed. app.widget.name could be the element tag name

IMO I would like to have shared events between client SDKs (web and mobile) but they work for both cases, app.widget.click seems to be too tailored for mobile apps and it feels like a stretch to apply it here. I'll bring this up to the browser sig on Thursday and get their input

[thompson-tomo]

I wasn't part of the original discussion but it seems they preferred to use browser terminology instead of translating e.g. event.pageX -> app.screen.coordinate.x.

So I have seen at https://www.w3schools.com/jsref/obj_mouseevent.asp and page/app are in effect different measurements so perhaps we go with app.page.coordinate.x.

Some of these app attributes as easy to translate from browser APIs but some are not as straight forward. app.widget.id and app.widget.name are hard to understand in a browsers perspective.

I agree but I think we can improve the description to resolve those issues and use the attribute notes to define how to source it. For widget id = html element id and fall back to xpath when not defined.

[thompson-tomo]

Could someone from the browser sig or a maintainer add the triage accepted label so that the hw.mouse.button can be added to hardware namespace and not have this PR auto closed?

[thompson-tomo]

These should be in the registry file in the hardware folder. But only make the change once the triage:accepted label has been added.