Browser not detecting x-ua-compatible meta tag and setting to new IE browser version after changing it dynamically with javascript

Question

We have a lot of old Infopath forms in an old Sharepoint 2010 website that runs in IE11. They want the site running in IE9 or above so we can run youtube videos. As far as everything other than Infopath forms, IE9-IE11 functions fine for our uses. The problem is that the Infopath forms will not open in any browser other than IE8. I believe it is something to do with the code triggered on the click of Infopath links being written for IE8, and not working in later versions.

I tried writing javascript that checks the page for any .xsn text (all of the links to Infopath files have .xsn in the link text), and if it finds it, it dynamically injects a tag into the to force IE8 Compatibility mode on. This obviously didn't work, as the browser had already read the meta info and ran in default IE11 mode. So, I tried an experiment using localStorage to see if it is at all possible to have javascript write in an x-ua-compatible meta tag before the browser chose its default version of IE11. Basically the code checks the page for .xsn text, and if it finds it, sets a localStorage property to true, then triggers a browser reload. Another piece of code checks localStorage for that property value, and if it is true, renders the x-ua-compatible meta tag into the . The code works as far as getting/setting the localStorage property correctly, and rendering the correct x-ua-compatible meta tag. I check the HTML after page load, and the meta tag is changing to IE compatibility mode on any page that has an Infopath form on it. However, it seems like the browser has already chosen it's version mode prior to that meta tag being written into the .

/**************************************************
    script to insert meta tag to toggle 
    IE versions on the fly if Infopath forms
    have been detected on the page
    **************************************************/

if (localStorage.getItem('XSN-detect') !== null) {


//check localstorage for XSN-detect prop value
//if false, set meta tag to emulate IE11
if (localStorage.getItem('XSN-detect') === 'false') {
    var link = document.createElement('meta');
    link.setAttribute('http-equiv', 'x-ua-compatible');
    link.content = 'IE=11';
    document.getElementsByTagName('head')[0].appendChild(link);
} 

//check localstorage for XSN-detect prop value
//if true, set meta tag to emulate IE8
if (localStorage.getItem('XSN-detect') === 'true') {
    var link = document.createElement('meta');
    link.setAttribute('http-equiv', 'x-ua-compatible');
    link.content = 'IE=EmulateIE8';
    document.getElementsByTagName('head')[0].appendChild(link);

        //alert('This page contains Infopath forms, which requires IE8. Please press ok to have the page reload in IE8 mode.');
    }     
}

$(function() {
    if (localStorage.getItem('XSN-detect') === null && document.getElementsByTagName('BODY')[0].innerHTML.indexOf('.xsn') != -1 || localStorage.getItem('XSN-detect') !== 'true' && document.getElementsByTagName('BODY')[0].innerHTML.indexOf('.xsn') != -1) {
        localStorage.setItem('XSN-detect', 'true');
        window.location.reload();
    }

    if (document.getElementsByTagName('BODY')[0].innerHTML.indexOf('.xsn') == -1) {
        localStorage.setItem('XSN-detect', 'false');
    }
});

I really just need to know if it is possible to dynamically change the x-ua-campatible meta tag and have the IE browser catch it before it chooses its version to load. I don't have access to update the C# or the config, so I am stuck with the front end.

Answer 1

My solution was to utilize the download.aspx?SourceUrl= and dynamically change all of the Infopath URLs on the page to use it. This causes all infopath files on Sharepoint 2010 (not including those with file:// urls) to download, rather than opening via Sharepoint's settings. Users then need to navigate to their downloads folder and open the file from there. The drawback is that users cannot open the form via any "open" commands in a browser. They have to open the file directly from where it downloaded. Considering the fact that Sharepoint2010 is so outdated, and most admins would prefer not to be stuck in IE8 modes any longer, I think it is an acceptable drawback.

$(function() {
    if (document.getElementsByTagName('BODY')[0].innerHTML.indexOf('.xsn') != -1) {        

        $('a[href$=".xsn"]').each(function(index) {
            var self = $(this); 
            var fileLocation = '';  
            var spDownloadsUrl = '/_layouts/download.aspx?SourceUrl=';         

            //GRAB LINK'S HREF LINK PATH AND URI ENCODE IT
            var currentUrl = encodeURI(self.attr('href'));

            //IF THE HREF IS TO A NETWORK FILE LOCATION EXIT THE PROCESS AND LEAVE IT ALONE
            if (currentUrl.indexOf('file:') != -1) {
                return;
            }

            //SHAREPOINT 2010 DOC LIST ELEMENTS HAVE INLINE JS ALTERING THE LINK BEHAVIOR, SO THEY NEED TO BE REMOVED
            self.removeAttr('onclick');
            self.removeAttr('onmousedown');
            self.removeAttr('onfocus');

            //IF THE LINK'S URL IS ABSOLUTE PATH, BUILD IT AS RELATIVE
            if (currentUrl.indexOf('.com') != -1) {  
                var urlSplitOnDotCom = currentUrl.split('.com');              
                var urlAfterDotCom = urlSplitOnDotCom[1];
                var urlPartsArr = urlAfterDotCom.split('/');

                //REBUILD URL FROM ARRAY
                var newPathname = "";
                for (i = 1; i < urlPartsArr.length; i++) {
                  newPathname += "/";
                  newPathname += urlPartsArr[i];
                }                

                fileLocation = newPathname;     

            } else {
                fileLocation = currentUrl;
            }                        

            //ADD NEW URL TO INFOPATH FILE'S HREF ATTRIBUTE
            self.attr('href', spDownloadsUrl + fileLocation);                           
        });        
    }
});