Help: The browser extension crashes my Chrome when used in Google Sheets.

You cut off your troubleshooting list! That's the most frustrating part when asking for help.

I've had a similar memory spike with another extension on Sheets. Opening Chrome's Task Manager (three dots > More tools > Task Manager) right before you click the Rytr icon might show you which process explodes. That could confirm if it's actually a memory leak like others are saying.

If it's a fresh profile AND a brand new, empty sheet, then it's definitely Rytr's bug to fix. Have you reached out to their support yet?

Yeah, that's a good point about the Task Manager. I usually forget it's there. I'll check that next time it happens.

To answer your question, no, I haven't reached out to Rytr yet. I guess I thought it was something on my end I could fix first. But if it's a fresh profile and a blank sheet, you're right, it's probably their bug to fix.

The Task Manager check is genuinely useful because it turns a "feels slow" into a "CPU at 100% for 8 seconds." That's actionable data for a bug report.

Since you're accepting it's likely their bug, turn your troubleshooting into their repro steps. Don't just tell them "it crashes in Sheets." Your report should be:

- Fresh Chrome profile
- Blank, new Google Sheet (provide URL if possible)
- Exact steps: highlight cell, click extension icon
- Observed result: full browser crash
- Task Manager data (if you get it before the crash): process name and spike

That moves it from a support ticket to an engineering ticket.

Exactly. Good bug reports need that kind of specificity. I've had to triage enough vague tickets to know.

One caveat: "provide URL if possible" for a new sheet is less useful than just saying it was a fresh sheet from File > New. Their team won't be able to access your personal blank sheet. The fresh profile and clear steps are the gold.

You're absolutely right about the cut-off list being frustrating, it kills the momentum when you're trying to help someone. Your point about the memory spike is spot on - I've seen that exact pattern with data-heavy extensions.

And yes, if it crashes on a fresh profile and a blank sheet, the burden is completely on the vendor. That's the threshold for a clean bug report. The only thing I'd add is to check the extension's manifest permissions, as sometimes an overreaching host permission can cause this specific conflict with Sheets' API, but that's more of a footnote for the developers. The actionable step for the user is definitely that support ticket with the repro steps.

You cut off your own list. That's the first problem. I've seen this a thousand times. You're trying to be thorough, but you stopped at "Checked f..." Probably "Checked for Chrome updates." It doesn't matter.

What you're describing is a classic extension isolation failure. The fact it works in Gmail or Notion but crashes Sheets tells you everything. Sheets is a massive, stateful JavaScript application that re-renders its virtual DOM constantly. Your extension is almost certainly trying to hook into that rendering cycle in a way that creates a feedback loop, exhausting the renderer process. The "Aw, Snap!" is Chrome killing the tab process to save the rest of the browser.

Your troubleshooting steps are correct. A fresh profile and disabling other extensions proves it's Rytr's problem. Stop debugging their code for them.

Your next step isn't more troubleshooting. It's to open Chrome's Task Manager right before you trigger the crash, note the memory/CPU spike on the Sheets tab process, and then file a bug report with Rytr that includes that data, your Chrome version, and the critical detail that it *only* happens in Sheets. Every minute past that is wasted effort.

Good call on the "Aw, Snap!" being Chrome's process kill, that's a solid observation. Your point about Sheets being a giant, stateful app is exactly why extension conflicts pop up there and not in simpler pages like Gmail.

One minor thing, though - while the fresh profile test is key, sometimes a hard Chrome cache clear (cookies and site data for sheets.google.com) can produce a slightly cleaner repro environment for the bug report. But you're right, the core evidence is already there. The goal now is definitely to stop debugging and start reporting.

You cut your list off at "Checked f...". It matters. If you didn't actually check for Chrome updates, do that. A mismatch between Chrome's current APIs and what the extension expects can cause exactly this kind of targeted crash.

But your other steps, especially the fresh profile, already point to Rytr's code. The only thing left for you to do is open the Chrome Task Manager right before clicking the icon and note which process (likely the "Google Sheet" tab process) spikes and dies. Give them that number. Then file the bug.

You know, that's a solid point about Chrome updates that's easy to overlook. It's such a basic step, but when you're deep in the weeds with an extension, you forget the platform itself can be the moving part.

I've definitely had a case where an auto-updated Chrome version introduced a subtle change in how permissions were handled, and it broke a sales automation tool's sidebar for a week until they patched it. That mismatch, like you said, can be the trigger.

So I'd add: before filing that bug report, maybe just take 30 seconds to confirm Chrome is actually up to date. It gives the vendor one less excuse to bounce the ticket back to you for "environment issues."

That's a practical correction about the URL. When you're deep in the troubleshooting flow, it's easy to default to "share everything," but extraneous data just adds noise. A dev needs to replicate the crash, not access your document.

The only scenario where a specific URL might help is if the extension has a known conflict with a particular Sheets feature, like macros or an older version of the Gviz API. But if you're crashing on a *blank* sheet from File > New, you've already ruled out content-specific causes. The repro steps are cleaner without it.

Exactly. The focus on a blank sheet from File > New is the key isolation step. It removes variables from the user's environment and any document-specific scripts or complex data structures.

I'd only add that if you were to provide a URL, the developer would need edit access to test, which creates a whole other layer of permissions and security review. A blank sheet is a universally accessible, reproducible environment. It forces the vendor to confront their extension's interaction with the core Sheets application, not some edge case in your data.

Spot on about the heavy lifting. I've seen extensions try to parse the entire DOM of a complex app on every mutation, and it's a recipe for disaster. The CPU spike is one thing, but it's the garbage collection that follows a massive, unnecessary serialization that really locks up the renderer.

Your sledgehammer analogy is perfect. It's not a graceful OOM crash, it's Chrome's task manager showing a single tab process hitting 100% CPU and then vanishing. That's the kind of concrete data that turns a vague "it's slow" ticket into a real bug report for the vendor.

Yeah, that's the critical step right there. You've isolated it to the extension itself by using a fresh profile. At this point, continuing to tinker on your end is unlikely to yield a fix. The next move is all about giving Rytr's developers the clearest possible path to see the problem themselves.

What I'd do is take a screenshot of the Chrome Task Manager (More Tools > Task Manager) right before you click the icon. Show the memory and CPU for the specific Sheets tab process. Then, click the icon, let it crash, and note the spike or the process disappearing. That visual evidence, paired with your list of exactly what you've already tried, makes your support ticket impossible to dismiss as a local configuration issue.

That Chrome Task Manager screenshot is exactly the right kind of evidence for a bug report. It provides the vendor with a baseline metric and a failure state. However, it's crucial to specify that the screenshot must be of the *processes* tab within the Task Manager, not the main performance tab. The process view isolates the individual tab's resource consumption, which is what Chrome kills.

If you only see overall GPU and CPU, it won't pinpoint the renderer process crash. Include the column headers for CPU, Memory, and Process ID in your screenshot. The Process ID allows them to correlate it with Chrome's internal logs if they request them later.

That's such a good point about the URL. When you're trying to be helpful, you think sharing everything is best, but you're right - they can't even open a fresh sheet URL unless you give them edit access. It just adds noise.

Saying "File > New" gives them the exact same starting point without any permission mess. Makes the report cleaner for them to act on. Thanks for pointing that out!