You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/platforms/javascript/common/session-replay/troubleshooting.mdx
-27Lines changed: 0 additions & 27 deletions
Original file line number
Diff line number
Diff line change
@@ -77,33 +77,6 @@ We're always working on ways to reduce the bundle size. Additionally, there are
77
77
78
78
</Expandable>
79
79
80
-
<Expandabletitle="How does Rage Click detection work?">
81
-
82
-
The Replay SDK tries to detect cases where a user clicked on something, but nothing happened. This is called a "Dead Click" -- a click that seems to be "dead" and does nothing, from the user's perspective. This can happen if a bug prevents the UI from being correctly updated after a button is clicked.
83
-
84
-
The way that the Replay SDK detects this is by checking if a click on a `<button>` or `<a>` element doesn't lead to either updates to the DOM or a page scroll. If within 7 seconds no updates are detected, the SDK will generate a "Slow Click" in the Replay UI. (We call it a "Slow Click" because it may be possible that something will happen after the 7s, but we chose this as a cutoff time.)
85
-
86
-
Another concept related to this is "Rage Clicks". A "Rage Click" is when a user clicks on an element many times, which indicates frustration that something isn't working.
87
-
88
-
When a Slow Click and a Rage Click come together, we have a very good indicator that something is actually wrong, and the Replay SDK will generate a "Rage Click" for this.
89
-
90
-
Note that there are some limitations to this. On the one hand, there may be _false negatives_ -- we cannot detect all cases; for example, imagine a user clicks a "dead" button, but then clicks a different button afterwards that leads to a DOM update. In this case, since we cannot attribute the DOM update to a specific button, we'll _not_ capture this slow click.
91
-
92
-
On the other hand, there may be _false positives_. For example, if a user clicks a link that leads to a file download, there is no reliable way to detect that a download was initiated, so a Slow Click may be generated even if the button is not actually "dead". For these cases, you can configure the SDK via `slowClickIgnoreSelectors` - see <PlatformLinkto='/session-replay/configuration'>Configuration</PlatformLink> for more details.
93
-
94
-
For example, you could ignore detection of dad and rage clicks for download links in your application like this:
95
-
96
-
```javascript
97
-
Sentry.replayIntegration({
98
-
slowClickIgnoreSelectors: [
99
-
".download",
100
-
// Any link with a label including "download" (case-insensitive)
101
-
'a[label*="download" i]',
102
-
],
103
-
});
104
-
```
105
-
</Expandable>
106
-
107
80
<Expandabletitle='I see the message: "A large number of mutations was detected (N). This can slow down the Replay SDK and impact your customers."'>
108
81
109
82
The Sentry SDK attempts to minimize potential [performance overhead](/product/explore/session-replay/performance-overhead/#how-is-session-replay-optimized) in a few different ways. For example, by keeping track of the number of DOM mutations that are happening then disabling recording when a large number of changes are detected. Many simultaneous mutations can slow down a web page whether Session Replay is installed or not, but when a large number of mutations happen, the Replay client can incur an additional slowdown because it records each change.
Copy file name to clipboardExpand all lines: docs/product/issues/issue-details/replay-issues/index.mdx
+21Lines changed: 21 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -19,6 +19,27 @@ In order to see rage clicks in your issue stream on the **Issues** page, your or
19
19
While you can enable **session replay** with JavaScript SDK version 7.27.0, or higher, you'll need to have version 7.60.1 or higher in order to be able to see **rage click issues**.
20
20
</Note>
21
21
22
+
## Detection Criteria
23
+
24
+
"Slow clicks" (also called "dead clicks") are only detected on `<button>`, `<input>`, and `<a>` elements that don't lead to updates to the DOM or a page scroll within 7 seconds). When the user clicks on one of these elements 3 or more times within that 7 second time frame, it indicates frustration, and the SDK registers a "rage click".
25
+
26
+
### Why am I seeing too many or too few rage clicks?
27
+
There might be fewer rage clicks than you expect if the user stopped waiting for the site to respond before the 7 second threshold and instead chose to to something else. This is why the rage click issues that you *do* see are so valuable, because the user that clicked at least 3 times and continued waiting at least 7 seconds for the site to respond is likely very frustrated.
28
+
29
+
You might also see more rage clicks than you expected from buttons that don't trigger a DOM mutation or page scroll (such as Print and Download buttons). There is no reliable way for the SDK to detect that a download or print has initiated, so a slow click might be generated even if the button is not actually "dead". For these cases, you can configure the SDK via `slowClickIgnoreSelectors` - see [Configuration](/platforms/javascript/session-replay/configuration/) for more details.
30
+
31
+
For example, to ignore detection of dead and rage clicks for download links in your application:
32
+
33
+
```javascript
34
+
Sentry.replayIntegration({
35
+
slowClickIgnoreSelectors: [
36
+
".download",
37
+
// Any link with a label including "download" (case-insensitive)
38
+
'a[label*="download" i]',
39
+
],
40
+
});
41
+
```
42
+
22
43
## Get Rage Click Alerts
23
44
24
45
To set up alerts and get notified when a rage click occurs, follow these steps:
0 commit comments