←back to thread

Et Tu, Grammarly?

(dbushell.com)
279 points dbushell | 4 comments | | HN request time: 0.592s | source
1. emptysea ◴[] No.43516362[source]
At work we have a lot of sentry errors related to browser extensions doing weird stuff.

Chrome’s Google translate is also notorious for breaking react based sites.

It ends up being a tedious triage process to ignore each new extension issue. We use the client side filtering to reduce our ingest volume. In general we have to have a lot higher thresholds to handle the noise vs our backends.

replies(2): >>43516812 #>>43516871 #
2. jgalt212 ◴[] No.43516812[source]
> At work we have a lot of sentry errors related to browser extensions doing weird stuff.

Are you referring to the "Object captured as exception" error which Sentry refuses to give any guidance on? We just end of filtering these out client-side.

replies(1): >>43517558 #
3. MartijnHols ◴[] No.43516871[source]
It's not just noise though; clients are actually experiencing crashes and other issues because of it. I wrote an in-depth article on the Google Translate extension's interference of React (and other webapps): https://martijnhols.nl/blog/everything-about-google-translat...

It's no wonder frontend has a lot more errors, after all it has to support so many more client variations than a typical backend. It can be very hard to make a big webapp that works well for everyone.

4. emptysea ◴[] No.43517558[source]
Ah yeah I remember that one, but can’t remember the origin.

A lot of times the reason sentry can’t do much is because the browser JS VMs have terrible/non-existent stack traces, especially true with things like unhandled rejected promises.