About Record Applet Challenge
Siebel 7 Dual Screen popup
Siebel 8 Dual Screen popup
Conditional Popup based on button click
MVG Popup Challenge
[Another popup challenge]
On the last day before code freeze, the following challenge came through as a critical defect.
The problem in Siebel 8, is that the tab order is ignored on all popup form applets using grid layout (CSSFramePopup).
The tab order still functions correctly in view applets, but on popup form applets, the tab always moves in a sideways fashion, from left to right, no matter how the sequence property is set on the controls.
This may not seem like a huge issue, but for a customer facing staff this can be mission critical. The tab order allows staff to efficiently key in data in a logical sequence, without using the mouse, and if the tab order changes all of a sudden, they have to un-train their old typing habits and adapt to the new behaviour.
This problem was escalated to the Siebel engineers and we were advised that there is no workaround for this behaviour.
This is bad news, especially for customers who have upgraded from 7.8 to find this functionality has been broken.
[Tab Behaviour]
To fix the root cause of this problem, we need to understand how the tab behaviour works.
Is it controlled by class/ActiveX code? or by HTML? or by Javascript/browser script? who knows?
The answer is HTML. The actual solution will lead us to a very obscure part of the application.
When we configure Tab order in Siebel, we need to set the HTML sequence for the control on the applet or use the format menu option. The latter option is disabled in Siebel 8.
When siebel generates the HTML for this control definition, it creates a tag called tabIndex which controls the tab sequence in the browser.
Take a look at the following example, and copy it into a plain text file and run it to see how it works.
<html>
<head>
<title>Controlling TAB Order</title>
</head>
<body>
<SPAN>
<form>
<table border=1><tr><td ><div class=GridBorder>
Field 1 (first tab selection):
<input type="text" name="field1" tabindex=1 /><br />
Field 2 (third tab selection):
<input type="text" name="field2" tabindex=3 /><br />
Field 3 (second tab selection):
<input type="text" name="field3" tabindex=2 /><br> </div></td>
</tr>
</table>
</form>
</SPAN>
</body>
</html>
The problem is, this particular tag, cannot be inspected by looking at the HTML source, or sniffing the HTML, because the HTML source is the pre rendered content, which contains all the HTML code and Javascript commands that your browser interprets on the fly to create the actual content that you see.
The only way to get at this information is to traverse the DOM tree, and spool out the post rendered structure (which is the true representation of what you seen on the screen).
When i spooled out the HTML that Siebel rendered, the controls were missing the tabIndex, and it was also malformed.
No wonder it didnt work!, this tag was correctly rendered for applets in the view frame, but was not for popup applets.
[The challenge]
Our particular requirement for this challenge, was to only fix one applet, there were a few others which were affected, but given where we were, the business accepted this compromise, because there was likely to be a lot of hard coding.
We need some mechanism to control the tabIndex, i could query the repository to get the control sequence, but it wouldn't be easy to grab this information from Browser script and was overkill in every sense of the word, the alternative, was to hard code the tabIndex references to correspond to the HTML sequence of the actual control on the applet. Not very nice, but it was an idea.
[The solution]
An unexpected treasure appeared, when the post rendered Siebel HTML source was analysed, the malformed tag actually contained the HTML sequence, but it was disguised by an empty identifier and was actually hacked to the back of another attribute. It seemed that Siebel did generate the sequence attribute, but chopped off the tabIndex indentifier required for this to work.
So now that we have the most important ingredient (the tab sequence of all the controls), we can modify the HTML to create the tabIndex property and inject our sequence.
Its easy to access a node, and grab its attribute, but its difficult if the attribute dosnt have a name, so how do you reference some thing that has no reference? It took me a while to figure out, but heres how i restored the Siebel Tab order.
Put the following code on applet load:
var oControl = this.FindActiveXControl("Any Control Name");
var oObject = oControl.document.body.getElementsByTagName("object");
for (var i=0; i < oObject.length; i++)
oObject[i].tabIndex = oObject[i][""];
What this does, is grab a hold of any arbitary control to gain access to the DOM. We then use this handle to go to the top of the DOM hierarchy, and grab all the tags for the applet controls, and insert a tabIndex attribute, and assign it the value of the un-named identifier.
The final solution involved no hard coding of the sequence or control arrays, nor did it require a server trip to retrieve this information from the respository. So we ended up fixing all the other applets that the business wanted.
This is only meant to be a stop gap solution, and hopefully Siebel will fix the bug soon. Dont hold your breath, but also dont go crazy and put this on every popup applet in the application. This solution is only designed for HI mode and was tested on 8.1.1.1, a SI fix wasnt applicable, and wasnt explored. (Thanks to KW for help on analysing this problem)
This is brilliant. Thank you for publishing the solution, it was also an issue for 7.8
ReplyDelete