Closed Bug 1567182 Opened 2 years ago Closed 1 year ago

Since 68.0, cannot access portal and business information anymore in IBM Cognos portal

Categories

(Web Compatibility :: Desktop, defect, P2)

Product:
Web Compatibility
Component:
Desktop
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: asouquiere, Unassigned)

References

(Regression)

Details

(Keywords: regression)

Attachments

(8 files)

inspector-firefox
2.07 KB, text/html
Details
WebConsole
18.84 KB, text/plain
Details
WebConsole
3.84 KB, text/plain
Details
FF-error message
4.85 KB, text/plain
Details
error message with console
137.36 KB, image/png
Details
only errors and warnings
99.86 KB, image/png
Details
sample data on my trial account
373.57 KB, image/png
Details
11.1.3 error and webconsole
117.21 KB, image/png
Details
Attached file inspector-firefox —

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36

Steps to reproduce:

https://xxxxxx/ibmcognos/bi/?perspective=authoring&pathRef=.public_folders%2FD-Divers%2FPortail%2FHss+Activit%C3%A9+Live%2FLive&id=iF797B623629746778576D5DEDAB9B28E&objRef=iF797B623629746778576D5DEDAB9B28E&type=report&format=HTML&Download=false&cmProperties%5Bid%5D=iF797B623629746778576D5DEDAB9B28E&rsFinalRunOptions%5Bformat%5D=HTML&rsFinalRunOptions%5BDownload%5D=false&UIProfile=Titan

Actual results:

_Z3L._NTE@https://cgnprd.ventadis.fr/ibmcognos/bi/pat/halcchl_block.js:1:58619
_J58.prototype._K4L@https://cgnprd.ventadis.fr/ibmcognos/bi/pat/rsstartupblock_8.js:21:3986
_J58@https://cgnprd.ventadis.fr/ibmcognos/bi/pat/rsstartupblock_8.js:21:3898
_036._GF3@https://cgnprd.ventadis.fr/ibmcognos/bi/pat/rsstartupblock_8.js:21:2387
_036._MC5@https://cgnprd.ventadis.fr/ibmcognos/bi/pat/rsstartupblock_8.js:21:3363
_0UJ._EC9@https://cgnprd.ventadis.fr/ibmcognos/bi/pat/rsstartupblock_6.js:11:30330
_0UJ._Z1J@https://cgnprd.ventadis.fr/ibmcognos/bi/pat/rsstartupblock_6.js:11:19171
_0UJ._N3L@https://cgnprd.ventadis.fr/ibmcognos/bi/pat/rsstartupblock_6.js:11:18485
_0UJ._M73@https://cgnprd.ventadis.fr/ibmcognos/bi/pat/rsstartupblock_6.js:11:11996
_JIF._UYI@https://cgnprd.ventadis.fr/ibmcognos/bi/pat/rsstartupblock_5.js:7:10246
_JIF._OCK@https://cgnprd.ventadis.fr/ibmcognos/bi/pat/rsstartupblock_5.js:7:8702
_JIF._OY5@https://cgnprd.ventadis.fr/ibmcognos/bi/pat/rsstartupblock_5.js:7:6523
_JIF._MK@https://cgnprd.ventadis.fr/ibmcognos/bi/pat/rsstartupblock_5.js:7:8652
_D1B._BRA/<@https://cgnprd.ventadis.fr/ibmcognos/bi/pat/rsstartupblock_1.js:7:10083
_fulfilled@https://cgnprd.ventadis.fr/ibmcognos/bi/lib/q/1.0.1/q.js:787:54
Promise.prototype.then/</<@https://cgnprd.ventadis.fr/ibmcognos/bi/lib/q/1.0.1/q.js:816:30
Promise/promise.promiseDispatch@https://cgnprd.ventadis.fr/ibmcognos/bi/lib/q/1.0.1/q.js:749:13
become/</<@https://cgnprd.ventadis.fr/ibmcognos/bi/lib/q/1.0.1/q.js:557:44
flush@https://cgnprd.ventadis.fr/ibmcognos/bi/lib/q/1.0.1/q.js:108:17

Expected results:

Have a look on portal and business information
with older version its work like a charm!

Nearly 200 people are involved in our company
Thanks for your help.
Waiting

See the error that you posted:

Le script à lâadresse « https://cgnprd.ventadis.fr/ibmcognos/bi/js/ba-polyfill.js?v=11.0.12 » a été chargé alors que son type MIME (« ») nâest pas un type MIME JavaScript valide.

I don't see any bug in Firefox here? This ticket also lacks a description of the actual outcome (what does not work).

Does the problem still happen if you start Firefox in Safe Mode? (Safe Mode disables add-ons, extensions and themes, hardware acceleration and some JavaScript stuff in order to exclude some possible reasons for problems.) See https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

And does this also happen with a new and empty profile? See https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile

Flags: needinfo?(asouquiere)

Does the problem still happen if you start Firefox in Safe Mode?
Yes.
We have already tested in safe mode and we are experiencing the same error message.
All of our users have this message since the last firefox update
This is a real problem for us

And does this also happen with a new and empty profile?
Yes we have the same problem.

Flags: needinfo?(asouquiere)

I cannot decrypt / read the attachment above, so if there is some error in the console of the Developer Tools, please post that error including its stacktrace, in a readable format...

Hello, We have also experienced the same issue.
All our reports were working fine on Firefox prior to release 68.
They continue to work fine on Internet Explorer, but that's no good enough for Mac users.
We would like to help you in identifying the root cause for this issue.

Hi, please see my previous comment requesting readable data from the console of the developer tools.
See https://developer.mozilla.org/en-US/docs/Tools/Web_Console for more information. Thanks!

Summary: Firefox v68.0 bug with ibm cognos portal → Since 68.0, cannot access portal and business information anymore in IBM Cognos portal
Attached file WebConsole — 
Is it good for you ?
Below elements of the web console 
*******

Thanks. There are two error messages that one file is not found on your server, and hence it cannot be loaded:

GET https://cgnprd.ventadis.fr/ibmcognos/bi/js/ba-polyfill.js?v=11.0.12
[HTTP/1.1 404 Not Found 0ms]

Le script à l’adresse « https://cgnprd.ventadis.fr/ibmcognos/bi/js/ba-polyfill.js?v=11.0.12 » a été chargé alors que son type MIME (« ») n’est pas un type MIME JavaScript valide. bi
GET https://cgnprd.ventadis.fr/ibmcognos/bi/js/ba-polyfill.js?v=11.0.12
[HTTP/1.1 404 Not Found 3ms]

I don't see how this is a Firefox bug (yet), but instead something to fix in IBM Cognos (or your configuration)?

Flags: needinfo?(asouquiere)

Hi Andre -
But everything works fine on Firefox prior to 68.
Is there any way different in using MIME types, or processing JS?
Regards

Krzysztof Bender

Sorry, no idea and I'm not a developer.
You may want to go through change logs, or run a regression test: https://github.com/mozilla/mozregression/#readme

Attached file WebConsole — 
Is it good for you ?
Below elements of the web console 
*******
(In reply to Andre Klapper from comment #9)
> Sorry, no idea and I'm not a developer.
> You may want to go through change logs, or run a regression test: https://github.com/mozilla/mozregression/#readme

Hello

I just tested on a macbook. It works!
Firefox version: 60.8.0

If we have to donwgrade version we will make it simpler. Unfortunately we will stop using firefox if no resolution.
We can not continue to adapt to each update.
Below the screenshot of the web console!

Hi,
I can't access to the url for the steps, could you share them please?
Also, Could you please try to see if it's reproducible on Nightly? here is the link for download https://www.mozilla.org/en-US/firefox/nightly/all/

Thanks!

Is it good for you ?
Below elements of the web console

(In reply to Andre Klapper from comment #9)

Sorry, no idea and I'm not a developer.
You may want to go through change logs, or run a regression test: https://github.com/mozilla/mozregression/#readme

Hello

I just tested on a macbook. It works!
Firefox version: 60.8.0

If we have to donwgrade version we will make it simpler. Unfortunately we will stop using firefox if no resolution.
We can not continue to adapt to each update.
Below the screenshot of the web console!
(In reply to Luciana queirolo from comment #11)

Hi,
I can't access to the url for the steps, could you share them please?
Also, Could you please try to see if it's reproducible on Nightly? here is the link for download https://www.mozilla.org/en-US/firefox/nightly/all/

Thanks!

Hello
I've installed 70.0a1 (2019-07-23) (64 bits) but i have the same way

Note : I can't share url it's on private network.
Regards

Flags: needinfo?(asouquiere)

Hi @Antoine, based on the comment 11 and on the next one, couldn't access the link from description and there is no way to test the problem.
Please provide some info or find a way to describe the problem in order to figure it out what may case it.
For now, I will set a component, if isn't the right one please fell free to change it.
Thanks.

Component: Untriaged → Networking: HTTP
Flags: needinfo?(asouquiere)
Product: Firefox → Core
Attached file FF-error message — 
As it seems related to the issue I'm facing, I'm posting here. 
I have the same issue with nightly and 68.0.1, both 64 bit. 

When I open reporting, I get the following error:

As it seems related to the issue I'm facing, I'm posting here.
I have the same issue with nightly and 68.0.1, both 64 bit.

When I open reporting, I get the following error:
See attached error.

The console gives the following error: TypeError: _8UE is null
TypeError: _8UE is null halcchl_block.js:1:58734
_SUE https://elkjop.bi.ibmcloud.com/bi/pat/halcchl_block.js:1
_26L https://elkjop.bi.ibmcloud.com/bi/pat/rsstartupblock_8.js:21
_D68 https://elkjop.bi.ibmcloud.com/bi/pat/rsstartupblock_8.js:21
_VF3 https://elkjop.bi.ibmcloud.com/bi/pat/rsstartupblock_8.js:21
_577 https://elkjop.bi.ibmcloud.com/bi/pat/rsstartupblock_7.js:19
_SJ4 https://elkjop.bi.ibmcloud.com/bi/pat/packages/TemplateOperations/_Z49_async.js:6
_8N3 https://elkjop.bi.ibmcloud.com/bi/pat/packages/TemplateOperations/_Z49_async.js:6
_FV8 https://elkjop.bi.ibmcloud.com/bi/pat/rsstartupblock_2.js:43
_WS9 https://elkjop.bi.ibmcloud.com/bi/pat/rsstartupblock_2.js:43
_MN9 https://elkjop.bi.ibmcloud.com/bi/pat/rsstartupblock_2.js:43
_N3B https://elkjop.bi.ibmcloud.com/bi/pat/rsstartupblock_2.js:43
_2WK https://elkjop.bi.ibmcloud.com/bi/pat/packages/TemplateOperations/_Z49_async.js:6
_IYK https://elkjop.bi.ibmcloud.com/bi/pat/packages/TemplateOperations/_Z49_async.js:6
_AD3 https://elkjop.bi.ibmcloud.com/bi/pat/packages/TemplateOperations/_Z49_async.js:6
_NH2 https://elkjop.bi.ibmcloud.com/bi/pat/packages/TemplateOperations/_Z49_async.js:6
_GPE https://elkjop.bi.ibmcloud.com/bi/pat/rsstartupblock_1.js:33
bind_applyFunctionN self-hosted:1195
<anonymous> self-hosted:1145
_L5G https://elkjop.bi.ibmcloud.com/bi/pat/rsstartupblock_1.js:33
_ZVK https://elkjop.bi.ibmcloud.com/bi/pat/rsstartupblock_1.js:33
bind_applyFunctionN self-hosted:1185
<anonymous> self-hosted:1145
_PU8 https://elkjop.bi.ibmcloud.com/bi/pat/rsstartupblock_1.js:33
_Q75 https://elkjop.bi.ibmcloud.com/bi/pat/rsstartupblock_1.js:33
_I7A https://elkjop.bi.ibmcloud.com/bi/pat/rsstartupblock_3.js:13
_2T1 https://elkjop.bi.ibmcloud.com/bi/pat/rsstartupblock_3.js:13
bind_applyFunctionN self-hosted:1183
<anonymous> self-hosted:1162
It works fine in IE and Chrome.

Have some news about this bug ??
Thx

Flags: needinfo?(asouquiere)

Antoine (or anyone experiencing this issue), your report is too fuzzy for us to follow, error console messages are something we can't make a conclusion from. So I'll ask few questions (maybe some repeated) to have a summary of what happens and what is expected, to start from and then possibly collect more detailed information I'll ask for in reply.

  • what exactly is the expected outcome from the point of view of the user (how the web page is expected to look like or behave like)
  • what exactly is the actual (buggy) outcome (how the web page is looking like or behaving like, and I don't mean just web console error logs)
  • helpful will be to simply compare 67 and 68 outcomes for differences, specifically the Networking panel in devtools differences
  • the most helpful thing to move us to a fix would be to use mozregression to find the exact change that caused this (it's a semi-automated bisection tool, you'll like it ;))

I'm asking these because so far it's not clear at all if this is a networking issue, script load or script execution problem or something else.

Thank you.

Flags: needinfo?(kbender)
Flags: needinfo?(deep750)
Flags: needinfo?(asouquiere)

Hello
Here some information (with mozregression last buil)

Working GOOD for us :
app_name: firefox
build_date: 2019-04-15
build_file: C:\Users\asouquiere.mozilla\mozregression\persist\2019-04-15--mozilla-central--firefox-68.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2019/04/2019-04-15-21-36-26-mozilla-central/firefox-68.0a1.en-US.win64.zip
changeset: b8f49a14c458f56a6a08e4c177671108e386be3a
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b8f49a14c458f56a6a08e4c177671108e386be3a&tochange=e7e658ec1e98c3868b98195c2ee4b9fe3842172e
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central

Working BAD for us :
app_name: firefox
build_date: 2019-06-17
build_file: C:\Users\asouquiere.mozilla\mozregression\persist\2019-06-17--mozilla-central--firefox-69.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2019/06/2019-06-17-21-40-29-mozilla-central/firefox-69.0a1.en-US.win64.zip
changeset: 40c99f4752f968db32f189243b4432b18d1b3471
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b8f49a14c458f56a6a08e4c177671108e386be3a&tochange=40c99f4752f968db32f189243b4432b18d1b3471
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central

When it works the user has financial results.

When it does not work the user has a blank page

Flags: needinfo?(asouquiere)

Thanks for using mozregression! But we need you to go way deeper with the bisection as this is two months span. It's impossible to make a conclusion what exact change causes this. Thanks.

Flags: needinfo?(asouquiere)

Like this ?

BAD
app_name: firefox
build_date: 2019-04-19 15:36:45.130000
build_file: C:\Users\asouquiere.mozilla\mozregression\persist\edbf9758ea94-shippable--autoland--target.zip
build_type: inbound
build_url: https://queue.taskcluster.net/v1/task/elO8KpjoT7uzfQPpDITutQ/runs/0/artifacts/public%2Fbuild%2Ftarget.zip
changeset: edbf9758ea946df5063e84c397c43208c555fd74
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=4a10eafaa8ad2311924a28bd1da8c8bc21b7842a&tochange=edbf9758ea946df5063e84c397c43208c555fd74
repo_name: autoland
repo_url: https://hg.mozilla.org/integration/autoland
task_id: elO8KpjoT7uzfQPpDITutQ

GOOD
app_name: firefox
build_date: 2019-04-19 15:19:08.187000
build_file: C:\Users\asouquiere.mozilla\mozregression\persist\3240b92c5566-shippable--autoland--target.zip
build_type: inbound
build_url: https://queue.taskcluster.net/v1/task/dZOaXnvoRzu2LCKNcTLUPw/runs/0/artifacts/public%2Fbuild%2Ftarget.zip
changeset: 3240b92c556673fc5eaaeed281bd890db02bd851
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3240b92c556673fc5eaaeed281bd890db02bd851&tochange=edbf9758ea946df5063e84c397c43208c555fd74
repo_name: autoland
repo_url: https://hg.mozilla.org/integration/autoland
task_id: dZOaXnvoRzu2LCKNcTLUPw

Flags: needinfo?(asouquiere)

Yes! Thanks for this. I'll tentatively mark this bug as a regression caused by bug 1281135 (which seems to be the one of the two to cause this more likely).

Emilio, can you look at this please?

Component: Networking: HTTP → DOM: CSS Object Model
Flags: needinfo?(kbender)
Flags: needinfo?(emilio)
Flags: needinfo?(deep750)
Keywords: regression
Regressed by: 1281135

Is there any kind of repro I could access?

Also, can you confirm that it works if you flip dom.link.disabled_attribute.enabled to false in about:config? That'd confirm it's a regression from that bug.

Flags: needinfo?(asouquiere)

And sure, can take a look, though most likely the site is doing some UA sniffing and relying on our old behavior, or something of that sort.

But hard to say without an URL / repro.

Assignee: nobody → emilio
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

(Waiting for comment 24, so clearing from ni? queue. Please put ni? back if I seem to forget about this)

Flags: needinfo?(emilio)

I checked setting dom.link.disabled_attribute.enabled to false, and it works.

Flags: needinfo?(emilio)

(In reply to deep750 from comment #27)

I checked setting dom.link.disabled_attribute.enabled to false, and it works.

I also see that other functionality in Cognos misbehaves when I set it to false, but that is maybe expected?

Not really... We implemented <link disabled> for compat with other browsers, but the functionality with the flag set to false should be the same as before... Though of course that may already misbehave in 67 or such?

I still need a way to reproduce the issue so it can be fixed or at least diagnosed. Otherwise I can't help much more... :(

Flags: needinfo?(emilio)

My bad, restarting the browser fixed the misbehaving.
The problem with giving you access is that the systems are mostly internal. What you can do is create a trial account in the cloud, which will give you possibility to reproduce, I guess;
https://www.ibm.com/account/reg/no-en/signup?formid=urx-34710

(In reply to deep750 from comment #30)

My bad, restarting the browser fixed the misbehaving.
The problem with giving you access is that the systems are mostly internal. What you can do is create a trial account in the cloud, which will give you possibility to reproduce, I guess;
https://www.ibm.com/account/reg/no-en/signup?formid=urx-34710

I could try, though I'm not sure what the portal and business information stuff is at all... Mike, do we have any contacts at IBM that could help with this somehow?

Flags: needinfo?(miket)

I signed up for a trial account (happy to share creds), but more info on how to reproduce would be super helpful. Me just poking around isn't showing the error.

Also, deep750 could you open devtools and report back what the following returns from the web console? window.inlineContext.configuration["Glass.productVersion"] -- for me I get "11.1 R3". That's the closest thing I could find to a version number (it might not even be relevant...).

It's possible the bug was fixed in the cloud version, but there still be "on premise" installs of older versions that will be affected. :/

Flags: needinfo?(miket) → needinfo?(deep750)
Flags: needinfo?(deep750)

Great you got access. I have access to 11.0.13 and 11.1.3, which is same as you ("11.1 R3") see screenshot.
The error message is slightly different for the latest version, compared to 11.0.13, which I used when reported.
To reproduce, if you click on + and choose report instead of dashboard, as you have done in the screenshot, you'll get an error:

Ah, perfect. I can reproduce the TypeError: _TCG is null https://us3.ca.analytics.ibm.com/bi/pat/halcchl_block.js 1 error now.

STR:

  1. log in to https://myibm.ibm.com/dashboard/
  2. launch the Cognos trial (there's a button that says Launch)
  3. in the bottom left, click the + New button and select Report -- that's when the alert() happens.

In the console I also see: TypeError: _TCG is null. At that particular line:

var _9TK = _TCG.cssRules.length;

_TCG seems to be defined here:

_SHM._RS4 = function (_BPK) {
  this._4SG['hal']['enableAccessibility'] = _BPK;
  var _TCG = _XHM._N0C('idHalBrowserStyles');
  if (_TCG) {
    if (!_C9F._RSL && !_BPK) {
      _TCG.insertRule('*:focus {outline:none;}', _TCG.cssRules.length);
    } else if (_BPK) {
      _TCG.insertRule('*:focus {outline:1px solid #6374AB;}', _TCG.cssRules.length);
      _TCG.insertRule('table[class=\'page\']:focus {border:1px solid #6374AB;}', _TCG.cssRules.length);
      _TCG.insertRule('td[class=\'pageBody\']:focus {border:1px solid #6374AB;}', _TCG.cssRules.length);
      _TCG.insertRule('td[class=\'pageHeader\']:focus {border:1px solid #6374AB;}', _TCG.cssRules.length);
      _TCG.insertRule('td[class=\'pageFooter\']:focus {border:1px solid #6374AB;}', _TCG.cssRules.length);
      _TCG.insertRule('tr[role=\'option\']:focus {border:1px solid #6374AB;}', _TCG.cssRules.length);
      _TCG.insertRule('td[role=\'tab\']:focus {border:1px solid #6374AB;}', _TCG.cssRules.length);
    }
  }
};

_XHM._N0C('idHalBrowserStyles') returns a StyleSheet object:

StyleSheet https://us3.ca.analytics.ibm.com/bi/pat/hal/hal_firefox.css
​cssRules: CSSRuleList(11) [ CSSStyleRule "*, ::before, ::after", CSSStyleRule "IMG", CSSStyleRule ".clsHighContrast [HAL_disabled=\"true\"], .clsHighContrast [HAL_disabled=\"true\"] *", … ]
​disabled: false
​href: "https://us3.ca.analytics.ibm.com/bi/pat/hal/hal_firefox.css"
​media: MediaList []
​ownerNode: <link id="idHalBrowserStyles" rel="stylesheet" type="text/css" href="hal/hal_firefox.css">
​ownerRule: null
​parentStyleSheet: null
​rules: CSSRuleList(11) [ CSSStyleRule "*, ::before, ::after", CSSStyleRule "IMG", CSSStyleRule ".clsHighContrast [HAL_disabled=\"true\"], .clsHighContrast [HAL_disabled=\"true\"] *", … ]
​title: null
​type: "text/css"

I'm gonna PM emilio my credentials if he wants to dig in a bit -- otherwise we could ask someone like :ksenia to help diagnose this one.

I'll take a look when I have some time, though I'll be on PTO until this friday.

:ksenia if you could take a look before that it'd be great (key here is that the behavior of HTMLinkElement.disabled changed as described here: https://github.com/whatwg/html/issues/3840#issuecomment-481034206), but otherwise don't worry, I'll get to it.

Flags: needinfo?(kberezina)
Flags: needinfo?(emilio)
Priority: -- → P2

I was on PTO as well, will take a look later today.

As Mike mentioned the error is happening here:

    _XHM._Z3F = function(_TCG) {
        ...
        var _9TK = _TCG.cssRules.length;
       ...
    }

when TypeError: _TCG is null is happening, it expects to load this stylesheet https://us1.ca.analytics.ibm.com/bi/reportstyles/GlobalReportStyles_11.5.css .

In the template they have:

For Firefox -- <link rel="stylesheet" href="../reportstyles/GlobalReportStyles_11.5.css" id="idDefaultLayout_11.5" disabled="true">
For Chrome -- <link rel="stylesheet" href="../reportstyles/GlobalReportStyles_11.5.css" id="idDefaultLayout_11.5">

So disabled="true" is added for Firefox here:

    _XHM._IIA = function(_E1L, _9KM, _BLI, _JEH) {
        var d = document;
        if (!d.querySelector("link[href='" + _E1L + "']")) {
            var _KHL = d.createElement("LINK");
            ....
            if (_JEH) {
                _KHL.onload = _BLI ? this._QW.bind(this, _KHL, _JEH) : _JEH;
                _KHL.onerror = this._0N3;
            }
            d.getElementsByTagName("HEAD").item(0).appendChild(_KHL);
        }
    }

    _XHM._QW = function(_KHL, _JEH) {
        _KHL.setAttribute("disabled", "true");
        _JEH();
        _KHL.onload = null;
        _KHL.onerror = null;
    }

where _BLI is being set in this function:

    var _BLI = !_C9F._A6I;
    var _9TK = this._4C1.length;
    for (var i = 0; i < _9TK; i++) {
        var _FBK = this._4C1[i];
        _3KI.push(_XHM._2F3("../reportstyles/GlobalReportStyles" + (_FBK ? ("_" + _FBK) : "") + ".css", this._LH3[i], _BLI));
    }

where

var _1OL = navigator.userAgent.toLowerCase();
_C9F._A6I = _1OL.indexOf("webkit") != -1;

So they add a disabled attribute to a stylesheet if the User Agent string does not contain "webkit". It's added to at least 7 stylesheets on that page.

We could perhaps reach out to the site to see if they can fix it? And also can add an UA override.

Flags: needinfo?(kberezina)

Wat, the disabled attribute works historically on WebKit based browsers only, that doesn't make sense, why would anybody do if (browser doesn't implement X) use X();??

Yeah, let's reach out to them I guess, thanks a lot for the analysis Ksenia, it's great :)

If they have any reasoning for using this attribute I'd be curious to know too. Maybe they wanted to use it on WebKit browsers only? IDK

Assignee: emilio → nobody
Status: ASSIGNED → NEW
Component: DOM: CSS Object Model → Desktop
Flags: needinfo?(emilio)
Product: Core → Web Compatibility
Version: 68 Branch → unspecified

Np! I've reached out to the site

Is this a cloud application hosted by IBM? It's unclear based on the original reporter saying:

https://xxxxxx/ibmcognos/bi/

Is the xxxxx an IBM domain or a local domain?

It's unclear, but looks like from the script location https://cgnprd.ventadis.fr/ibmcognos/bi/pat/halcchl_block.js:1:58619 the assets are stored on https://cgnprd.ventadis.fr. So it can be a local domain.

Also when I try to access https://cgnprd.ventadis.fr , it points to https://ventadis.okta-emea.com/app/ventadis_cognos_1/exk1o1ofm39czCyF90i7/sso/saml. It says "Powered by Okta" (https://www.okta.com/), which is a third party provider of Cognos Analytics

So this definitely sounds like something we'll need to fix in Firefox, not rely on IBM.

What is the potential to back https://bugzilla.mozilla.org/show_bug.cgi?id=1281135 out of ESR68?

(In reply to Mike Kaply [:mkaply] from comment #43)

So this definitely sounds like something we'll need to fix in Firefox, not rely on IBM.

What is the potential to back https://bugzilla.mozilla.org/show_bug.cgi?id=1281135 out of ESR68?

It's gated behind a pref: dom.link.disabled_attribute.enabled.

But it's an important compat fix for other sites, so I'd be hesitant of disabling it everywhere.

(In reply to Mike Kaply [:mkaply] from comment #41)

Is this a cloud application hosted by IBM? It's unclear based on the original reporter saying:

https://xxxxxx/ibmcognos/bi/

Is the xxxxx an IBM domain or a local domain?

The bug was reproduced using the solution hosted in IBM cloud. Cognos is also available on premise. The creator of the bug has a on premise solution.
As far as I know, there are no differences in behavior between on premise or IBM hosted

See Also: → 1584647

Looks like the issue has been fixed in the cloud version. Antoine, deep750, Krzysztof, could you please check if it's still reproducible for you?

Flags: needinfo?(kbender)
Flags: needinfo?(deep750)

Hi, how I can test fix/solution?
Do I need to update my firefox version? Or test it against specific Cognos BI URL?

Regards
Krzysztof

Flags: needinfo?(kbender)

Hi Krzysztof. IBM fixed their cloud version, the error is not reproducible there anymore. The url I was testing is: https://us3.ca.analytics.ibm.com/bi/?perspective=authoring&id=1571023914746

If you could try creating a report in you instance of IBM Cognos in Firefox release and see if you get that error still, that would be helpful.

Hi, I will check what version do they have there, and will try to upgrade our local instance to the same release.

Regards
Krzysztof

Thanks Krzysztof! That will be great to know.

We received an update from an IBM contact:

Cognos Analytics 11.1.4 for on-premise was just released on October 15. We were able to put a fix on our side that addresses this particular issue.

So, if anyone is reading this looking for how to fix this particular issue, an update will do the trick. (I have no idea how complex that is to do.)

I can confirm it,
We've just done update to 11.1.4 and issue is fixed.
Regards
Krzysztof Bender

Should we close this now that IBM has fixed the problem?

IBM has fixed this. We are not going to workaround this in Firefox.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
Flags: needinfo?(deep750)
Flags: needinfo?(asouquiere)

Why you close this bug ?

Since the bug is in cognos, and has been fixed in 11.1.4. If you're on 11.0.13, ask IBM for a patch

Excuse me, but the BUG is not in Cognos.
The BUG was result of change in Firefox after release 68.0
Nothing changed on IBM side, it was change in Firefox that caused all the trouble. IBM reacted to that in latest release by re-writing the code to be in line with latest Firefox releases. But please don't write that the BUG was in Cognos. Cognos 11.1.4 works fine. But it is only available to customers paying for ongoing support. It also implements a lot of changes. This is not a PATCH. It's new release of software, upgrading older customer environment to 11.1.4 requires a lot of effort.

Saying "Since the bug is in cognos, and has been fixed in 11.1.4. If you're on 11.0.13, ask IBM for a patch" is like saying "It works fine on new MacBook, ask Apple for free upgrade". It does not fully close the topic in my opinion. Workaround for older releases of software is needed.

(In reply to kbender from comment #57)
Per the analysis in comment 38, the page was doing some UA sniffing that added an attribute we implemented for compat for non-WebKit browsers. So working around this is at best challenging.

Saying "Since the bug is in cognos, and has been fixed in 11.1.4. If you're on 11.0.13, ask IBM for a patch" is like saying "It works fine on new MacBook, ask Apple for free upgrade". It does not fully close the topic in my opinion. Workaround for older releases of software is needed.

Workaround could be setting dom.link.disabled_attribute.enabled=false in about:config, until you're ready to upgrade. It's not clear what else do you want us to do, I don't think we're going to add page-specific quirks for websites doing poor UA sniffing.

You need to log in before you can comment on or make changes to this bug.