Internet Explorer 11 Issues

The Problem

IE 11 appears to work differently to earlier versions, with respect to return values from Active Accessibility and how it handles badly formed HTML. This was discovered while running in Windows 10, so that could be a factor; either way, some investigation as to the scope of the problem is required.

The Investigation

The htmlgettableaa QA test is the one which first exposed these problems, so I'll be using that as a base to investigate.

I'll be trying IE11 in Win10, IE11 in Win7 and IE<earlier version> to see the difference.

Windows Versions

After a bit of messing around, it appears that the problem is very much IE, rather than the hosting Windows version, so I'll be dropping the IE11 in Win10 aspect of the investigation; gladly, cos it's really really slow.

AA Dimension Changes

The Cell 9.3.1 element in the AA Get Table Test object, used in the above test matches on the values:

Role:        "Cell"
Parent Role: "Table"
Name:        ""
Class Name:  "Internet Explorer_Server"
aY:          29
aX:          3

In IE11, the same cell has the values:

Role:        "Cell"
Parent Role: "Table"
Name:        ""
Class Name:  "Internet Explorer_Server"
aY:          28
aX:          3

The table has the markup:

 <table id="table9" name="nmTable9" description="Table 9">
   <tr>
      <td>9.1.1</td>
      <td></td>
      <td>9.1.3</td>
   </tr>
   <tr></tr> <!-- 9.2 -->
   <tr><td><!-- 9.3.1 --></td></tr>
   <tr>
     <td></td>
     <td>9.4.2</td>
   </tr>
 </table>

Note that 9.3.1 comes after an empty row. The amount of space taken up by that empty row has changed in between earlier versions of IE and IE11. Also note that 9.3.1 has a border rendered around it in IE11 - in earlier versions, that border is missing, even though it is specified in the CSS. This may account for the difference in height and the knock-on effect on later elements that this has.

In IE11, the aHeight of the 9.3.1 element is 4; in earlier IE versions, the height is 2. This may well be due to the border.

The row itself does not appear in the AA model, so I created another to gauge how much extra space is required; in Win7/IE8, the aY of the 9.3.1 element went from 29 to 30. In IE11, it went from 28 to 30.

Invalid HTML Path Changes

This refers to bug 9576, itself dealing with the way that bug 3709 and [[the corresponding bug3709 test]] test is handled. Basically, the way that IE builds the DOM when faced with invalid HTML has changed in IE11. The test contains and uses a path to an element which has mismatched start and end tags - while invalid, the path remained consistent in each rendering of the page up until IE11.

In IE11, the path is:

/HTML/FRAMESET(1)/FRAME(4)/HTML/BODY(1)/DIV(1)/IFRAME(1)/HTML/FRAMESET(1)/FRAMESET(1)/FRAME(2)/HTML/BODY(1)/DIV(2)/TABLE(1)/TBODY(1)/TR(1)/TD(2)/DIV(1)/TABLE(2)/TBODY(1)/TR(1)/TD(3)/TABLE(1)/TBODY(1)/TR(1)/TD(2)/BUTTON(1)

In previous versions, the path is:

/HTML/FRAMESET(1)/FRAME(4)/HTML/BODY(1)/DIV(1)/IFRAME(1)/HTML/FRAMESET(1)/FRAMESET(1)/FRAME(2)/HTML/BODY(1)/DIV(2)/TABLE(1)/TBODY(1)/TR(1)/TD(2)/DIV(1)/TABLE(1)/TBODY(1)/(1)/DIV(1)/CENTER(1)/TABLE(1)/TBODY(1)/TR(1)/TD(3)/TABLE(1)/TBODY(1)/TR(1)/TD(2)/BUTTON(1)

The differences are highlighted in red.

You can set the render mode for Internet Explorer in a number of ways - This technet article has a very thorough flowchart which indicates how the browser determines which mode it should use. In a nutshell, setting the mode to be IE8 changes the building of the DOM to work like it did in IE8, meaning that the path in the above test matches that spied from earlier versions.

I proved this by adding the line:

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

into the file used in the test; with that in place (and a fixed case difference between my hard drive and the test) the test worked correctly. See bug 9576, comment 4 for further details. Note that I haven't committed any changes to the test - it's currently disabled for IE11 and that hasn't changed - I only tested it locally.

Leading and trailing space in inline elements

This refers to bug 9631, specifically what I describe in bug 9631, comment 1.

In the Get Table action, we collapse the subelements of a cell into a line of text - so, the AA Name property for each of the subelements returns the text á la:

• "This is "
• "not"
• " a cell. "
• "Oh, but it is."

In IE11, the same property returns:

• "This is"
• "not"
• "a cell."
• "Oh, but it is."

When we append the elements' text data together, in earlier IE versions we get:

"This is not a cell. Oh, but it is."

..whereas in IE11, we get:

"This isnota cell.Oh, but it is."

I tried a couple of fixes to this in the code.

First, in the above example, the Name property of the cell itself holds the combined (correct) text for the cell, so I tried just using that instead of accumulating the inner text manually. Unfortunately, a later cell in the same test failed because the cell's property was blank, even though it contained elements in it. That was the cell containing:

<a href="#">11.1</a>.1

Second, I considered adding whitespace ourselves, but we have no way of knowing if there should be a space character there or not - in the above example "This is " should have trailing, but not leading whitespace. "not" should have no whitespace. " a cell. " should have both leading and trailing... ultimately, without the context we cannot know whether a space should be there or not.

Ultimately, I think this is a bug in Internet Explorer - it should not be trimming the element's text data when it returns it in AA, and there's little we can do about it in the code.

However, as in the path changes above, if you set the render mode to IE8, this works as it is supposed to - ie. returning the leading or trailing space character in text within inline elements.

Conclusion

There are a number of things at play here:

1. The width and height of some elements has changed between earlier IE versions and IE11. In the specific example above, empty table rows or cells are rendered with different heights than previously which can change the elements themselves and also any subsequent elements in the model - ie. there is a knock on effect. The two suggestions for how to deal with this are:

   • not to use specific locations or sizes to match elements
   • to respy the elements when upgrading to IE11.

   Note that changing the render mode has no effect on this issue.

2. The handling of invalid HTML has changed in IE11. To mitigate this, either:

   • respy the element in IE11 and use the new path derived from there, or
   • change the render mode to IE8 - either in the browser, in the source application (if such an option is available)

3. The handling of leading and trailing space has changed.

   • The only way to fix this (using AA) is to change the render mode to IE8 - respying has no effect, and there is no code change available to fix it in the product.
   • Note that the HTML version of Get Table works correctly, so that may be another option