To be fair this was Excell 25 years ago, may no longer be true.
One of the other bugs (the Quark/ATM one) was also because of the programmers were worried about writing over stuff that hadn't been completely erased, the Quark guys wrote a string with 2 spaces at the end through a box that masked the end of the string, the ATM font renderer saw it couldn't fit the text so it split it in half and tried again so it drew N/2 N/4 N/8 ... strings. It spent all it's time in the 68k's multiply instructions figuring out how wide the strings (and substrings) were, our fancy 24-bit character rendering hardware was an afterthought
there were no GPUs at that time. What we were building in the late 80s/early 90s were the first generation of Mac graphics accelerators, really just glorified blit engines, a class of things that eventually grew into what we now call GPUs as people started to push CPUs into them
Well all they needed to do was erase the screen with white and draw on it, but their app's internal logic meant that they erased it more than once.
I was capturing QuickDraw library calls - the low level graphics primitives, to figure out where the graphics time in apps was going and found out sometimes excel did it 9 times
Of course users didn't see it more than once, but our hardware made all that wasted time run faster
It's more likely that one dev wrote the draw-cell code.
Another dev who's fixing a bug, realizes if they call a certain function either directly or indirectly, their particular bug gets fixed.
Oh, and as a side effect, the cell gets erased (again).
A few more fixes/new features added like this and the code is inadvertently erasing the same cell multiple times.
It takes a certain type of dev to step through in a debugger and Notice the app is doing way too much work and then to untangle the mess of code without causing regressions.
Visual memory is really powerful and maps far more easily onto human brain’s experience of navigating the world. So it’s easier for many people to imagine and organise around a grid.
This is sometimes exposed in front end browser code and I had an actual (non technical) end user email our support team last month asking if it was something they should be concerned about! God knows how they found it, I suspect everyone is now an AI-enabled expert at these things…
Oh I've stumbled upon it myself while coding. You can ctrl/cmd-click into any React type and it will take you to its explicit source definition. I'm not sure if it's still the case but they used to have all of the types organized into a single file. Since I was the go-to TypeScript person at one job I had I made sure to familiarize myself with every type (less than you'd expect)
The point of that scary flag name was the stance that source maps should never be deployed in production.
There are stances that say they should, browse a large SPA with complex working source maps enabled, DevTools open, cache disabled and a long session (relevant because of HMR in dev), and you can see why this matters.
Browsers only fetch and process source maps in a development environment in production, that's why this flag name exists.
That being said, I still have a hobby project with an (in my opinion) sensible (at the time) Webpack configuration, and glossed over this being in the minified bundle, after 1-2 days at the time.
But if my hobby project would have been something production-relevant, I'd have continued to hunt down this artifact.
I think, with Vite et al this should not appear anymore in current JS bundles ready for prod, so the name is apt.
But the underlying problem is still a neverending source of frustration: minification is (by definition, when it's statically verifiable), not equipped to change object property names without provoking breakage.
In Webpack times, early React 18 days, manual config, "ejected" and adjusted from CRA, I did have it in my production bundle.
I just gave up checking on why after a couple hours because it was a hobby project.
Haven't seen it in a long time since then, but there are many overlapping factors here.
As far as I know, Vite/Rollup tree shaking is strictly better than what Webpack + Terser did, but I'm wondering where the difference comes from.
Maybe it's even a JSDoc annotation or something else that is esoteric.
Because tree-shaking all property names in JS without making static analysis arbitrarily complex, is still not possible.
So, if the change was not on React's side, I'd guess it is in bundler minifying heuristics or a backwards-compatible change that makes the property name inaccessible and erasable by other means.
Nrwl are right to be sceptical about Microsoft’s published download numbers for the compromised extension. Given that my machine downloaded it a full two hours after it was supposedly unpublished.
This list is incomplete - at least one other package (nx-console VS code extension; 2.2M downloads) was compromised yesterday with this worm: if suitably qualified/connected people are reading this, it could be worth following that dependency chain too in case there are more. See here:
Ouch: critical supply chain attack in one of the most popular VS Code Extensions (2.2M installs)
I was bitten by this today - the payload dropped a Python C2 backdoor and LaunchAgent. (fortunately, it failed to run due to failed dependencies...)
Incidentally, my local install was almost 2 hours after the maintainers claim they pulled it from the marketplace so the real-world exposure window appears to have been substantially longer than 11 minutes.
`2026-05-18 16:34:11.092 [info] Extracted extension to .../nrwl.angular-console-18.95.0`
Incidentally, this is one of the first times where an LLM was genuinely useful in helping me quarantine & identify the issue with a degree of certainty.
If you want further information on how the attack was obfuscated & executed, I posted in the nx-console Issues board [here](https://github.com/nrwl/nx-console/issues/3140) - (apols for the LLM-assisted post, as you would imagine I was in something of a hurry to report it)
reply