- Start Date: 2022-11-02
- RFC Type: feature
- RFC PR: #33
- RFC Status: approved
- RFC Driver: Dhiogo Ramos Brustolin
Allow SDKs to send a textual representation of the application's UI view hierarchy.
Being able to see what the user was looking at is a good way to find problems in an application. This RFC proposes a way to send information from the UI state of an application, known as "view hierarchy". Compared to screenshots the view hierarchy provides complementary information about the UI, e.g. relationships between UI widgets or additional attributes not visible on the screen.
Example View Hierarchies from PoC implementations:
Capture the view hierarchy in our front-end SDKs and convert it to a common JSON representation. Add it as an attachment to the envelope. The filename is view-hierarchy.json
, the attachment_type
is set to "event.view_hierarchy"
and the content_type
is set to the "application/json"
mime-type.
The attachment payload is a JSON structure containing the view hierarchy, here's an example:
{
"rendering_system": "compose", // or android_view_system, apple_uikit, apple_swiftui, unity, flutter, ...
"windows": [
{
"type": "com.example.ui.FancyButton",
"identifier": "R.id.button_logout",
"children": [], // nested elements
"width": 100.0,
"height": 100.0,
"depth": 100.0, // if applies
"x": 0.0,
"y": 0.0,
"z": 2.0, // if applies.
"visible": true|false,
"visibility": "visible|invisible|gone", // Android specific visibility property
"alpha": 1, // a float number from 0 to 1, where 0 means transparent, and 1 is opaque.
"{extra_properties}": "{property value}" // additional platform-specific attributes
}
]
}
Some remarks on the example:
windows
: contains all visible windows, on mobile it's typically just one or two (e.g. if a dialog is open)type
: The fully qualified widget class name, this name may be obfuscated on certain platforms (e.g. Android release builds with proguard enabled)children
nests all child UI widgets, which then builds up the whole UI tree
A typical Android/iOS view hierarchy for a single window consists of around 100-200 objects. Taking the attributes from the example above this generates a raw JSON file with a size of around 50KB. More complex view hierarchies, for example a Unity game, may hold 1000-2000 objects, producing a JSON file of around 500KB.
As the view hierarchy may contain obfuscated attribute values (see type
attribute in the example above) we need to process the attachment server-side, similar to what we already do for minidumps, or profiles.
- Use a new envelope type instead of attachments: Whilst doable it's considerably more work without adding any benefits. Using attachments has several advantages
- Attachments are billable by default
- We can immediately start sending and using this data, no need for large Relay updates
- Less new code in the SDKs when compared to adding a new envelope item, so less hassle to maintain/test
- We don't have to touch outcomes/rate limiting/processing code at all
- We always can eventually migrate to a new envelope item type if we feel the need to, that option is still left open.
- The view hierarchy could be part of the Event, but because of the size limit, it is not recommended
- By utilizing attachments, attachment scrubbing is relevant for any PII attributes in the view hierarchy
- We've decided to not add the content of textfields, editables, or labels because of PII.
- We may evaluate an option to allow PII.
Instead of sending it as an attachment, the initial proposal was to create a new Envelope item. We opted against this because doing so would introduce a lot of new challenges, and using attachments requires minimal changes for Sentry infrastructure.