PeopleSoft Test Framework and IE9 issues

We ran into problems with PTF in that tests we had created earlier this year wouldn’t work.  Worse, the errors were inconsistent – first it would refuse to enter the current login information; it would throw errors after opening up the browser; PTF would just hang when at a search screen and wait instead of entering information from the script.  Our company had done an upgrade to IE9 from IE 8 a few months back; it looked once again as if IE9 was the culprit.

Our tools level is 8.51.1.  Doing a web search returned some hits – mostly of the ‘IE9 is not compatible with PTF’ variety.  So yes that sort of validated our hunch, but didn’t really supply a direction to go.

Searching in the Oracle Knowledge Base was frankly a waste of time.  Then we started looking into PeopleTools patches – and found there have been patches to PTF since our release.  In point of fact the patch for 8.51.14 had this bug mentioned as fixed – 12912401 PTF – Synch Issues with IE9.

We looked up the bug and found the text of the reported bug:

Hdr: 12912401 N/A TFRM 8.51 PRODID-5085 PORTID-289
*** 08/24/11 08:25 am *** 
Can not recognize innerText=QAS_TST_MSGSETS in IE9(PTF 852 902R1) 
 PTF throw error in log as object not found or access denied when executing in IE9.  The same test ran successfully in IE8
1.Execute process_run at IE9 and got unstable issue(each time got different issue)
2.Uninstall IE9 and reinstall IE8
3.Reexecute process_run at IE8 the script executed fine

Not wanting to do a complete PeopleTools patch to the system we tried the following:

  • Uninstalled PTF from the client machine.
  • Downloaded the 8.51.20 patch, and ran the setup in a client PC.
  • Navigated to the newly created PT8.51.20\setup\PSTestFramework folder.
  • Ran the setup.exe program.

That’s all it took.  The patched 8.51.20 version of PTF works with IE9; the few tests we had created with the earlier version using IE8 now run to success.

The PTF Signon screen displays PeopleTools 8.51.20, but it works fine with our current 8.51.10 Integration Broker setup and Oracle database.


IE 9 and more PeopleSoft issues – white space???

How about another PeopleSoft and IE 9 story?  Gather round!

We (my company – for the rest of the story will be known as we) recently upgraded to PeopleTools 8.51.10 – our application level is 9.0.  We are a PeopleSoft HRMS shop, and use PeopleSoft Portal for our self-service customers.

So, shortly after our tools upgrade a corporate decision was made to upgrade our browser to IE 9.  Our usual in-house computer has MS Windows 7 (soon to be upgraded to SP1) with the browser standardized as Internet Explorer – currently version 8.

While we had been using PS Portal for a while the presentation was getting – well – dated is a nice way of putting it.  Our portal got amped up – a lot.  So when we took a look at our freshly delivered portal in IE 9 we noticed white space in areas that decidedly should not be white.

In essence bands of white space were being rendered in the header.  Not always tho, only when a user was clicking thru to a lower level of navigation.


White spaces appear in IE9 only – which seems to be caused by the tags (or dir=”ltr” in general) within the HTML. These are found throughout PeopleTools.

Unfortunately – Oracle plans a final fix in Tools 8.53 – and there is no plan on back porting to earlier versions.

So, noticing that the white spaces only appeared some of the time I started looking into the code.  I found that we had an HTML template that was not used at the top most page level – but was fired once a user started drilling down.  The template started with a boilerplate declaration:


<html dir=”%Direction” lang=”%LanguageISO”>

The html root level element in the template had a dir attribute.  It seems that when PeopleTools renders a page using a template, and the template has a dir attribute in the html root level element – that gets used when span tags are generated.  So in our case span tags were getting generated as ….  In an IE 9 browser that line would get rendered as a white space.

My solution was simple – since this was only happening in the page header, I removed the dir attribute.  The second line now reads: <html lang=”%LanguageISO”>.  When the page gets rendered by PeopleTools the span tags no longer had a dir attribute; and white space was no longer being created in IE 9.

I would guess that in those situations where you needed the dir attribute then the next step would be to try inline formatting – but for now I’m not in that situation.

PeopleSoft Signin and IE 9 Not Supported Error

We very recently upgraded to PeopleTools 8.51.10; and using Portal 9.0.

The company is using Windows 7 with IE 8 as the standard, and will be rolling out IE 9 first quarter of next year.

Trolling in My Oracle Support there have been a number of issues reported – and then we found this one logging into a testing instance:

PIA Signin w/IE 9

The fix at first seemed easy – compatibility mode for intrasites was turned on.  Turning it off removes the browser version isn’t supported error.

Except we found that corporate standards will require compatibility mode for intranets will be turned on.

I got directed to this link with MSDN explaining how to define document compatibility.  Based on suggestions from MSDN I added the new HTML5 tag:

<!DOCTYPE html dir= lang=>

to the page, as well as this meta tag:

<!– Enable IE9 Standards mode –>
<meta http-equiv=”X-UA-Compatible” content=”IE=edge” >

Then I bounced the Portal web servers.

Didn’t stop the error from showing up.  Seems the problem is that compatibility mode forces the browser to behave a couple of revisions back – causing it to behave as if it’s version was below IE 8.0.

Okay, so then I changed the broswer.xml file by going looking for the name element Windows NT 6.1, description Windows 7.  I set the browser_min to 7.0.  Bounced the web servers again.

Still no luck.  The warning still showed up on the page.  Okay, time to inspect the HTML more carefully.

There is a bit of code that brings in this value  – %=browserCheck% – clearly the text advising that the browser version not getting supported is coming from PeopleCode.  So some JavaScript got added:

function getInternetExplorerVersion(){

var rv = -1; // Return value assumes failure.

if (navigator.appName == ‘Microsoft Internet Explorer’){

var ua = navigator.userAgent;

var re = new RegExp(“MSIE ([0-9]{1,}[\.0-9]{0,})”);

if (re.exec(ua) != null)

rv = parseFloat(RegExp.$1);


return rv; }

And I added this to the already existing function setErrorImg():

if (discovery_error.length != 0)

if ver < 8
document.getElementById(‘discovery_error’).style.visibility = ‘visible’;
document.getElementById(‘browsercheck_error’).style.visibility = ‘visible’;
document.getElementById(‘discovery_error’).style.visibility = ‘hidden’;
document.getElementById(‘browsercheck_error’).style.visibility = ‘hidden’;

Finally success – it seems by having all the above the browser version error goes away.  I’ve played with removing the HTML5 tag and the meta tag – it reverts back and displays the error.

A call has been made to Oracle on this issue – clearly the PeopleCode is getting confused about what the actual version of the browser is when IE 9 has been set to compatibility mode.

%d bloggers like this: