Home Dashboard Directory Help
Search

Rendering issue in Internet Explorer 10 by Stephen Deken


Status: 

Closed
 as Not Reproducible Help for as Not Reproducible


Type: Bug
ID: 794791
Opened: 7/23/2013 9:58:05 AM
Access Restriction: Public
0
Workaround(s)
view
1
User(s) can reproduce this bug

Description


I have encountered a rather strange rendering bug in which IE is using the textual content of another element while rendering.

I am using Internet Explorer 10.0.9200.16635 (update versions 10.0.7), I have disabled my addons, and I have reproduced the problem on a second machine. I have also attempted to come up with a minimal reproduction (although it's still not very minimal); I will attach this test case shortly.

The page contains three basic parts: two button elements, a run of inline text, and a series of div elements. The first button contains a span with the word 'WORKING', and the second button contains a span with the word 'BROKEN'. The problem is that the first button is occasionally rendered with the word 'BROKEN'.

The bug is only triggered when the run of text wraps to a second line (but not a third line), and when all of the div elements are visible on the screen. The behavior vanishes if there are more or fewer div elements following (there are currently 42!), or if some of them have more or fewer characters (but it doesn't seem to matter what letter is used; they used to be email addresses). It also disappears if the text run is longer or shorter (although I could get it to recur using certain lengths of lorem ipsum).

As if that wasn't maddening enough, changing the styles in certain ways will also cause the problem to vanish. A border radius of less than 4 pixels on the divs fixes the issue, as does removing the text shadow on the buttons. Even something like removing the relative positioning on the wrapper div fixes the issue.

I've tried to mark up the reproduction case to make it clear what's needed to trigger the problem.

Disabling ClearType fixes the problem (which has the side effect, I believe, of giving the elements a non-fractional width, which may ultimately be the culprit).

If the window loses focus, it redraws correctly. The element also redraws correctly when the mouse is hovered over it.

Mostly at this point I'm just curious as to what's going on under the covers -- the renderer is clearly getting confused at some point and pulling in cached data or whatever. I was hoping to whittle it down to something that I could avoid, but this just seems to make no sense whatsoever -- given the amount needed to reproduce it I'm surprised it ever showed up at all.
Details
Sign in to post a comment.
Posted by MrP19982 on 8/6/2013 at 4:55 AM
Hi,

I can also reproduce this on a PC with nVidia Geforce 9500GT graphics running Windows 8 pro x64, but only in a virtual machine (VMware Workstation 9.0.2) running Windows 7 x64 SP1 with IE 10 (and 3D acceleration enabled in the VM graphics settings).

When I open the HtmlPage2.html in the virtual Windows 7 x64 SP1 machine with IE 10 and resize the windows to 800x600 with F12 tools, then both buttons read "BROKEN".

You can see a screenshot here: http://i42.tinypic.com/1zphd00.png

Maybe I can also record a video that shows the transition between "BROKEN" and "WORKING" on the first button when resizing a video.

So it seems this issue is reproducible, not only with AMD graphics cards, but also with nVidia. However, for mit it only reproduces on a virtual machine, but not on the "real" PC with Windows 8 Pro.
Posted by Microsoft on 8/2/2013 at 6:40 AM
Thank you for your feedback.

We are currently unable to reproduce this issue as described.

We attempted to repro the issue again on Windows 7 IE10-11 and Windows 8 IE10/Windows 8.1 IE11 and we were never able to get the first button to say BROKEN.

We value your feedback. If you have additional information that can help us recreate this issue — such as a specific url, more detailed steps, test results from different machines, or additional conditions — please reactivate the bug or submit a new bug with more details on how to reproduce the issue. You can also read the guidelines at https://connect.microsoft.com/IE/content/content.aspx?ContentID=16254 regarding filing a good bug report.

Best regards,

The Internet Explorer Team
Posted by Stephen Deken on 7/29/2013 at 9:10 AM
In Windows 8 Enterprise x64, running IE 10.0.9200.16384, I'm seeing slightly different behavior -- the first button reads "BROKEN" only if the IE window is sized such that the bug would be reproduced otherwise, but resizing it from there causes the rendering to proceed correctly. Upgrading to IE 10.0.9200.16635 exhibits the same sort of broken behavior in Windows 8 Enterprise x64.
Posted by Stephen Deken on 7/29/2013 at 7:45 AM
Also confirmed in clean install of Windows 7 Professional x86 SP1 and IE 10 in a virtual machine.
Posted by Stephen Deken on 7/26/2013 at 1:48 PM
I was able to recreate the problem with a clean install of Windows 7 Professional x64 SP1 and IE 10 in a virtual machine. I am still downloading Windows 7 Professional x86 to see if the problem exists there as well; I'll let you know if it does.
Posted by Stephen Deken on 7/26/2013 at 8:23 AM
I have updated my video drivers and the problem still persists. I am now running driver version 12.104.0.0, published 3/28/2013, aticfx32.dll version 8.17.10.1191, atidxx23.dll version 8.17.10.0489, and atiuxpag.dll version 8.14.01.6304. I downloaded the drivers from this page on AMD's website:

http://support.amd.com/us/gpudownload/windows/Pages/radeonaiw_win8-64.aspx

I selected the first download option, for Catalyst Software Suite revision 13.4, release date 5/29/2013:

http://www2.ati.com/drivers/13-4_win7_win8_64_dd_ccc_whql.exe

The problem still persists.
Posted by Stephen Deken on 7/26/2013 at 7:29 AM
Also, checking "Use software rendering instead of GPU rendering" solves the problem after restarting Internet Explorer, even using the 32-bit mshtml.dll. That would appear to indicate that there's a problem with my video drivers, but since I've reproduced it on three different machines with different video cards, so I'm not sure how that's possible.

My dev machine has an AMD Radeon HD 6350, with aticfx32.dll version 8.17.10.1107, atidxx32.dll version 8.17.10.0405, and atiuxpag.dll version 8.14.01.6243. I'll upgrade the drivers and see if that fixes the issue.
Posted by Stephen Deken on 7/26/2013 at 7:17 AM
I have reproduced this behavior on three different machines. At least two (possibly all three) machines are 64 bit; two are running Windows 7 Professional SP1, one is running Windows 7 Ultimate SP1.

On these machines, a consistent way to reproduce the issue (which also avoids the correct text being repainted when the window loses focus) is to use the F12 tools to resize the window to 800x600 (as long as the window was not already 800x600).

The problem appears to be somewhere inside mshtml.dll, which makes sense as that's the HTML renderer, but I'm not sure exactly how it gets triggered. Somewhere inside HtmlLayout::LineBox::Draw(...) the wrong text is appended using CTextRenderList::AppendCharacterRun(), but I don't know why.

I'm using mshtml.dll version 10.00.9200.16635 (win8_gdr.130611-1533), loaded from C:\Windows\SysWOW64\mshtml.dll. If I enable Enhanced Protected Mode, so that the 64-bit version of mshtml.dll is loaded from C:\Windows\system32\mshtml.dll (also version 10.00.9200.16635 (win8_gdr.130611-1533)), then the problem does not recur.

So! I still have no idea what's causing the issue, but it appears to be a problem with the 32-bit version of mshtml.dll on a 64-bit version of Windows.
Posted by Microsoft on 7/25/2013 at 7:11 AM
Thank you for your feedback.

We are currently unable to reproduce this issue as described.

We attempted to repro this on IE11, IE10 win8, IE10 win7 and IE 9 but no matter how many times we resized the window the first button always said working. Clear Type was verified as being active as well.

We value your feedback. If you have additional information that can help us recreate this issue — such as a specific url, more detailed steps, test results from different machines, or additional conditions — please reactivate the bug or submit a new bug with more details on how to reproduce the issue. You can also read the guidelines at https://connect.microsoft.com/IE/content/content.aspx?ContentID=16254 regarding filing a good bug report.

Best regards,

The Internet Explorer Team
Sign in to post a workaround.
File Name Submitted By Submitted On File Size  
HtmlPage2.zip 7/23/2013 913 bytes