That report API is interesting, I’ve seen it used for csp errors but not for browser errors, I wonder if error monitoring services support it

https://report-uri.com/ does.

Thank you for contributing data to support the efforts for a style-free scroll.

> apparently some change there was causing lower-end browsers to crash.

Was the change CSS specific or was it domain specific?

It's definitely possible to cause browser failures with pure CSS if you figure out how to stress the renderer. For example, if your set of transforms and animations require the browser to allocate lots of temporary surfaces, it can run out of RAM (or VRAM) and then the tab might get killed to free up resources. This is more likely to happen on mobile, but it can happen on desktop too.

Crashing a browser process with CSS is certainly up there in WTF moments. I've had to debug one such situation in the past: https://news.ycombinator.com/item?id=25265708

The call chain from the renderer can be surprisingly deep.

Oh nice, a great way to get some feedback on whether my 1-click exploits are working!

I always monitor for crashes and try and handle a crash from the code itself.

You can't handle browser crashes.

> From this I took away an important lesson: even when your app is not pushing the boundaries of browsers, monitoring for crashes is probably worth it.

What is your favorite tool for this?

I feel like years ago it was New Relic, Raygun, Sentry, etc... but it feels like we never hear about these tools or companies any more on HN. Is this not a sexy topic any more?

I got to know about Sentry because they have a special offer for students, through the GitHub Student Developer Pack[0]. I searched for Sentry right now, through the search, and I am surprised how common it was to talk about these tools.

If it wasn't for the GitHub pack, I would have never known about something like this. Maybe you are right, and it isn't a unique enough topic now :(

[0] https://education.github.com/pack

I know Sentry and hotjar from noscript panel.

I disable javascript by default, some sites become non-functional, then I enable 1st party js, and something see these 3rd party js and got curious on it when I see it being used from multiple sites.

You can also quickly see which tech are used by the site you're browsing with the wappalyzer addon

Observability has never been sexy. It's a lot of grunt work and boilerplate.

That being said, New Relic has served us fairly well. Especially if you put in the grunt work for distributed tracing between the client and your servers.

At least for me when building things the first thing I install after setting up a project is Sentry.

They have a generous free tier and are open source so that’s a plus too

https://sentry.io/pricing/ ...if you're gonna go looking.

For browser side,

Report-uri is the tool. Warning you are going to get a lot of reports because your stuff is broken a lot. You just don't see it.

I always give that advice when adding these sorts of tools into the mix. "you are about to get a lot of work you did not know you had".

Basically more than likely your code/infrastructure is doing something wrong. These linter style tools many times will find whole classes of bugs smeared across your whole code base.

One poor soul I worked with once decided 'hey no errors are being caught anywhere'. He then proceeded to add logging to everything where something would fail. "dude you are about to get 1000 bugs back from the QA group and they will blame you even though it is the 3 guys who left 2 years ago that did it". He nearly lost his job because he did not prime them for it. QA was rightly mad because they went from 'everything seems to work' to error alerts everywhere and no testing can be completed.

Tools like Sentry are not just collection, but more importantly do aggregation.

I've built shopping cart forms before, which get every single browser imaginable. Keenly aware of the number of oddball edge case errors that happen.

I don't see in Sentry where you can set up "Report-To", "NEL" headers.

I can imagine an AdNauseam-like userscript that spams POST requests of fake crashes for every visited webpage (:

Assuming you can disable this crash reporting, what's the point? These endpoints aren't being called by Javascript bugs or error messages, but bg actual browser crashes.

If these settings can't be turned off then I'd definitely assume the feature flag reporting and the CSP reporting are used for tracking on some platforms, on which AdNauseam would then have merit.

EDIT: CSP reports are blocked by uBlock Origin by default but it appears there are no browser settings to control this behaviour. I expected Chrome to screw users over like this, but I'm disappointed in Firefox that there's no "advanced privacy options" screen where I can control this behaviour.

how is that different than any other POST endpoint?

I assume it produces most headaches to the team behind the webapp, since crashes are probably not that common and it's relatively expensive to diagnose one. While clicking on ads in background does steal some revenue, developer time seems more expensive than a couple of ads.

Don't be evil (:

It's a poor man's version, and it doesn't catch all errors, but it works in all browsers

    export function wrapInErrorHandler<Func extends (...args: any[]) => any>(func: Func): (...args: InferArguments<Func>) => InferReturn<Func> {
        return function (...args: InferArguments<Func>) {
            try {
                return func.apply(null, args);
            } catch (err: any) {
                if (err instanceof LoggedError) {
                    throw err;
                }
                post({ your- error - object});
                throw new LoggedError(err);
            }
        };
    }

I wrap (some) event handlers and callbacks in this function (wrapInErrorHandler(f) returns a function of the same type as f). If they throw an error, the data is posted to a simple json collecting endpoint, which triggers an email action (not too frequently). LoggedError is wrapper for err, to avoid logging the same error multiple times.

I think this is about browser crashes, not browsers throwing errors in user scripts.

Right. I should have put it under the Sentry discussion.