My extension problem story is a bit different. We distribute an extension that makes it easy to switch between proxy servers for geolocation testing.
I ran my worst client demo ever a few months ago. It was like our product simply didn’t work. A lot of pulled hair and frustrating debugging later we discovered that a recent update to the 1Password extension broke ours. They were subscribing to an auth event, but not returning, this timed out so our subscriber was never called. So our extension would tell the browser to change proxy servers, then sit ready to provide credentials, but the request would never come. 1Password’s support team was better than grammerly’s, but it’s hard to convince an unknown PM to prioritize something, especially if you’re speaking to them via a support team.
We’ve since discovered that there’s some Russian extension you need for government websites that has the same issue.
Yeah, similar boat here. 1pass still breaks opening the chrome sidepanel UI from content scripts in other extensions. They screw up the trusted flag that indicates the event is coming from a user interaction.
Ultimately, as someone in the extension space for more than a decade now, Google is really at fault... Manifest v3 is just crappier than it should be in a LOT of ways (entirely outside the politics of the ad blocker changes - which is a whole different can o worms).
Overall, I think the quality of the chromium codebase feels a lot lower than it used to.
this really pisses me off because about 5-6 months ago I was doing an interview for a job that of course I did not get because old, and I talked about an instagram / branding startup thing I was the CTO of and main programmer in 2014 and how I made this build system to make sure that css classes and JavaScript objects were properly namespaced and how we made sure there was no potential collisions and the way we made sure exactly what scripts needed to be loaded on the page based on which of our widgets were on the 3rd party client site etc. etc. and at the end of it the guy interviewing me said dismissively there are tools that do that and everybody does that nowadays which I sort of had to agree they probably did because who knows, I'm not really doing that thing any more, and now it turns out they don't even.
I wonder what would happen if you cut your salary requirements in half. Would they still reject you on your age or what? And if so, would they reject you if you slashed it in half again? And keep slashing until they hired you. Just as an experiment
Hell, namespacing makes life easier even just for yourself. I wrote some browser automation in a previous role that was never going to be user-facing—it wasn't an extension—and it still proved useful to namespace things, both to clearly mark what we were inserting vs what was already there, and to avoid possible collisions.
I don't know if this is what was meant by namespacing but i've seen '--{{ projectname}}-my-variable' before, so something like '--grammarly-rem' in this case.
Its frightening to see how many screenshares and recordings contain that green infestation as default on every website, not just the obvious visual disturbance (am i the only one who thinks the green is ugly and clashes with most websites colors?) that does not seem to bother users but the privacy and obvious attack vectors that come with it. Chrome can enable extensions only when needed why does no one do this? Why is this not the default on every browser?
I count myself fairly lucky to have colleague that care about these sorts of things. We have had meeting halted because it was obvious that some participants had certain extensions installed, AI assistants of various types, and some colleagues aren't comfortable with information potentially being picked up by a third party. So the meeting is halted until the extension is disabled.
I suppose they're concerned so many people are blindly installing Grammarly without a sandbox.
I'm concerned too, but from the angle that writing on the internet is becoming less human, more robot protocol. Even when it's from humans.
As if bots weren't enough of a problem, imagine when social media is just people clicking on buttons: "write a funny response", "write a comment in disagreement", "write 'same'", etc.
Hey. I’m an engineer at Grammarly Extension. First of all, I’m really sorry that our extension broke the UX on dbushell.com and caused the author to spend time and effort figuring this out.
That was never intentional, and we are using various techniques to prevent this from happening. Unfortunately, that wasn’t enough. The article clearly shows that there’s room for improvement.
We temporarily added an exception for dbushell.com as a quick fix. In the meantime, we’re working on a change to ensure proper style isolation; such issues must never be the case.
I've a similiar problem with Google Translate that breaks my web app. Users, using Google Translate, complaining my app is broken, but it was Google changing the state of my app from a higher meta level. Really bad practice..
I am trying to detect Google Translate and print a warning then.
While Google Translate's interference sucks, with current browser tools, I don't think they can really operate any other way.
This is mostly because of cases where they need to translate a sentence like "[Click here] for more information". When translating it to another language, they may have to move the link to the end e.g. "For more information, [click here]". The only way to achieve that is to shuffle DOM elements around, which can cause interference with interactive apps.
There's still a lot the Google Translate team can do to reduce the interference they cause, but I don't think they can fully eliminate it without some new browser APIs.
This is fairly unrealted, but it irks me when one-line fixes like this sit for ages in backlog hell. I want a company where developers go "might as well fix that now, it's faster than writing a ticket for it".
I see people where I work not do this, and it drives me crazy. Our director of engineering will literally add tickets for himself to do things that would take less time to just do. At least I hear "I took a page from your book and messaged the person instead of adding a ticket for myself to message them" often, which is a good sign.
To be clear, I'm answering this purely from a personal standpoint and not talking about any particular employer, and this doesn't relate to this specific issue at all.
Yes, I totally agree. The point of processes is to enable a company to manage huge amounts of potential work. Sometimes, processes can get in the way of just doing the simple thing we all know needs to be done.
Buuuut, I've been on the other side of that, too. Someone asks me to make some change. Sure! That's a reasonable idea and it would improve things. Making the change would take about 20 minutes. However, 437 different systems expect that thing to have its current behavior, and updating them to use the new behavior would be quite the project. In a vacuum, the change is simple and shouldn't take long to implement. Not many things operate in a vacuum, though.
For example, it would take like 5 minutes to do a "find all" in the Nginx source code and fix the misspelling of "referrer" as "referer". It would take a lot longer to update the standards with the correct spelling, and every client and other server to use it, would be slightly more challenging.
> Our director of engineering will literally add tickets for himself to do things that would take less time to just do
I've done this. It irks me too, but sometimes I'm in organizational mode, and sometimes I'm in execution mode. :)
Also, I work in an environment[0] where all work is required to go through the formal tracker documentation flow (and all code changes must be approved by a second party).
So the ticket step is non-optional, and in fact required before work can begin -- we name branches with the ticket ID, so that Pivotal[1] can track the GitHub lifecycle.
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.
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.
> 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.
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.
Readit News
I ran my worst client demo ever a few months ago. It was like our product simply didn’t work. A lot of pulled hair and frustrating debugging later we discovered that a recent update to the 1Password extension broke ours. They were subscribing to an auth event, but not returning, this timed out so our subscriber was never called. So our extension would tell the browser to change proxy servers, then sit ready to provide credentials, but the request would never come. 1Password’s support team was better than grammerly’s, but it’s hard to convince an unknown PM to prioritize something, especially if you’re speaking to them via a support team.
We’ve since discovered that there’s some Russian extension you need for government websites that has the same issue.
Ultimately, as someone in the extension space for more than a decade now, Google is really at fault... Manifest v3 is just crappier than it should be in a LOT of ways (entirely outside the politics of the ad blocker changes - which is a whole different can o worms).
Overall, I think the quality of the chromium codebase feels a lot lower than it used to.
on edit: fixed some grammar
I'm concerned too, but from the angle that writing on the internet is becoming less human, more robot protocol. Even when it's from humans.
As if bots weren't enough of a problem, imagine when social media is just people clicking on buttons: "write a funny response", "write a comment in disagreement", "write 'same'", etc.
Dead Comment
That was never intentional, and we are using various techniques to prevent this from happening. Unfortunately, that wasn’t enough. The article clearly shows that there’s room for improvement.
We temporarily added an exception for dbushell.com as a quick fix. In the meantime, we’re working on a change to ensure proper style isolation; such issues must never be the case.
Thank you!
I am trying to detect Google Translate and print a warning then.
This is mostly because of cases where they need to translate a sentence like "[Click here] for more information". When translating it to another language, they may have to move the link to the end e.g. "For more information, [click here]". The only way to achieve that is to shuffle DOM elements around, which can cause interference with interactive apps.
There's still a lot the Google Translate team can do to reduce the interference they cause, but I don't think they can fully eliminate it without some new browser APIs.
I see people where I work not do this, and it drives me crazy. Our director of engineering will literally add tickets for himself to do things that would take less time to just do. At least I hear "I took a page from your book and messaged the person instead of adding a ticket for myself to message them" often, which is a good sign.
Yes, I totally agree. The point of processes is to enable a company to manage huge amounts of potential work. Sometimes, processes can get in the way of just doing the simple thing we all know needs to be done.
Buuuut, I've been on the other side of that, too. Someone asks me to make some change. Sure! That's a reasonable idea and it would improve things. Making the change would take about 20 minutes. However, 437 different systems expect that thing to have its current behavior, and updating them to use the new behavior would be quite the project. In a vacuum, the change is simple and shouldn't take long to implement. Not many things operate in a vacuum, though.
For example, it would take like 5 minutes to do a "find all" in the Nginx source code and fix the misspelling of "referrer" as "referer". It would take a lot longer to update the standards with the correct spelling, and every client and other server to use it, would be slightly more challenging.
I've done this. It irks me too, but sometimes I'm in organizational mode, and sometimes I'm in execution mode. :)
Also, I work in an environment[0] where all work is required to go through the formal tracker documentation flow (and all code changes must be approved by a second party).
So the ticket step is non-optional, and in fact required before work can begin -- we name branches with the ticket ID, so that Pivotal[1] can track the GitHub lifecycle.
[0] PCI-DSS, SOC 2, etc
[1] RIP :(
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.
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.
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.
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.