Level up your business security with free, on-demand training and certification. Explore 1Password Academy today →
Forum Discussion
1P_Blake
Community Manager
Community ManagerPSA: Extension going blank or unresponsive in Chrome? Here's what we know
Hey everyone! We've been tracking a recent Chrome change that’s causing the 1Password extension to go blank or become unresponsive after filling on certain sites, and wanted to share what’s going on.
A change in Chrome 147 has introduced an issue with how the browser handles extensions and its back/forward cache. We have seen reports of this issue affecting other password managers too, so it’s not only 1Password.
We are in direct contact with the Chrome team and they're working on a fix. We anticipate a Chrome update on Wednesday will resolve this problem, and we’ll keep you informed if that timeline changes. Brave and Edge users on version 147 will also be affected since they share the same Chromium engine.
In the meantime, if the 1Password extension displays a blank screen or otherwise becomes unresponsive, fully quitting and reopening your browser should get things working again. Not ideal, we know, but it does the trick until the fix is rolled out.
We'll update this post when the fix ships. If you're seeing this and want to follow along on the Chromium side, here's the bug report.
Update: Good news! Chrome has started rolling out an update (147.0.7727.102) that resolves this issue. If you haven't received it yet, you should be getting it soon. Once it lands, just restart your browser and you should be good to go.
- Brave users on the latest stable (1.89.137) should already be in the clear.
- Edge is still affected on stable. The fix is in Edge's beta, dev, and canary channels, so it should make its way to stable soon.
We'll keep this post updated as things progress. Thanks for hanging in there with us on this one! 💙
5 Replies
Today's Stable Channel Update for Desktop to version 147.0.7727.101 may have addressed this bug which I observed in the initial stable 147 version, 147.0.7727.55 (and .56 for Windows and MacOS).
Since the symptom occurs after some time after behaving normally, confident prediction is impossible, however it is alleged to be fixed.
1P_Blake Given the disruption of a foundational behavior of the software, why is it that 1Password isn't using its status service to make users aware of incidents like this? It does for many less frequently used features (as I write this, there is one impacting SSO for example and that is also due to a third-party cause for example). It's great to clearly post it in the community but that's a venue not many look at and not what we're told to follow to understand if there are availability disruptions. Surely something so central to the use of the software deserves using the status mechanism provided rather than making users actively search to determine if it's their own issue or 1Password's.
Also... Are Chromium builds not available for 1Password to regression test against before they are released to the public channel? If so, is 1Password doing what it can to discover potential integration/regression issues before they impact paying customers? I'd venture Chromium represents a massive segment of usage. We're not talking about edge cases here.
- 1P_Blake
Hey reub! The honest answer is that this sat in an awkward middle ground. The issue itself was fairly intermittent and depends on specific browsing flows, so it's not exactly a clean "service is down" sorta' situation that maps neatly to the status page. On top of that, we also don't actually have a line item for the browser extension on the status page right now, which is something this has definitely surfaced as a gap on our end.
That said, you’re right that the extension is central to how most people use 1Password day to day, and a community post probably is not the first place most people are going to look when something starts breaking. We should be thinking more carefully about how we surface issues like this. I’m bringing that feedback back to the team, because I do think there’s room for us to do better here.
As for testing against pre-release Chromium builds, we do! Our browser extension team runs Chrome Dev, Beta, or Canary as their daily drivers while working on the extension. We caught this specific bug on April 8, before it reached Chrome stable, flagged it with the Chrome team right away, and have been working closely with them since.
We’re also in the process of expanding our automated end-to-end coverage against pre-release builds on a recurring schedule, which should help us catch things like this even earlier.
Couldn't agree more here. How can a software developer as prominent as 1Pass not be doing regression testing against pre-release builds of Chrome, or being more upfront with it's customers? I understand one or the other, but both? I only discovered this post after frustration-posting about the issue on X...
Thanks for the update. I was going crazy with this. Really frustrating. I'm on Linux running Chromium and I see the same issue.
