4 ms·

I gotta say, the ending was pretty disappointing. I was so hyped to learn why Grammarly crashes when Chrome loads a particular gif. What about the gif was diffe

I gotta say, the ending was pretty disappointing. I was so hyped to learn why Grammarly crashes when Chrome loads a particular gif. What about the gif was different? What part of Grammarly made that happen? I hate to say it but this is modern web dev in a nutshell. Remove stuff until you find where the bug is, tweak it randomly until it's fixed, done. No root cause analysis or anything deep. This is a great post anyway. Well written and still quite intriguing right up until the end. And it seems lots of comments on here seem to also know about this problem, so I think I can still satisfy my curiosity.

eyelidlessness 3y ago
> I hate to say it but this is modern web dev in a nutshell. Remove stuff until you find where the bug is, tweak it randomly until it's fixed, done. I’ve alternated between frontend, “full stack”, and backend roles for over 20 years. It’s my experience that what you’re describing is “dev in a nutshell”—neither “modern” nor “web” in the sense you seem to mean. And in any case it’s highly situational and variable depending on the dev and their team.
randshift 3y ago
They never root caused the bug! They know a symptom (Grammarly and this gif cause things to crash) but still no root cause. I was pretty disappointed at the end.
- sanderjd 3y ago
  It was like reading a Sherlock Holmes story where they just decide to put Moriarty in jail and that fixes everything, but Holmes doesn't actually figure out what was going on.
karim79 3y ago
> When I removed loader-spinner.gif, the placeholder we display while the menu options load, the page stopped crashing. Eureka! It’s the gif! We swapped in a different gif and the page did not crash. I would love to have the original and the un-crashy gifs mentioned. It's super easy, generally, and even without an extensive knowledge of image formats to get a grasp of what might be going on and then going down some really exciting rabbit-hole of image encoding/decoding issues. Just take the two gifs and run them (one by one) through ImageMagick or GraphicsMagick to print out the details of what's in them, and look for differences. Assuming ImageMagick is installed (or GraphicsMagick) installed, something like: #imagemagick $ diff <(identify -verbose loader-spinner-CRASHY.gif) <(identify -verbose loader-spinner.gif) #graphicsmagick $ diff <(gm identify -verbose loader-spinner-CRASHY.gif) <(gm identify -verbose loader-spinner.gif) ...and rabbit-hole away EDIT: formatting
alpb 3y ago
Agreed. > Unfortunately, with access to neither the Chrome source code nor the Grammarly source code, we can only guess. Chromium source code is open. They could also certainly try different versions of Chrome to bisect when the issue has started to happen. Isn't there a chance perhaps this crash might actually be disguising a buffer overflow vulnerability as well? Typically user inputs aren't supposed to crash browser/renderer processes.
- alexeldeib 3y ago
  They allegedly tried chromium without luck.
deleted 3y ago
[deleted]
Sxubas 3y ago
> I hate to say it but this is modern web dev in a nutshell I'd rather call it scientific method: observe, form a hypothesis, experiment and analyze results. I agree it is anticlimatic to not know the root cause, but the rant about the current state of web dev seems out of place. We dont even know if it was because a web technology. Some folks were mentioning issues from printers being caused by graphic cards drivers. One would love to blame printers, but it turned out they were not the culprit.
robocat 3y ago
> No root cause analysis or anything deep. Spending time to create a test case and sending it to the browser bug team gets the bug fixed? Riiiiiiiiight. Actually I did that for a while and the Chromium team would occasionally fix some fairly subtle issues: assuming I could make a demo of the problem and took the time to write up a good bug report. Maybe they just liked me! The Chromium team also wrote fantastic public followup to bug reports (whether fixed or not). Certainly I never had any luck getting even extremely serious browser bugs fixed by anyone else (Apple, Mozilla, Microsoft) regardless of how much time I wasted trying to give good informative bug reports. And you never found out anything further - talking to walls is more productive. It feels good trying to help the world be a better place, but it wasn't worth it. Don't waste your time fighting windmills. Find a workaround, document it with a comment, forget about it. Do something that makes your business successful instead.
flippinfloppin 3y ago
And when you consider they end with the pitch "If you also enjoy collaborating with relentlessly curious people, we are hiring!" What is effectively guessing which is what this article entails - without knowing the actual cause - hardly qualifies one as "relentlessly curious". Personally I deeply dislike the random walk towards insanity that modern dev takes with the constant churn and layers of fixes upon fixes - react state is no good! use redux! use this! use that! And before you know it knowing what is actually going on becomes nearly impossible!

eyelidlessness 3y ago

> I hate to say it but this is modern web dev in a nutshell. Remove stuff until you find where the bug is, tweak it randomly until it's fixed, done. I’ve alternated between frontend, “full stack”, and backend roles for over 20 years. It’s my experience that what you’re describing is “dev in a nutshell”—neither “modern” nor “web” in the sense you seem to mean. And in any case it’s highly situational and variable depending on the dev and their team.

randshift 3y ago

They never root caused the bug! They know a symptom (Grammarly and this gif cause things to crash) but still no root cause. I was pretty disappointed at the end.

sanderjd 3y ago
It was like reading a Sherlock Holmes story where they just decide to put Moriarty in jail and that fixes everything, but Holmes doesn't actually figure out what was going on.

karim79 3y ago

> When I removed loader-spinner.gif, the placeholder we display while the menu options load, the page stopped crashing. Eureka! It’s the gif! We swapped in a different gif and the page did not crash. I would love to have the original and the un-crashy gifs mentioned. It's super easy, generally, and even without an extensive knowledge of image formats to get a grasp of what might be going on and then going down some really exciting rabbit-hole of image encoding/decoding issues. Just take the two gifs and run them (one by one) through ImageMagick or GraphicsMagick to print out the details of what's in them, and look for differences. Assuming ImageMagick is installed (or GraphicsMagick) installed, something like: #imagemagick $ diff <(identify -verbose loader-spinner-CRASHY.gif) <(identify -verbose loader-spinner.gif) #graphicsmagick $ diff <(gm identify -verbose loader-spinner-CRASHY.gif) <(gm identify -verbose loader-spinner.gif) ...and rabbit-hole away EDIT: formatting

alpb 3y ago

Agreed. > Unfortunately, with access to neither the Chrome source code nor the Grammarly source code, we can only guess. Chromium source code is open. They could also certainly try different versions of Chrome to bisect when the issue has started to happen. Isn't there a chance perhaps this crash might actually be disguising a buffer overflow vulnerability as well? Typically user inputs aren't supposed to crash browser/renderer processes.

alexeldeib 3y ago
They allegedly tried chromium without luck.

deleted 3y ago

[deleted]

Sxubas 3y ago

> I hate to say it but this is modern web dev in a nutshell I'd rather call it scientific method: observe, form a hypothesis, experiment and analyze results. I agree it is anticlimatic to not know the root cause, but the rant about the current state of web dev seems out of place. We dont even know if it was because a web technology. Some folks were mentioning issues from printers being caused by graphic cards drivers. One would love to blame printers, but it turned out they were not the culprit.

robocat 3y ago

> No root cause analysis or anything deep. Spending time to create a test case and sending it to the browser bug team gets the bug fixed? Riiiiiiiiight. Actually I did that for a while and the Chromium team would occasionally fix some fairly subtle issues: assuming I could make a demo of the problem and took the time to write up a good bug report. Maybe they just liked me! The Chromium team also wrote fantastic public followup to bug reports (whether fixed or not). Certainly I never had any luck getting even extremely serious browser bugs fixed by anyone else (Apple, Mozilla, Microsoft) regardless of how much time I wasted trying to give good informative bug reports. And you never found out anything further - talking to walls is more productive. It feels good trying to help the world be a better place, but it wasn't worth it. Don't waste your time fighting windmills. Find a workaround, document it with a comment, forget about it. Do something that makes your business successful instead.

flippinfloppin 3y ago

And when you consider they end with the pitch "If you also enjoy collaborating with relentlessly curious people, we are hiring!" What is effectively guessing which is what this article entails - without knowing the actual cause - hardly qualifies one as "relentlessly curious". Personally I deeply dislike the random walk towards insanity that modern dev takes with the constant churn and layers of fixes upon fixes - react state is no good! use redux! use this! use that! And before you know it knowing what is actually going on becomes nearly impossible!