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

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.

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?

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

@joaquin-diaz could you merge in main/rebase this branch followed by a regeneration of the docs?

This PR has been labeled as stale due to lack of activity. It will be automatically closed if there is no further activity over the next 14 days.

@joaquin-diaz @martinkuba the current span based instrumentation for click allows for linking the click to any xhr/fetch calls made from the click handler, which is helpful to know. The approach used there is to propagate trace context and use a common trace across click and all the xhr/fetch calls. This approach poses a problem that the same API calls are modeled different with and without RUM instrumentation, as these API calls get their own traceId when RUM is not involved. I prefer modeling them using independent traces. However, I do find it helpful to have the xhr/fetch calls linked to the click event.

a) is there a span.links equivalent for events where we can add related spans, events, etc?
b) is it possible to identify the xhr/fetch related to a click event without using trace context?

a) is there a span.links equivalent for events where we can add related spans, events, etc?

An event can only be linked to 1 span but a span can have many events.

b) is it possible to identify the xhr/fetch related to a click event without using trace context?

My suggestion is that we should have an app interaction span which acts as the root span. This root span could then contain the navigation, http etc child spans.

@joaquin-diaz

My suggestion is that we should have an app interaction span which acts as the root span. This root span could then contain the navigation, http etc child spans.

This is what the current user-interaction instrumentation does today; however, it has the issue I described above. The trace context ends up propagating to the backend instrumentation, whose behavior then varies depending on whether the user interaction instrumentation is set up or not, and this is not ideal.

Are we not solving that by having the attributes on the root span for the span initiator hence removing the need for inference based on the parent span?

This PR has been labeled as stale due to lack of activity. It will be automatically closed if there is no further activity over the next 7 days.

Thanks, this PR is very useful context for my proposal in open-telemetry/opentelemetry-specification#4975.

I agree the right direction is not to introduce a generic new “user action” family, but to build from existing app events where possible.

For native mobile, my intent is:

• reuse existing click/tap-related app events as the basis where they already fit
• only propose additions for clear gaps such as scroll / gesture, lifecycle composition, and session correlation
• keep everything log-based and privacy-safe

So I’m treating #2992 as prior art rather than trying to redefine click from scratch.