'JSON' is undefined - SharePoint 2013 - InfoPath 2013 - IE11

Question

We are in the middle of standing up a new SharePoint 2013 Enterprise Server Environment and recreating data from an existing SharePoint 2010 Environment.

Everything was going along well enough but we recently started being forced to use IE11 and so are now having issue. Also, we have no way of not using IE11. As it is being forced down from a higher element and were Government, so you can image how that works, lol.

The issue I need help on is that when a SharePoint Forms Library has an InfoPath Form, the Form is throwing the 'JSON is undefined' error when a People Picker is used after a File has been attached. The People Picker works fine prior to the attachment and this issue does not occur on a Modified SharePoint List (Modified with InfoPath).

Now, the Form works if I hit F12 > Emulation and change User agent string to: Internet Explorer 10. But I have no intention of telling close to 20,000 users that they have to do this when they use one of the 100+ Forms Libraries that my Environment has, lol.

So far I have tried making changes to:

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

I have done this on the Root Site Master Page, the Site Collection Master Page and on the Hive pickerdialog.master and V4.master. Which are located at: \ServerName\c$\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\LAYOUTS

However the issue I have with doing this is that my changes never seem to effect the Forms Library when I open the Form. It seems to be drawing its Header/Body from somewhere else. If I change all of them to be IE=9, the meta in DOM still reads IE=10. So perhaps an InfoPath.xsn is not using one of those Master Pages. So I also exported the Source from the .xsn and looked through that but saw no mention of X-UA or IE.

If I can't find this answer I will most likely try to force URLRedirect in IIS or god forbid make changes to the web.config. I also have read that there is a dramatic difference between IE=10 and IE=EmulateIE10 but can't test any of that until I can manage to make the Forms Library draw the meta I tell it to.

So I'm now officially out of options as provided by google and so need help, lol.

For Reference:

When I navigate to the Forms Library and look at the DOM Explorer, I note that:

head contains: <meta http-equiv="X-UA-Compatible" content="IE=10">

body contains: No Reference to X-UA

While in the Forms Library if I hit New Document to spawn the Form, I note that:

head contains: <meta http-equiv="X-UA-Compatible" content="IE=10">

body contains: <meta http-equiv="X-UA-Compatible" content="IE=8">

After I Attach a File and the Form posts back, I note that:

head contains: <META http-equiv=X-UA-Compatible content=IE=8>

body contains: No Reference to X-UA

So it seems as if the meta tag from the body is being moved to the head after file attachment but I have no idea where that IE=8 is coming from.

Please help

Pretty please, lol

Answer 1

Ok, so I'm fairly certain that the IE=8 is coming from an InfoPath DLL but I found myself extremely short for time and so went ahead an corrected this issue by using the URL-Rewrite Module via IIS.

In truth, this isn't a bad solution because the string I am correcting is most likely only being returned at specific times. But for those that find this question by frantically googling it, like I was doing:

................................................................................

First “Download Web Platform installer” and search for URL-Rewrite Module (add it and install it), open up IIS after the URL Rewrite Module is installed.

Click on the particular IIS site that represents your SharePoint 2013 Web Application, then click on the URL Rewrite button in the Features View.

Click the View Server Variables link from the Actions pane on the right. From here you need to add HTTP_USER_AGENT into the list of Allowed Server Variables by clicking Add in the Actions Pane. When this step is complete, click the Back to Rules button from the Actions pane then press Add Rules(s).

Select Blank rule under the Inbound rules section (the first selection on the top left) and enter/choose the following values:

1. Name

   • This rule can be named anything you wish for it to be named

2. Match URL

   • Requested URL: Matches the Pattern

   • Using: Regular Expressions

   • Pattern: .*

3. Conditions

   • Logical grouping: Match All
   • Click Add Condition and then enter the following data:
     • Condition Input: {HTTP_USER_AGENT}
     • Check if input string: Matches the Pattern
     • Pattern: MSIE\s7.0;
     • (You can test your Patter by using https://regex101.com/)

4. Server Variables Click Add and then enter the following data:

   • Server variable name: HTTP_USER_AGENT

   • Value: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0)

   • Replace the existing value: Checked

5. Action

   • Action Type: None

................................................................................

After following these steps, press Apply in the Actions pane and try editing a page in IE 11 without Compatibility View.

This may also fix a number of the other issues related to IE11's inability to play nicely with SharePoint 2013. But I hadn't run into any of those issues yet and so will never "truly" know if this fixed them or if they were never going to happen in my environment, lol.

As explained before, F12 > Emulation > User Agent String > Internet Explorer 10, will Solve this issue. But if you have a ton of "End Users", asking them to follow those steps every time they want to open a Form, really isn't applicable as a solution.

But, please let me know if this could have been done without the URL-Rewrite Module via IIS. Though I've already spent 3 or 4 weeks worth of paid time for myself, a developer and the server admin. So maybe let's agree to pretend there wasn't an easier solution, lol.

Thanks,