Having the same issues after upgrading to Chrome version 150. My Test Cognos environment is 12.1.3 and my PROD Cognos environment is 12.0.4.

• Errors when opening reports in edit mode
• Data packages not loading properly
• Missing column headers in report authoring screens
• Metadata-related errors during editing

Below is the error when I switch to Page preview, it gave me the server error

It is working fine so far for me using Edge and Firefox

Thanks,

Abbas

Hi, 

I opened a case and IBM has confirmed that is a issue with Chrome 150.

The recommendation is downgrade to version Chrome 149 and disable  GoogleUpdaterService and GooglUpdaterInternalService in Windows to avoid automatically updates.

Hi Jeam,

Thanks for sharing what IBM said and the workaround!

That definitely helps for the short term, but I do worry about the long term plan here. Did IBM mention if they're actually working on a fix for Cognos to support Chrome 150?

Downgrading and completely turning off the Google update services is going to be a really tough sell for a lot of IT teams. Most organizations just won't let employees disable those updates because missing out on browser security patches is too big of a risk.

Thanks,

Abbas

Hi, 

I opened a case and IBM has confirmed that is a issue with Chrome 150.

The recommendation is downgrade to version Chrome 149 and disable  GoogleUpdaterService and GooglUpdaterInternalService in Windows to avoid automatically updates.

Almost same issue at out side (v12.0.4 FP1), metadata load is blank, if i try to add a source i receive this error with chrome Version 150.0.7871.47 (Official Build) (64-bit):

Source remains empty:

In other browsers: firefox, edge its working fine.

I'll create a ticket to IBM, too.

One question: is this fixed already with v12.1.3?

best regards

Thomas

------------------------------
Thomas Grunewald
------------------------------

Almost same issue at out side (v12.0.4 FP1), metadata load is blank, if i try to add a source i receive this error with chrome Version 150.0.7871.47 (Official Build) (64-bit):

Source remains empty:

In other browsers: firefox, edge its working fine.

I'll create a ticket to IBM, too.

One question: is this fixed already with v12.1.3?

best regards

Thomas

------------------------------
Thomas Grunewald
------------------------------

I've identified at least part of the problem. Chrome now behaves differently when executing

querySelectorAll(':not(:empty, [*|space="preserve"], [*|space="default"])')

In Firefox when I run that against a specific report XML I get 115 nodes.

But in Chrome that returns 128 nodes. 

When I filter out the ones in common, what's left are the corrupted objects:

In Chrome that text item appears empty, but in Firefox I see the static text. So that means I'm able to at least locally patch this issue by going in and changing the file directly. 

This doesn't solve the issue with the list headers disappearing and the data source being empty, but it's a start.

And I've found the reason why the list headers aren't appearing. 

Let's take this code:

xmlstring = `<!DOCTYPE report [  <!ELEMENT modelPath (#PCDATA)>  <!ATTLIST modelPathxml:space (default | preserve) "preserve"type (FM | module | report) "FM">]><report useStyleVersion="11.6" expressionLocale="en">  <modelPath>/content/package[@name=&#39;GO Sales (query)&#39;]/model[@name=&#39;model&#39;]</modelPath></report>`xmlXml = (new DOMParser()).parseFromString(xmlstring, "text/xml");console.log(xmlXml.querySelector('modelPath').outerHTML)

I've identified at least part of the problem. Chrome now behaves differently when executing

querySelectorAll(':not(:empty, [*|space="preserve"], [*|space="default"])')

In Firefox when I run that against a specific report XML I get 115 nodes.

But in Chrome that returns 128 nodes. 

When I filter out the ones in common, what's left are the corrupted objects:

In Chrome that text item appears empty, but in Firefox I see the static text. So that means I'm able to at least locally patch this issue by going in and changing the file directly. 

This doesn't solve the issue with the list headers disappearing and the data source being empty, but it's a start.

Great pickup Paul.

It looks like it is related to this: https://issues.chromium.org/issues/531506229

So ultimately the problem is their project to move XML handling to use the Rust library xml-rs, which ignores DTDs entirely.

It looks like it can (for now) be worked around by disabling this feature. It's weird that this isn't exposed under chrome://flags but this works for me:

chrome.exe --disable-features=XMLRustForNonXslt

And I've found the reason why the list headers aren't appearing. 

Let's take this code:

xmlstring = `<!DOCTYPE report [  <!ELEMENT modelPath (#PCDATA)>  <!ATTLIST modelPathxml:space (default | preserve) "preserve"type (FM | module | report) "FM">]><report useStyleVersion="11.6" expressionLocale="en">  <modelPath>/content/package[@name=&#39;GO Sales (query)&#39;]/model[@name=&#39;model&#39;]</modelPath></report>`xmlXml = (new DOMParser()).parseFromString(xmlstring, "text/xml");console.log(xmlXml.querySelector('modelPath').outerHTML)

I've identified at least part of the problem. Chrome now behaves differently when executing

querySelectorAll(':not(:empty, [*|space="preserve"], [*|space="default"])')

In Firefox when I run that against a specific report XML I get 115 nodes.

But in Chrome that returns 128 nodes. 

When I filter out the ones in common, what's left are the corrupted objects:

In Chrome that text item appears empty, but in Firefox I see the static text. So that means I'm able to at least locally patch this issue by going in and changing the file directly. 

This doesn't solve the issue with the list headers disappearing and the data source being empty, but it's a start.

Great pickup Paul.

It looks like it is related to this: https://issues.chromium.org/issues/531506229

So ultimately the problem is their project to move XML handling to use the Rust library xml-rs, which ignores DTDs entirely.

It looks like it can (for now) be worked around by disabling this feature. It's weird that this isn't exposed under chrome://flags but this works for me:

chrome.exe --disable-features=XMLRustForNonXslt

And I've found the reason why the list headers aren't appearing. 

Let's take this code:

xmlstring = `<!DOCTYPE report [  <!ELEMENT modelPath (#PCDATA)>  <!ATTLIST modelPathxml:space (default | preserve) "preserve"type (FM | module | report) "FM">]><report useStyleVersion="11.6" expressionLocale="en">  <modelPath>/content/package[@name=&#39;GO Sales (query)&#39;]/model[@name=&#39;model&#39;]</modelPath></report>`xmlXml = (new DOMParser()).parseFromString(xmlstring, "text/xml");console.log(xmlXml.querySelector('modelPath').outerHTML)

I've identified at least part of the problem. Chrome now behaves differently when executing

querySelectorAll(':not(:empty, [*|space="preserve"], [*|space="default"])')

In Firefox when I run that against a specific report XML I get 115 nodes.

But in Chrome that returns 128 nodes. 

When I filter out the ones in common, what's left are the corrupted objects:

In Chrome that text item appears empty, but in Firefox I see the static text. So that means I'm able to at least locally patch this issue by going in and changing the file directly. 

This doesn't solve the issue with the list headers disappearing and the data source being empty, but it's a start.

Great pickup Paul.

It looks like it is related to this: https://issues.chromium.org/issues/531506229

So ultimately the problem is their project to move XML handling to use the Rust library xml-rs, which ignores DTDs entirely.

It looks like it can (for now) be worked around by disabling this feature. It's weird that this isn't exposed under chrome://flags but this works for me:

chrome.exe --disable-features=XMLRustForNonXslt

And I've found the reason why the list headers aren't appearing. 

Let's take this code:

xmlstring = `<!DOCTYPE report [  <!ELEMENT modelPath (#PCDATA)>  <!ATTLIST modelPathxml:space (default | preserve) "preserve"type (FM | module | report) "FM">]><report useStyleVersion="11.6" expressionLocale="en">  <modelPath>/content/package[@name=&#39;GO Sales (query)&#39;]/model[@name=&#39;model&#39;]</modelPath></report>`xmlXml = (new DOMParser()).parseFromString(xmlstring, "text/xml");console.log(xmlXml.querySelector('modelPath').outerHTML)

I've identified at least part of the problem. Chrome now behaves differently when executing

querySelectorAll(':not(:empty, [*|space="preserve"], [*|space="default"])')

In Firefox when I run that against a specific report XML I get 115 nodes.

But in Chrome that returns 128 nodes. 

When I filter out the ones in common, what's left are the corrupted objects:

In Chrome that text item appears empty, but in Firefox I see the static text. So that means I'm able to at least locally patch this issue by going in and changing the file directly. 

This doesn't solve the issue with the list headers disappearing and the data source being empty, but it's a start.

Chromium team has confirmed the root cause. They traced it to a new Chrome feature, XMLRustForNonXslt (field trial XMLParsingRustNonXslt) - Chrome's new Rust-based XML parser, which no longer applies the DTD default attribute values Cognos report specs rely on. 

Interim workaround: use Firefox (recommended), stay on Chrome ≤149, or launch Chrome with the new parser disabled. Fully quit Chrome first, then:

  Windows (cmd):  start chrome --disable-features=XMLRustForNonXslt  Mac:            open -a "Google Chrome" --args --disable-features=XMLRustForNonXslt  Linux:          google-chrome --disable-features=XMLRustForNonXslt

Note: there are no chrome://flags or policy toggle for it - the command-line launch is the only off-switch.

------------------------------
Pedro Jose Salguero Aguilar
------------------------------


Original Message:
Sent: 07/07/26 03:17 AM
From: Sam Angove
Subject: Is anyone else experiencing issues with Cognos after the latest Chrome update

Great pickup Paul.

It looks like it is related to this: https://issues.chromium.org/issues/531506229

So ultimately the problem is their project to move XML handling to use the Rust library xml-rs, which ignores DTDs entirely.

It looks like it can (for now) be worked around by disabling this feature. It's weird that this isn't exposed under chrome://flags but this works for me:

chrome.exe --disable-features=XMLRustForNonXslt

------------------------------
Sam Angove
------------------------------



Original Message:
Sent: 07/06/26 10:25 AM
From: Paul Mendelson
Subject: Is anyone else experiencing issues with Cognos after the latest Chrome update

And I've found the reason why the list headers aren't appearing. 

Let's take this code:

xmlstring = `<!DOCTYPE report [  <!ELEMENT modelPath (#PCDATA)>  <!ATTLIST modelPathxml:space (default | preserve) "preserve"type (FM | module | report) "FM">]><report useStyleVersion="11.6" expressionLocale="en">  <modelPath>/content/package[@name=&#39;GO Sales (query)&#39;]/model[@name=&#39;model&#39;]</modelPath></report>`xmlXml = (new DOMParser()).parseFromString(xmlstring, "text/xml");console.log(xmlXml.querySelector('modelPath').outerHTML)

------------------------------
Paul Mendelson Product Manager
Product Manager
PMsquare
------------------------------




Original Message:
Sent: 07/06/26 06:21 AM
From: Paul Mendelson
Subject: Is anyone else experiencing issues with Cognos after the latest Chrome update

I've identified at least part of the problem. Chrome now behaves differently when executing

querySelectorAll(':not(:empty, [*|space="preserve"], [*|space="default"])')

In Firefox when I run that against a specific report XML I get 115 nodes.

But in Chrome that returns 128 nodes. 

When I filter out the ones in common, what's left are the corrupted objects:

In Chrome that text item appears empty, but in Firefox I see the static text. So that means I'm able to at least locally patch this issue by going in and changing the file directly. 

This doesn't solve the issue with the list headers disappearing and the data source being empty, but it's a start.

------------------------------
Paul Mendelson Product Manager
Product Manager
PMsquare
------------------------------

i know it is probably redundant, but can you use the Target in a ShortCut instead of the Windows Command? Using the target does not seem to work for me, and the windows cmd does work. but, we are having issues with our development cognos at the moment so not a reliable test. and thinking about it more, not sure that i closed all chrome windows for each of the test. 

My shortcut Target

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-features=XMLRustForNonXslt

------------------------------
brenda grossnickle
BI Programmer Analyst
FIS
------------------------------


Original Message:
Sent: 07/08/26 01:08 PM
From: Pedro Jose Salguero Aguilar
Subject: Is anyone else experiencing issues with Cognos after the latest Chrome update

Chromium team has confirmed the root cause. They traced it to a new Chrome feature, XMLRustForNonXslt (field trial XMLParsingRustNonXslt) - Chrome's new Rust-based XML parser, which no longer applies the DTD default attribute values Cognos report specs rely on. 

Interim workaround: use Firefox (recommended), stay on Chrome ≤149, or launch Chrome with the new parser disabled. Fully quit Chrome first, then:

  Windows (cmd):  start chrome --disable-features=XMLRustForNonXslt  Mac:            open -a "Google Chrome" --args --disable-features=XMLRustForNonXslt  Linux:          google-chrome --disable-features=XMLRustForNonXslt

Note: there are no chrome://flags or policy toggle for it - the command-line launch is the only off-switch.

------------------------------
Pedro Jose Salguero Aguilar
------------------------------



Original Message:
Sent: 07/07/26 03:17 AM
From: Sam Angove
Subject: Is anyone else experiencing issues with Cognos after the latest Chrome update

Great pickup Paul.

It looks like it is related to this: https://issues.chromium.org/issues/531506229

So ultimately the problem is their project to move XML handling to use the Rust library xml-rs, which ignores DTDs entirely.

It looks like it can (for now) be worked around by disabling this feature. It's weird that this isn't exposed under chrome://flags but this works for me:

chrome.exe --disable-features=XMLRustForNonXslt

------------------------------
Sam Angove
------------------------------




Original Message:
Sent: 07/06/26 10:25 AM
From: Paul Mendelson
Subject: Is anyone else experiencing issues with Cognos after the latest Chrome update

And I've found the reason why the list headers aren't appearing. 

Let's take this code:

xmlstring = `<!DOCTYPE report [  <!ELEMENT modelPath (#PCDATA)>  <!ATTLIST modelPathxml:space (default | preserve) "preserve"type (FM | module | report) "FM">]><report useStyleVersion="11.6" expressionLocale="en">  <modelPath>/content/package[@name=&#39;GO Sales (query)&#39;]/model[@name=&#39;model&#39;]</modelPath></report>`xmlXml = (new DOMParser()).parseFromString(xmlstring, "text/xml");console.log(xmlXml.querySelector('modelPath').outerHTML)

------------------------------
Paul Mendelson Product Manager
Product Manager
PMsquare
------------------------------





Original Message:
Sent: 07/06/26 06:21 AM
From: Paul Mendelson
Subject: Is anyone else experiencing issues with Cognos after the latest Chrome update

I've identified at least part of the problem. Chrome now behaves differently when executing

querySelectorAll(':not(:empty, [*|space="preserve"], [*|space="default"])')

In Firefox when I run that against a specific report XML I get 115 nodes.

But in Chrome that returns 128 nodes. 

When I filter out the ones in common, what's left are the corrupted objects:

In Chrome that text item appears empty, but in Firefox I see the static text. So that means I'm able to at least locally patch this issue by going in and changing the file directly. 

This doesn't solve the issue with the list headers disappearing and the data source being empty, but it's a start.

------------------------------
Paul Mendelson Product Manager
Product Manager
PMsquare
------------------------------

Hey Brenda,

for me it's not working, too:

"C:\Program Files\Google\Chrome\Application\chrome.exe" --disable-features=XMLRustForNonXslt

Not as Shortcut, not via cmd Command Prompt.

What can i have done wrong?

best regards

Thomas

i know it is probably redundant, but can you use the Target in a ShortCut instead of the Windows Command? Using the target does not seem to work for me, and the windows cmd does work. but, we are having issues with our development cognos at the moment so not a reliable test. and thinking about it more, not sure that i closed all chrome windows for each of the test. 

My shortcut Target

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-features=XMLRustForNonXslt

------------------------------
brenda grossnickle
BI Programmer Analyst
FIS
------------------------------



Original Message:
Sent: 07/08/26 01:08 PM
From: Pedro Jose Salguero Aguilar
Subject: Is anyone else experiencing issues with Cognos after the latest Chrome update

Chromium team has confirmed the root cause. They traced it to a new Chrome feature, XMLRustForNonXslt (field trial XMLParsingRustNonXslt) - Chrome's new Rust-based XML parser, which no longer applies the DTD default attribute values Cognos report specs rely on. 

Interim workaround: use Firefox (recommended), stay on Chrome ≤149, or launch Chrome with the new parser disabled. Fully quit Chrome first, then:

  Windows (cmd):  start chrome --disable-features=XMLRustForNonXslt  Mac:            open -a "Google Chrome" --args --disable-features=XMLRustForNonXslt  Linux:          google-chrome --disable-features=XMLRustForNonXslt

Note: there are no chrome://flags or policy toggle for it - the command-line launch is the only off-switch.

------------------------------
Pedro Jose Salguero Aguilar
------------------------------




Original Message:
Sent: 07/07/26 03:17 AM
From: Sam Angove
Subject: Is anyone else experiencing issues with Cognos after the latest Chrome update

Great pickup Paul.

It looks like it is related to this: https://issues.chromium.org/issues/531506229

So ultimately the problem is their project to move XML handling to use the Rust library xml-rs, which ignores DTDs entirely.

It looks like it can (for now) be worked around by disabling this feature. It's weird that this isn't exposed under chrome://flags but this works for me:

chrome.exe --disable-features=XMLRustForNonXslt

------------------------------
Sam Angove
------------------------------





Original Message:
Sent: 07/06/26 10:25 AM
From: Paul Mendelson
Subject: Is anyone else experiencing issues with Cognos after the latest Chrome update

And I've found the reason why the list headers aren't appearing. 

Let's take this code:

xmlstring = `<!DOCTYPE report [  <!ELEMENT modelPath (#PCDATA)>  <!ATTLIST modelPathxml:space (default | preserve) "preserve"type (FM | module | report) "FM">]><report useStyleVersion="11.6" expressionLocale="en">  <modelPath>/content/package[@name=&#39;GO Sales (query)&#39;]/model[@name=&#39;model&#39;]</modelPath></report>`xmlXml = (new DOMParser()).parseFromString(xmlstring, "text/xml");console.log(xmlXml.querySelector('modelPath').outerHTML)

------------------------------
Paul Mendelson Product Manager
Product Manager
PMsquare
------------------------------






Original Message:
Sent: 07/06/26 06:21 AM
From: Paul Mendelson
Subject: Is anyone else experiencing issues with Cognos after the latest Chrome update

I've identified at least part of the problem. Chrome now behaves differently when executing

querySelectorAll(':not(:empty, [*|space="preserve"], [*|space="default"])')

In Firefox when I run that against a specific report XML I get 115 nodes.

But in Chrome that returns 128 nodes. 

When I filter out the ones in common, what's left are the corrupted objects:

In Chrome that text item appears empty, but in Firefox I see the static text. So that means I'm able to at least locally patch this issue by going in and changing the file directly. 

This doesn't solve the issue with the list headers disappearing and the data source being empty, but it's a start.

------------------------------
Paul Mendelson Product Manager
Product Manager
PMsquare
------------------------------

Hi,

Here is the Known Issue (KI) from IBM support:
https://www.ibm.com/mysupport/s/defect/aCIgJ000000FlEjWAK/dt475269

This record has been marked High Impact Pervasive (HIPER). 𝗔 𝗛𝗜𝗣𝗘𝗥 𝗞𝗻𝗼𝘄𝗻 𝗜𝘀𝘀𝘂𝗲 𝗱𝗲𝘀𝗰𝗿𝗶𝗯𝗲𝘀 𝗮 𝘀𝗲𝗿𝗶𝗼𝘂𝘀 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝗼𝗿 𝗮 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝘁𝗵𝗮𝘁 𝗶𝗺𝗽𝗮𝗰𝘁𝘀 𝗺𝗮𝗻𝘆 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿𝘀.

Best regards,

Hi Patrick,

Can you reload the link? Doesn't seem to work.

Thanks!

Hi,

Here is the Known Issue (KI) from IBM support:
https://www.ibm.com/mysupport/s/defect/aCIgJ000000FlEjWAK/dt475269

This record has been marked High Impact Pervasive (HIPER). 𝗔 𝗛𝗜𝗣𝗘𝗥 𝗞𝗻𝗼𝘄𝗻 𝗜𝘀𝘀𝘂𝗲 𝗱𝗲𝘀𝗰𝗿𝗶𝗯𝗲𝘀 𝗮 𝘀𝗲𝗿𝗶𝗼𝘂𝘀 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝗼𝗿 𝗮 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝘁𝗵𝗮𝘁 𝗶𝗺𝗽𝗮𝗰𝘁𝘀 𝗺𝗮𝗻𝘆 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿𝘀.

Best regards,

Hi,

Here is the Known Issue (KI) from IBM support:
https://www.ibm.com/mysupport/s/defect/aCIgJ000000FlEjWAK/dt475269

(Link is now working)

This record has been marked High Impact Pervasive (HIPER). 𝗔 𝗛𝗜𝗣𝗘𝗥 𝗞𝗻𝗼𝘄𝗻 𝗜𝘀𝘀𝘂𝗲 𝗱𝗲𝘀𝗰𝗿𝗶𝗯𝗲𝘀 𝗮 𝘀𝗲𝗿𝗶𝗼𝘂𝘀 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝗼𝗿 𝗮 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝘁𝗵𝗮𝘁 𝗶𝗺𝗽𝗮𝗰𝘁𝘀 𝗺𝗮𝗻𝘆 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿𝘀.

Best regards,

------------------------------
Patrick Neveu
BSL Consulting
IBM Champion
------------------------------

Hi,

Here is the Known Issue (KI) from IBM support:
https://www.ibm.com/mysupport/s/defect/aCIgJ000000FlEjWAK/dt475269

(Link is now working)

This record has been marked High Impact Pervasive (HIPER). 𝗔 𝗛𝗜𝗣𝗘𝗥 𝗞𝗻𝗼𝘄𝗻 𝗜𝘀𝘀𝘂𝗲 𝗱𝗲𝘀𝗰𝗿𝗶𝗯𝗲𝘀 𝗮 𝘀𝗲𝗿𝗶𝗼𝘂𝘀 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝗼𝗿 𝗮 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝘁𝗵𝗮𝘁 𝗶𝗺𝗽𝗮𝗰𝘁𝘀 𝗺𝗮𝗻𝘆 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿𝘀.

Best regards,

------------------------------
Patrick Neveu
BSL Consulting
IBM Champion
------------------------------

Hi,

Here is the Known Issue (KI) from IBM support:
https://www.ibm.com/mysupport/s/defect/aCIgJ000000FlEjWAK/dt475269

(Link is now working)

This record has been marked High Impact Pervasive (HIPER). 𝗔 𝗛𝗜𝗣𝗘𝗥 𝗞𝗻𝗼𝘄𝗻 𝗜𝘀𝘀𝘂𝗲 𝗱𝗲𝘀𝗰𝗿𝗶𝗯𝗲𝘀 𝗮 𝘀𝗲𝗿𝗶𝗼𝘂𝘀 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝗼𝗿 𝗮 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝘁𝗵𝗮𝘁 𝗶𝗺𝗽𝗮𝗰𝘁𝘀 𝗺𝗮𝗻𝘆 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿𝘀.

Best regards,

------------------------------
Patrick Neveu
BSL Consulting
IBM Champion
------------------------------

Just a note. I tried FF 152.0.4 and the report editing works, but the switcher is gone. 

Hi,

The same issue is still true with Chrome 150.0.7871.115. The only viable solution (if you think about security: you cannot reuse a previous version of Chrome and you cannot disable an existing feature in Chrome) is to choose another supported browser for the time being.

Best regards,

Yet it's not the Chromium engine per se. Edge  150.0.4078.48 works fine. 

That one is not my favourite Browser, but on a Windows machine I simply have it at hand.

Hi,

The same issue is still true with Chrome 150.0.7871.115. The only viable solution (if you think about security: you cannot reuse a previous version of Chrome and you cannot disable an existing feature in Chrome) is to choose another supported browser for the time being.

Best regards,

A client I work with has advised that Google is releasing a minor update to Chrome v150 as early as tomorrow to resolve this issue.

------------------------------
Robert Hofstetter
------------------------------


Original Message:
Sent: 07/10/26 04:51 AM
From: Thomas Wolf
Subject: Is anyone else experiencing issues with Cognos after the latest Chrome update

Yet it's not the Chromium engine per se. Edge  150.0.4078.48 works fine. 

That one is not my favourite Browser, but on a Windows machine I simply have it at hand.

------------------------------
Thomas Wolf
BI Professional
Techniker Krankenkasse
Hamburg
------------------------------



Original Message:
Sent: 07/09/26 12:23 PM
From: Patrick Neveu
Subject: Is anyone else experiencing issues with Cognos after the latest Chrome update

Hi,

The same issue is still true with Chrome 150.0.7871.115. The only viable solution (if you think about security: you cannot reuse a previous version of Chrome and you cannot disable an existing feature in Chrome) is to choose another supported browser for the time being.

Best regards,

------------------------------
Patrick Neveu
BSL Consulting
IBM Champion
------------------------------