Archive for Internet Explorer

Still using SharePoint 2010? Watch out for polyfills…

Pushing the boundaries of SharePoint is a daily exercise for us here at CorasWorks. When still working in SharePoint 2010 though, all too often, the real limiting factor in designing & building applications is the browser – or more specifically, the Document Mode enforced by the masterpage in SP2010:

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

One way you’ll see some people or companies work around this is by adding polyfills; if you’re unfamiliar with the term, a polyfill is essentially a piece of code or script that ensures (or restores, depending on how you look at it) a piece of functionality the browser should natively support. You can read more about the term here.

A word of caution though; if you add a polyfill into your application, you run the risk of conflicting with the stock SharePoint JS. This is exactly what I observed recently when attempting to use the Modernizr.js and Less.js libraries – they broke the ability to add new web parts to any page. The error I was getting in my browser console pointed to a file named “WPAdder.js” and only stated:

Type mismatch.

My research led me to this blog post by Steve Ottenad, an excellent web designer based (ironically?) in Seattle, WA and not far from the Microsoft campus. His findings confirmed my suspicion and, as soon as the offending JS was removed, I was once again able to add web parts to a page.

One approach I considered, but eventually abandoned in favor of taking a different path altogether, was I could have wrapped my polyfill code inside a script block that only ran if my page was not in Edit Mode. But I didn’t trust SP & IE enough that some other issue wouldn’t crop up in the future.

And lest you think I didn’t consider addressing the “root problem”, there is no shortage of tips, tricks & workarounds for using SharePoint 2010 without the “IE=8″ meta tag – but they involve some pretty heady work around overriding stock SP JS files and modifying key server-side application pages for things like the People Picker. In other words, fodder for a future blog post ;-)

JS Date functions not working in SharePoint with IE…?

Ever run into a problem where you have what you know to be valid javascript, trying to work with a Date object, and yet you keep getting JS errors in the console? If you’re working in SharePoint 2010 or older, blame Microsoft ;-)

Joking aside, even if you’re using the latest version of Internet Explorer, because of the meta tags present in the OOTB masterpages of the older versions of SharePoint, IE will load the page in an older Document Mode; IE8 Standards for SP2010 and Quirks for SP2007. You can always, of course, apply a different masterpage or customize the native ones, however you run the risk of encountering issues elsewhere – for example, remove the “IE8″ meta tag from an SP2010 masterpage (or just setting it to a newer version) causes myriad issues with controls like the People Picker, the RTF field, certain menu options in the Item Context Menu, etc.

If your organization’s timeline for upgrading to SP2013 is a long-term effort, consider allowing/enabling your users to run Firefox or Chrome (Chrome Frame was a nice alternative until it was retired at the end of 2013). I know, not the most ideal answer – but at least you can stop banging your head on your desk wondering why your perfectly valid JS for manipulating Dates keeps throwing errors in IE.

Using IE 11? We Need a Patch!

If you’re running Internet Explorer 11, you may have noticed that your SharePoint environment isn’t responding in the way you have come to expect.  It turns out…wait a moment!  Didn’t we just write this a few months ago?

Last June we wrote an article entitled “Using IE10? You Need This Patch.”  In the article, we told how there are updates for .NET to provide compatibility for SharePoint with the IE10 browser.  It turns out that the browser definition file controlling how the environment interacted with the browser stopped at IE9.

As a result, SharePoint treated the IE10 browser as if it was IE6 and prevented SharePoint (along with CorasWorks v11) from operating in a modern manner.  There were a pair of hot fixes supplied updating .NET to account for newer browser types.  Once the .NET update was installed, SharePoint could supply to the browser the appropriate script files.

This worked well, until IE11 was released within Windows 8.1.  IE11 users are noticing that SharePoint is treating their browser like IE6 again.  For example, multiline text columns are missing their editing toolbar.  As before, the issue again is with SharePoint not recognizing this browser type.  Although the results are the same, the reason for this behavior is different.

With the IE11 release, Microsoft has changed the formatting of the browser’s user agent.  In short, the user agent is used by the web server to determine what type of browser it is working with.  Unfortunately, SharePoint (more specifically .NET 4) cannot understand the changed format of IE11’s user agent and treats the browser as if it was an old browser.  This blog entry has a partial listing of what users are seeing.

In the long run, the updating of the user agent format is a positive step.  In the short term, we appear to be waiting for Microsoft to issue another .NET patch to accommodate IE11.  To work around this limitation, enable compatibility mode for IE11.  Entering into compatibility mode is tougher than in the past, though.  This blog entry from Windows IT Pro explains how to enable it for IE11.

Using IE10 With SharePoint? You Need This Patch!

If you’re running Internet Explorer 10, you may have noticed that your SharePoint environment isn’t responding in the way that you have come to expect.  It turns out, the issue isn’t with your browser!  Instead, the problem is with the server.

In short, because ASP.NET was created before Internet Explorer 10 was expected.  ASP.NET has a file that tracks browser versions in order to know how to respond when the web pages are loaded.  Unfortunately, this file (browser definition file) runs out with Internet Explorer 9.  As a result, your environment doesn’t know how to handle Internet Explorer 10 since it doesn’t recognize it as a modern browser type.

When Internet Explorer 10 hits a SharePoint environment, SharePoint treats the browser as if it is Internet Explorer 6.  This prevents many of the scripts used by SharePoint and CorasWorks from operating correctly.  This is a frustrating condition but one that can be solved.

Microsoft has issued hot fixes for the web servers.  The hot fix that needs to be installed differs depending upon the version of .NET installed on your servers:

The hot fixes perform two specific steps: they update the browser version files for Internet Explorer and Firefox (ie.browser and firefox.browser, respectively) to account for the newer browser versions.  That’s all they do!

CorasWorks is recommending the installation of this update within all of our customer’s environments.  We’re dependent upon SharePoint and it responding correctly to your browser.  As these hot fixes are so specific (updating the browser files), installing them is straightforward and worth the results.

Microsoft has identified ASP.NET to be the source of this problem: http://msdn.microsoft.com/en-us/library/ie/hh869299(v=vs.85).aspx

To learn more, be sure to check out Scott Hanselman’s blog article on this issue: http://www.hanselman.com/blog/BugAndFixASPNETFailsToDetectIE10CausingDoPostBackIsUndefinedJavaScriptErrorOrMaintainFF5ScrollbarPosition.aspx

 

Using JavaScript’s setTimeout() Method


By Michael Bradley, CorasWorks Professional Services Consultant

On a recent engagement I was running into performance issues in the customer’s environment when trying to use JavaScript to update a report client-side for a custom hierarchal KPI report that rolls up worst-case KPIs.  The customer only has Internet Explorer 8 in their environment and I quickly discovered that IE8’s JavaScript engine is notoriously slow as compared to the newer IE9 and IE10.   The problem was that the users would receive a “Stop script” alert every time they would try to apply a filter to the report, which would require a recalculation of the KPI indicators.

While not a complete game stopper since you can simply select “No” and let the script continue running, most users would select “Yes” to stop the script and return to the report.  Of course the report would be incomplete since the recalculation function had not finished its job of updating the report.  Add to this the delays and apparent slow performance of the report and a new strategy needed to be applied to the recalculation function of the report.

At the suggestion of a more seasoned solution architect on my team, I looked at leveraging JavaScript’s setTimeout() method to improve the report’s performance and the overall user experience.   The beauty of adding setTimeout() to my existing report and code was that it only required minor changes.   The first step was to wrap discreet sections of the report in a <tbody> tag.  This allowed me to pass smaller sections of the report to the recalc function instead of passing the entire report.  The next step was to make use of setTimeout() when calling the recalc function.  The syntax in my report’s script looks like this:

var t = setTimeout (recalcFunction(tbodyID),0);

or, more generically:

var id = setTimeout (fn, delay);

What’s going on here is that I am assigning the setTimeout() function to a variable ‘t’, that will store the unique ID for the timer.  Within the setTimeout() function I tell it to run my recalcFunction() with the id of the tbody tag that I want the recalc to update as a parameter and that I want to wait “0” milliseconds before doing so.  Adding this one line of code to the logic of the report after a user applies a filter to narrow the report’s results, greatly improved the performance of the report within IE8 resulting in a “win” for this solution.

Here’s another blog article that provides a more detailed explanation of how JavaScript timers work.

 

IE (7, 8, and 9) Doesn’t Open New Tabs/Windows from Links

The following issue describes a behavior exited by Internet Explorer, versions 7, 8 and 9, that prevents the browser from opening links in new tabs or windows. This issue is NOT caused by CorasWorks software, but since CorasWorks applications are affected by the issue we’ve decided to document it to help our customers.

IMPORTANT: In our testing the issue was caused by a bad installation of Visual Studio; however, it may also be caused by other software installations or updates. The fix described in this article is AS-IS and it is not supported by CorasWorks Corporation.

Symptoms

After installing Visual Studio, browser updates, or applications, Internet Explorer is unable to open links in new tabs or windows. When a new link is clicked where the contents are to open in a new tab or new browser window, the page launches but nothing is displayed.

The following images depict the behavior of the problem.

Cause

The issue appears to be caused by a bad installation of an application or a browser update, which causes browser DLL registrations to become corrupt or invalid.

Resolution

In order to resolve the issue, the corrupt or invalid Internet Explorer DLLs must be re-registered. To re-register the DLLs, follow the steps below. The steps MUST be performed in the order shown below or the fix will not take effect.

  1. 1. Download ie8-rereg.32on64.zip and ie8-rereg.64on64 from Internet Explorer FAQ and save them to disk.
  2. 2. Extract the compressed files into a single directory.
  3. 3. Reboot PC.
  4. 4. Open the command line as an Administrator.
  5. 5. Go into folder with the following files:
    1. a. ie8-rereg.32on64.cmd
    2. b. ie8-rereg.64on64.cmd
  6. 6. Run ie8-rereg.32on64.cmd within command line window. Ensure there are no errors.
  7. 7. Run ie8-rereg.64on64.cmd within command line window. Ensure there are no errors.
  8. 8. Reboot PC.

After implementing the fix, the behavior should be as follows:

We thank Internet Explorer FAQ for the actual fix, as this is simply an implementation of the fix documented by good folks over at Internet Explorer FAQ.

Source: Repair IE8 (IE7) and IE9, http://iefaq.info/index.php?action=artikel&cat=48&id=133&artlang=en.

SharePoint 2010 Browser Compatibility

Microsoft has made efforts to improve multiple browser support and developed SharePoint 2010 more standards friendly.  As such, the expected multi-browser functionality and support has reached levels not seen in previous versions of SharePoint.  Microsoft has classified browser functionality and support for various browsers into three categories, Level 1, Level 2, and Level 3 browsers.  The Level 1 compatible browsers support SharePoint 2010 fully and all functionality is available for use.  The Level 2 compatible browsers on the other hand provide the majority of the functionality with some exceptions.  As far as what these exceptions are, a detailed list of functionality can be found in the following linked TechNet articles: Plan browser support (SharePoint Foundation 2010) and Plan browser support (SharePoint Server 2010).  Finally, Level 3 browsers are the browsers not tested by the Microsoft product team.

In any case, below is the list of Level 1 and Level 2 browsers.  Hopefully the will come in handy when deciding what browser versions to support in your organization.

Level 1 Browsers (Supported)

Internet Explorer 7.x or higher (32bit on Windows platforms)

Firefox 3.x or higher (32bit on Windows platforms)

Level 2 Browsers (Supported with known limitations)

Internet Explorer 7.x or higher (64-bit on Windows platforms)

Firefox 3.x or higher (non-Windows platforms)

Safari 4.x or higher (non-Windows platforms)

As always, CorasWorks has made significant efforts and allocated large amounts of resources to ensure that our solutions provide the same level of browser support Microsoft provides for SharePoint.  Should you have any questions regarding browser compatibility, please post your questions in our Community Forums site or contact Support at support@corasworks.net.