Debug tab
Blocking and crashing a thread on purpose.
Tools that break the app on purpose, so the numbers on the other tabs can be trusted. No toolbar: there is no stream to record and nothing to clear.
Block and crash a thread
Every Performance section reports something that happened; these go out and cause it, which is why they sit here rather than there.
| Field | Options |
|---|---|
| Thread | JavaScript (works everywhere) or Main (UI) (needs a dev build). |
| For | 100ms, 250ms, 500ms, 1s, 3s, or a custom value in ms. |
| Block | Blocks the chosen thread for that long. |
| Crash | Crashes the chosen thread. Takes two taps: the first arms it, the second does it. |
Blocking the JS thread shows up as a long task and drops the JS frame rate. Blocking the main thread freezes the screen while every JS number stays healthy. That gap is the blind spot the frame-rate card warns about, and this is how you see it for yourself.
These are not gated on __DEV__, and not on .init() either
The crash paths do not go through any store, so .init() is not what keeps them out of a release:
they work as soon as the panel is on screen. What gates them is whether you rendered
<DevtoolsOverlay /> at all.
Both crash paths are captured by the Crashes tab when crash reporting is on. A JS crash is reported before you let go of the button; a main-thread crash ends the process and is read back off disk at the next launch.