Issues with Console Dashboards and Internet Explorer versions - wizards.js IE11 incompatibility

Customizations
1

wizards.js that is loaded into all dashboards by the console has issues with IE11 engine when enabled, but not the IE9 engine. I’m not sure what the exact issue is, but ideally it would be solved to allow it to work with IE11.

Despite the fact that IE11 is installed, the BigFix console uses IE7 compatibility view for all Wizards and Dashboards by default. This seems to be the case to keep old and outdated dashboards working that would otherwise need revamped to work with newer IE versions.

Creating new dashboards today in IE7 compatibility view is quite painful as it isn’t standards compliant and you can’t just look up how to do something, you have to look up how to do it in IE7 for any edge cases you encounter. It also means that you are limited on which JavaScript libraries you use within the Dashboard. IE7 is limited to JQuery 1.12.4 which isn’t exactly state of the art given that the current version is JQuery 3.1.1.

It is possible to get JQuery 3.1.1 to work within a Dashboard by enabling IE10 mode, using the following: <Head><![CDATA[<meta http-equiv="X-UA-Compatible" content="IE=10">]]></Head>. This works by switching IE11 from IE7 mode into IE10 mode and JQuery 3.1.1 supports IE9 or later.

This doesn’t solve the problem if a javascript library requires IE11. Adding this should work: <Head><![CDATA[<meta http-equiv="X-UA-Compatible" content="IE=11">]]></Head>, which does update the documentmode but it causes wizard.js to throw an error:

The other reason that I’d REALLY like to use IE11 standards mode for writing Dashboards is that it should work approximately the same as Chrome or Firefox. This means JavaScript/HTML should work approximately the same within a Dashboard as it does in any browser, including in WebReports custom reports, and the WebUI. Without IE11 standards mode, that will not be the case and there will always be edge cases that have to be accounted for, much more so than there would otherwise be. CC: @dexdexdex

Another thing that really caused me a lot of trouble while trying to figure this out is that no matter what I did to change the IE mode, the user agent never seemed to change from that of IE7, even though I’m fairly certain it should have.

Source: bigfix-content/dashboards/JavascriptDebugging.ojo at main · jgstew/bigfix-content · GitHub

All of my public dashboards: bigfix-content/dashboards at main · jgstew/bigfix-content · GitHub

Related:

1 Like
2

Actually, it seems like even though wizards.js doesn’t complain on load when a Dashboard is rendered in IE10 mode, it will throw an error as soon as something within wizards.js is invoked. It seems like IE9 mode works just fine.

This means that wizards.js still has IE11 compatibility issues, but it seems to also have IE10 documentmode issues.

I attempted a little bit of debugging and analysis of wizards.js to try to find obvious problems, but I didn’t find any. Ideally I’d take the time to do more digging.

3

Note on support of JQueryUI & IE9: https://blog.jqueryui.com/2016/04/jquery-ui-1-12-0-release-candidate-2/

Reduced old IE support: jQuery UI 1.11 officially dropped support for IE7 but left all the existing workarounds in place. jQuery UI 1.12 has removed all of the IE7 workarounds. In addition, official support for IE8, IE9, and IE10 have been removed, but the workarounds are still in place and will be removed in 1.13

Another consequence of lack of IE11 compatibility is the requirement to dig deep to find browser compatibility for every library.

4

I actually tried including a script that would load first that would define all of the functions within wizard.js as noop to see if that would prevent it from causing problems on load, but it did not, which makes sense if it is last one wins.

https://github.com/jgstew/tools/blob/master/JS/wizardsnoop.js

5

Not sure why it took me so long to figure this obvious way to prevent wizard.js from loading:

<BES>
  <Wizard>
    <Title>Custom - Javascript Debugging</Title>
    <UIHooks LaunchType="Document" RequiresAuthoring="false" Menu="Dashboards"></UIHooks>
    <DefaultPage>JavascriptDebugging</DefaultPage>
    <Page Name="JavascriptDebugging" DocType="HTML5" >
        <Title>Javascript Debugging</Title>
        <Head><![CDATA[
            <meta http-equiv="X-UA-Compatible" content="IE=11">
            <script src="C:\Program Files (x86)\BigFix Enterprise\BES Console\reference\common.js"></script>
            <noscript>
        ]]></Head>
        <HTML><![CDATA[
</noscript>
<h1>IE DocumentMode:</h1>

This wraps wizard.js in a <noscript> tag to prevent it from being loaded. This allows IE11 mode in the console without throwing the error that wizard.js causes.

This is NOT a solution to the wizard.js incompatibility, but it does allow a dashboard to exist in the console in IE11 mode without the functionality of wizard.js, which is useful for debugging why wizard.js doesn’t load properly from there by making a modified version.

I’m loading common.js before the <noscript> tag because otherwise it would also be excluded.

6

Well, I’m pretty sure I already identified the problem on line 63 of wizard.js:

window.attachEvent("onload", InsertUtilityDiv);

If I comment out this line, then it prevents the script error.

From here: https://msdn.microsoft.com/en-us/library/ms536343(v=vs.85).aspx

[attachEvent is no longer supported. Starting with Internet Explorer 11, use addEventListener. For info, see Compatibility changes.]

From here: https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/attachEvent

This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user.

This is a proprietary Microsoft Internet Explorer alternative to the standard EventTarget.addEventListener() method.

This should be the alternative that works with IE9+ :

window.addEventListener("load", InsertUtilityDiv);

I was able to confirm that the InsertUtilityDiv function does fire when using the new window.addEventListener method in IE11 mode by adding an alert inside the function.

TODO:

This should be the code needed to handle all browser versions:

(function () {
    // IE9+ and other browsers
    if(window.addEventListener){ 
        window.addEventListener('load', InsertUtilityDiv);
    } else {
        // IE8 or earlier Fix
        window.attachEvent("onload", InsertUtilityDiv);
    }
})();

I tested it in all of IE11 modes… IE7 through IE11 and it did run InsertUtilityDiv as expected. The code above was based upon this: http://stackoverflow.com/a/21191249/861745

2 Likes
7

Seems like it might be possible to do some error handling of javascript being loaded in the console by using window.onerror which may be a way to try to handle both this issue and others, as well as provide much better error messages than the BigFix console normally provides.

This isn’t ideal, but the following will suppress all errors, including the error of wizards.js in IE11 mode:

<Head><![CDATA[
    <meta http-equiv="X-UA-Compatible" content="IE=11">
    <script>window.onerror = function(e){ return true; }</script>
]]></Head>

The problem with this option is that it will also prevent more helpful errors that you DO actually want to see for debugging & reporting purposes. Something more sophisticated is needed to trap only issues with wizards.js

This will catch only errors thrown by wizards.js :

<Head><![CDATA[
    <meta http-equiv="X-UA-Compatible" content="IE=11">
    <script>window.onerror = function(event, source, lineno, colno, error){ if( -1 != source.toString().indexOf("/wizards.js") && 0 == lineno && 0 == colno) { return true; } };</script>
]]></Head>

This should be exactly what I need to get a dashboard to bypass the wizards.js IE11 compatibility issue, which is excellent! This will mean that the hidden DIV that wizards.js creates will not be available in the dashboard unless it is subsequently created because wizards.js will not have done it automatically since it is what is causing this error. It is easy to call the function that creates the hidden DIV as the first thing that runs within the Dashboard itself.

1 Like
8

Thanks for all the digging here, jg! We’ve already filed a defect on this internally and expect to deliver a fix in the next 9.5 patch, so you don’t need to worry about opening an RFE. :slight_smile:

1 Like
9

Very glad to hear it!

I’m glad to have found a good option to deal with this error for the existing codebase so that I can publish a dashboard that uses IE11 mode and have it work in older versions of BigFix since it will inevitably take awhile for everyone to get caught up.

10

I just figured out that C:\Program Files (x86)\BigFix Enterprise\BES Console\Reference\common.js has an issue with the expand / collapse sections code with IE11 mode. It works in IE7 or IE8 mode but not IE9 or above. I haven’t been able to figure out anything in particular that is causing the issue. I’m guessing the issue is within the function ToggleSectionVisibilityOfImage( el, scroll ) function somewhere.

Actually, it seems like the issue is here: ToggleSectionVisibilityOfImage( window.event.srcElement, true );

It seems that window.event is non standard and so is srcElement, both of which are likely causing issues in IE9+

I have to say, mozilla has really excellent documentation.

11

Bigfix dev team has addressed the wizards.js issues you stated. If you have any known dashboard file(s) that would cause the error in IE11, we would like to run it by our fix. I did download the ojo files form here: https://github.com/jgstew/bigfix-content/tree/master/dashboards. But they all loaded fine before and after the fix.

1 Like
12

The reason they work fine is that I added a patch to them to prevent the problem from happening.

Adding this to any dashboard before the fix should cause the problem:

<meta http-equiv="X-UA-Compatible" content="IE=11">

But the following line prevents the error:

<script>window.onerror = function(event, source, lineno, colno, error){ if( -1 != source.toString().indexOf("/wizards.js") && 0 == lineno && 0 == colno) { return true; } };</script>

If you take this out, it should cause the error.

13

I uploaded a dashboard that will cause the error: https://github.com/jgstew/bigfix-content/blob/master/dashboards/JavascriptDebuggingIE11error.ojo

14

Jg, thanks a lot for uploaded dashboard. It really helps testing the fix!

1 Like
15

You are welcome. Let me know if it works.

I’d also be curious if you find any major issues in older versions of IE, in particular due to use of:
<meta http-equiv="X-UA-Compatible" content="IE=11">