Posts Tagged ‘Internet Explorer’

WebCenter Interaction and Internet Explorer 11

Tuesday, April 7th, 2015

In our last post, we hacked support for IE11 into Collaboration Server. Today, we’ll look at a small tweak to fix some UI issues with Internet Explorer 11, because, you know, technically Oracle WebCenter Interaction only supports up to IE9 (forget about Chrome!):

Microsoft Internet Explorer 6.0, 6.0 SP1, 6.0 SP2 (on XP), 7.0 (on Vista), 7.0 SP2 (on XP SP2), or 8.0

Internet Explorer has followed a long tradition of screwing up web sites by changing the way it renders pages, and IE11 is no exception. For example, one of the sites I manage started rendering a squished navigation bar in IE11:

Rather than trying to hack code or anything, we’re left with a pretty good solution: force IE to use its old IE9 rendering engine. You do this by adding an HTTP response header to your portal pages:

X-UA-Compatible: IE=EmulateIE9


Using Collaboration Server with Internet Explorer 11

Friday, April 3rd, 2015

Webcenter Collaboration 10gR4 was released in May 2013. Internet Explorer 11 was officially released in October/November of that year. Why is this a problem? Because, since Oracle has killed the entire product line, users are left high and dry with compatibility issues, getting a degraded version of Collab Explorer that’s missing key features like Bulk Upload:

Why is this? Because the abomination known as Internet Explorer threw developers yet another curveball in IE11: they changed the user agent string to one that doesn’t contain the characters “MSIE”. Sure, Oracle can be faulted for not following best practices on browser detection, but we’ve thrown enough angst Oracle’s way in this blog; it’s Microsoft’s turn today. I mean, they’ve used MSIE in their user agent strings for literally TWENTY YEARS; of course they should change it now to:

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; AS; rv:11.0) like Gecko

The solution is yet another Collab Hack requiring you to decompile code. Specifically, in collab-core.jar, we need to update There are two places in the code that need to be updated; you’ll note I didn’t even attempt to implement a generic solution, but am specifically looking for this IE11 user agent string. That, of course, is not completely future-proofed, but since WCI is basically dead, and IE is getting killed off, I’m not too worried. The updated code will look something like this:

    private static float parseVersion(HttpServletRequest request, String searchPattern)
        String userAgent;
        userAgent = request.getHeader("User-Agent");

	if(InStr(request.getHeader("User-Agent"), "rv:11.0"))
		return 11.0F;

… and:

    public static String GetBrowser(HttpServletRequest request)
        if(InStr(request.getHeader("User-Agent"), "MSIE"))
            return "IE";
        else {
	        if(InStr(request.getHeader("User-Agent"), "rv:11.0"))
				return "IE";
	            return "NS";


Use File:New Session to log in with another account

Thursday, May 24th, 2012

Here’s the situation: you’re a system admin logged in as administrator, but you need to see what the user interface of your portal looks like as a guest or other user. As you know, sessions are stored on the server, and web requests from your browser send a cookie to map to that session. If you use CTRL-N to open a new browser window, those cookies still get sent to the server, and you’re still logged in with that account.

But, in IE if you go to File: New Session, a new browser window will open, and the cookies will be cleared and maintained separately.

Boom – 2 browsers, 2 sessions:

Display an “Unsupported Browser” warning in Confluence 3.4

Wednesday, November 9th, 2011

As we continue to prepare for a Post-WCI world, you’ll see this blog starting to highlight other best-of-breed products and challenges we’ve overcome with them. Today’s post is related to the fact that Atlassian’s Confluence doesn’t support Internet Explorer 9 (in version 3.4), and how we addressed it with our client.

In analyzing our logs, fewer than 5% of our roughly 5,000 users were actually using IE9. And in our testing, most of the site worked with IE9, so we didn’t want to prevent these users from accessing the majority of the site. Finally, we didn’t want to send an email or put a message on the site that didn’t apply to the other 95% of users. The solution? A piece of Javascript in the header that would display a warning to only those users accessing the site with IE9: