Share
Paul Mendelson, July 13, 2026
Get the Best Cognos Solution
for Your Business Today!
Summary
Chrome 150 breaks all versions of Cognos across three separate areas: interactive report features, custom controls, and the authoring environment. The root cause for custom controls is that oControlHost.configuration returns null in Chrome 150. The fix is to fall back to the XML element. No Chrome setting resolves any of these issues. The only working workarounds are a different browser or rolling back to Chrome 149, and rolling back is not an option in many enterprise environments. IBM has acknowledged the issue and is actively investigating, but has not released a fix timeline. If you do roll back to Chrome 149, IBM recommends disabling the GoogleUpdaterService and GoogleUpdaterInternalService through Windows Services to prevent the auto-upgrade back to 150.
Update (July 15, 2026): Google released a fix and the latest version of Chrome works without any issue.
Update (July 14, 2026): Two developments since this was published.
1. A workaround that doesn’t require switching browsers. I’ve built a Cognos extension that patches this at the root by overloading querySelectorAll and parseFromString. It should resolve the issue across all Cognos versions without needing to change browsers or roll back Chrome.
Download the extension
Install it as a Cognos extension and it handles the rest automatically.
2. IBM has shipped fixes for 12.1.0 and 12.1.1, available now on Fix Central.
IBM Cognos Analytics 12.1.0 Interim Fix 4
IBM Cognos Analytics 12.1.1 Interim Fix 2
A fix for 12.1.2 is expected soon, however, if you’re on an older version, there’s currently no indication IBM plans a fix. Moving to a supported release is likely your best path forward.
The recommendations below (switching to Firefox/Edge, or rolling back Chrome) still apply if you’d rather wait on IBM’s official fix or aren’t ready to install the extension.
If you’ve been trying to do Cognos development work on Chrome 150 and wondering why everything seems to be on fire, you’re not imagining it. The latest Chrome update broke Cognos in multiple places simultaneously, and I’m not being dramatic when I say the authoring side is so bad that I eventually gave up cataloging all the things wrong with it.
Let me walk through what’s actually failing, because this one touches several distinct layers.
Table of Contents
What Is Chrome 150 Breaking in Cognos?
The failures fall into three buckets:
- The first is interactive report features. Running or refreshing a report results in a report server error. Exporting to any format fails. Sorting, filtering, and pivoting list to cross-tab all stop working. For end users who don’t do development work, this alone makes Cognos effectively unusable in Chrome 150.
- The second bucket is custom controls. And this is where things get particularly interesting, because IBM’s own custom controls fail here too, not just third-party ones. For this specific failure I’ve found a workaround and have already implemented it across all CogBox custom controls. More on that shortly.
- The third is the authoring environment, and this one is the worst. Open an existing report in Chrome 150 for editing and you’ll see expressions blank, text items empty, list headers missing, data sources gone. The list of broken things is long enough that I gave up looking for issues. The authoring environment is, for practical purposes, nonfunctional.
What’s Wrong With Custom Controls, and How Do You Fix It?
The root cause for the custom control failures is specific: in Chrome 150, oControlHost.configuration is null. In previous Chrome versions you could rely on this object being populated. Now you can’t.
The fix I’ve implemented in CogBox checks whether the configuration is null, and if so, pulls it from the XML element instead:
let config = oControlHost.configuration
?? JSON.parse(oControlHost.xmlElement.querySelector('configuration').textContent);
This is the kind of thing you don’t notice until Chrome breaks it. The XML element has always had the configuration data, but everyone was going through oControlHost.configuration because that’s the documented path. Chrome 150 removed that convenience, so now you have to go around it.
If you’re managing custom controls outside of CogBox, this is the pattern to apply. The logic is the same regardless of what your control does: check if oControlHost.configuration is null first, then fall back to the XML element. Test thoroughly after applying the fix since other Chrome 150 issues may surface depending on what your control does.
The Authoring Side: Don’t Even Try
For the authoring environment there’s no workaround I’ve found. The breakage is pervasive enough that my honest recommendation is to not attempt authoring in Chrome 150 at all. Recommending that Cognos developers stop doing development work in Chrome 150 would be like telling people to stop walking on Legos. Only masochists or toddlers would be attempting that at this point.
In some enterprise environments you also may not have the option to roll Chrome back to 149. Chrome typically auto-updates, and many organizations don’t give users control over browser versions. In those cases, a different browser is the only path.
What Can You Actually Do Right Now?
Use a different browser. Firefox and Edge both work. If you have a choice, use one of them for all Cognos work until IBM ships a patch.
Rolling back to Chrome 149 is the other option, but again, this isn’t available to everyone. If you do roll back, IBM recommends disabling the GoogleUpdaterService and GoogleUpdaterInternalService through the Windows Services console to stop Chrome from auto-upgrading itself back to 150. I’ve also tested Chrome settings extensively looking for a flag or configuration change that would restore Cognos functionality. There isn’t one. No Chrome setting I’ve tried resolves any of the three failure categories above.
If your team does active Cognos development, treat “Chrome 150 is not a development browser” as a working policy until further notice. Document it and make sure your developers and power users know. The frustration of discovering this mid-session is avoidable.
When Is IBM Going to Fix This?
IBM has now released an official statement: “We are aware of the issue introduced following the recent Google Chrome Version 150 update and are actively investigating the root cause to determine the impact on Cognos and identify a permanent resolution.” That’s the full extent of what they’ve committed to publicly. Actively investigating is not the same as a timeline.
A fix could come from either side. IBM could patch Cognos to stop relying on whatever Chrome changed. Google could release a patch that restores the old behavior or adds a setting that allows it. I’m not holding my breath on the Google side, though. Browser vendors don’t typically roll back changes once they’ve shipped.
So plan accordingly. The browser recommendation stands until a patch arrives. When one does, test your environment before rolling Chrome back for your whole user population. A fix from IBM might address some of these failure categories and not others, so verify before assuming everything works again.
Questions I’m Hearing From Clients
It affects all versions of Cognos Analytics I’ve tested. This is a Chrome-side change that removed something Cognos relied on across the board, so your Cognos version isn’t the relevant variable. The browser change broke the interface regardless of what version you’re running.
Not entirely. The recommendation is to switch to a different browser for all Cognos work until IBM patches the issue. Firefox and Edge both work fine. Changing browsers for your development team and power users is the lowest-effort path here.
Start with the oControlHost.configuration check. That’s the core failure pattern. Check if it’s null before using it, and fall back to oControlHost.xmlElement.querySelector('configuration').textContent if it is. Your specific controls may have additional Chrome 150 issues beyond this one, so test thoroughly after applying the fix before calling it done.
Yes, just not Chrome 150. Firefox and Edge both have functional Cognos authoring environments. If your team standardized on Chrome for everything, this is a good moment to make sure Firefox is installed and available on every development machine.
They’ve acknowledged it and issued an official statement that they’re actively investigating. Beyond that, I don’t have a timeline to give you. Watch IBM’s support channels and the Cognos community forums for patch announcements. When something ships, test before rolling it out broadly.
We hope you found this article both intriguing and informative. At PMsquare, we specialize in cutting through the hype to deliver impactful, outcome-driven AI and analytics solutions. We help you build the data foundation, implement the right tools, and establish the governance needed to turn AI’s promise into your competitive advantage. If this is something you are looking for, contact us today.
Be sure to subscribe to our newsletter for more PMsquare updates and insights delivered straight to your inbox.
