Read the Element Trail and Repro Summary

Read a FeedBlox element trail by starting at the bottom numbered list (closest to submit), matching #xxxx author ids to your markup, and using ·xxxx fingerprint suffixes to tell similar controls apart. Repro Summary above is a compressed cheat sheet; trust precise timings in the full trail.

When a visitor submits feedback, the inbox can include an Element Trail: recent clicks and focus changes from their session. It is not session replay. The widget stores structural fingerprints only - tag, role, timing, and hashed paths - so you get repro hints without button labels, field values, or page copy.

What the Widget Captures (and What It Skips)

The embed keeps a bounded ring buffer of the last 16 interactions before submit. Each event records whether the visitor clicked or focused an element, when it happened relative to the page session, and a fingerprint of where that element sits in the DOM tree.

For privacy, FeedBlox does not store inner text, placeholder strings, typed values, or raw attribute values. You will see <button role=button>, not "Checkout now." The trail tells you where they acted. Console logs and network errors tell you what broke.

• Included: HTML tag, inferred or explicit ARIA role, relative timestamps, structural path hash, optional stable author id

• Excluded: DOM text, form field values, passwords, framework-generated React ids, full CSS selectors with labels

• Buffer limit: 16 events - older steps roll off if the visitor clicks around a lot before sending

Repro Summary vs. the Full Trail

The inbox shows two related views. Repro Summary is a compressed cheat sheet: consecutive identical steps on the same element type are merged (for example click <button role=button> (×2)), and only the last dozen grouped steps are shown.

Timings in the summary use coarse buckets - ≥60s means the step happened at least a minute after the widget started tracking on that page load. The numbered list below is the timeline you should read when reproducing. It uses precise offsets such as +48s, +9m 1s, or +44m 18s from the start of that session. When the two blocks disagree on timing detail, trust the full trail.

How to Read One Trail Line

Example: +9m 1s click <input role=input:text> #B2A4 ·xSRr

• +9m 1s - about nine minutes and one second after tracking started on this page load

• click - a mouse click (focus-only rows mean tab or programmatic focus without a click)

• <input role=input:text> - a text input (password, checkbox, and other input types show different role suffixes)

• #B2A4 - short suffix of a stable id your markup exposed (see below)

• ·xSRr - last four characters of the structural path fingerprint; the same suffix on another row means the same element in the tree

• ×2 - the same action on the same fingerprint grouped twice

• Hover a row in the dashboard for full hash values (path:, box:, content:, scope:). Identical ·xxxx suffixes across rows mean the visitor interacted with the same control repeatedly.

What #xxxx and ·xxxx Mean

#xxxx appears when the element has a stable author id the widget is allowed to read: data-feedstack-id, data-testid, or a normal id that is not a framework-generated value (React and similar auto-ids are ignored because they change every render).

If you tag important controls in your app, the trail becomes much easier to read. A report that shows #email or #checkout beats guessing which of five identical <button role=button> rows mattered.

·xxxx is always present: a hashed fingerprint of the element path (tag, role, and nth-of-type position up the tree). Use it to tell two links or two images apart when no author id exists.

Walk Through a Realistic Example

Suppose the full trail ends with these rows (newest at the bottom):

• +48s focus <body> - page or window received focus

• +8m 49s click <img> ·wDwJ - one image clicked after a long idle gap

• +9m 1s focus <input role=input:text> #fld1 ·xSRr then click on the same suffix - typing or editing a labeled field

• +9m 8s click <a role=link> ·prcs and +9m 9s click <a role=link> ·A_SH - two different links (different · suffixes)

• +44m 18s click <button role=button> ·QaBj (×2) - same button clicked twice, often a submit or primary CTA right before feedback

What That Trail Implies

Story in plain language: the visitor returned to the tab, clicked a hero image, worked in a known text field, followed two links, waited a long time, then double-clicked a primary button and sent feedback. Large gaps often mean another tab, idle time, or a slow workflow - not continuous clicking for thirty minutes.

The Repro Summary above this list might show mostly ≥60s lines because many steps happened after the first minute. That is normal. Use the summary for a quick shape check; use the numbered list to reproduce.

How to Reproduce From a Trail

1. Open the report detail and scroll to the bottom of the Element Trail (closest to submit).

2. Match any #xxxx tokens to elements in your HTML or component tests.

3. For rows without author ids, use ·xxxx to distinguish controls of the same tag (two links, two images, two buttons).

4. Ignore bare focus <body> rows unless you are debugging tab or window focus.

5. Read console logs and failed network calls on the same report - the trail shows where they were; debug data shows what failed.

6. Replay on the same URL and viewport size when possible; check metadata your app attached with FeedBlox.setMetadata (plan, version, user id).

Common Misreads

• Treating Repro Summary timings as exact - use the full trail for offsets

• Assuming two <img> clicks are the same image without comparing · suffixes

• Expecting button label text - only structure is stored

• Missing earlier steps because only 16 events are kept

• Skipping reports where the trail is empty - the embed may be missing on that route or the visitor submitted immediately

Make Trails Easier for Your Team

Add data-feedstack-id to high-risk controls: checkout submit, login, billing fields, and modal confirm buttons. Keep ids stable across deploys.

In triage, paste the last three trail lines plus the top console error into your issue tracker. Link back to the FeedBlox report id so QA can reopen the bundle.

Pair element trails with triage statuses (open, in review, done) so repeat reports on the same · suffix stand out as regressions.

Related Guides

Product: Bug report widget for websites.

Also read: Bug reporting use case.

FAQ

What is an element trail in a FeedBlox bug report?

A bounded list of recent clicks and focus changes before submit. Each step records tag, role, timing, and a structural fingerprint. No button labels, field values, or page copy are stored.

What is the difference between Repro Summary and the full trail?

Repro Summary merges consecutive identical steps and uses coarse timing buckets. The numbered trail below uses precise offsets like +48s or +9m 1s. Trust the full trail when reproducing.

What do #xxxx and ·xxxx mean in a trail line?

#xxxx is a short suffix of a stable author id (data-feedstack-id, data-testid, or normal id). ·xxxx is the last four characters of a structural path fingerprint to distinguish similar elements.

How many interactions does FeedBlox store in the element trail?

Up to 16 interactions before submit. Older steps roll off if the visitor clicks around a lot before sending.

How do I reproduce a bug from an element trail?

Start at the bottom of the numbered trail (closest to submit). Match #xxxx tokens to your markup. Use ·xxxx suffixes to tell two buttons or links apart. Read console and network on the same report for what failed.