When the crash report says nothing was thrown
Some errors arrive with no message and no stack — a promise that failed with nothing to show for it. You can still catch them. A short trail of what the screen just did turns "something broke" into the step that broke.
A till that breaks quietly is worse than one that breaks loudly. So this system reports its own front-end errors: when something throws on a screen, a line lands in an error log the owner can read, worst first, with the page it happened on. Most of the time that line is enough — a message and a stack point straight at the cause.
Some errors carry neither. A browser can reject a promise with nothing at all: no message, no type, no stack. The honest report reads "a promise was rejected with no reason" — true, and on its own useless. It names the screen and stops there.
The trail is the stack you never got
When there is no stack, the next best thing is what the page was doing just before. So the page keeps a short rolling note of its own recent steps — the screen it opened, the calls it made to the server — and when one of these reasonless errors fires, that trail goes in where the stack would have been. The next time it happens, the report shows the sequence that led up to it instead of a blank.
Quiet, capped, and it cannot make things worse
A crash reporter that crashes takes the only signal with it, so every part of this is wrapped so it can fail silently. The trail is capped — a till left open all day cannot grow it without bound — and it is stored so it can never split one recurring fault into a hundred separate log lines that bury each other.
The wider point: an error you cannot yet explain is still worth catching honestly. Say exactly what turned up, keep the context that was available, and wait for the next occurrence to name the cause — rather than guessing at a fix that might hide a real failure.