WebBrowser control invalid z-index rendering for <select> tag

0
votes

I have a WebBrowser control that loads web-page, targeted IE 9+. The problem is that this page is displayed normally in IE 9, 10, latest Firefox and Chrome, but when displaying in WebBrowser control, something goes wrong and drop-down appears over the calendar:

enter image description here

z-index of calendar is 1, for tag it is not set (I also tried setting 0 explicitly - same result).

Page contains meta tag:

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

so I excluded possibility of wrong compatibility mode of IE. In addition "Save" and "Close" buttons looks OK, so it is at least IE 9 mode (they look worse in IE 8 and 7).

Does anybody have an idea why the layout can be different in normal IE browser and WebBrowser control?

UPDATE: Issue only reproducing when the windows form with WebBrowser control is shown as a plugin of MS Word (2010). The same form, when run as a standalone application, is displayed as expected.

1
c#.netwinformsinternet-explorerwebbrowser-control
webbrowser control is stuck in IE 7 rendering mode by default you need to add a registrykey like in this article explains - weblog.west-wind.com/posts/2011/May/21/… - terrybozzio
@terrybozzio, that doesn't help unfortunately. If browser mode was IE7, it wouldn't display Save button in blue color. - Sasha
Check DOM document.documentMode and document.compatMode. They should be something like these: document.documentMode: 9, document.compatMode: CSS1Compat, if FEATURE_BROWSER_EMULATION works correctly. - noseratio
@Noseratio, yes, it works as you described. Displays documentMode=9 and compatMode=CSS1Compat. It looks like the problem isn't in CSS or compatibility. It is the problem of just drop-down list. It always appears on top. I've read that it is implemented as separate window in IE, so it differs from all other controls. But I have no idea why it looks different in standalone browser and in the WebBrowser control. - Sasha
@OleksandrPshenychnyy, there's a bunch of other features. E.g., try FEATURE_GPU_RENDERING. - noseratio

1 Answers

1
votes

The issue appeared to be in the feature called 'FEATURE_USE_WINDOWEDSELECTCONTROL' (registry node 'HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_USE_WINDOWEDSELECTCONTROL'). It was enabled for WinWord.exe by default. Removing registry value 'WinWord.exe' fixed the problem.

I suppose it is a direct answer to the original question. But I'm not sure it is safe to remove this node from registry and how it can affect other applications and MS Word functionality.

It is said that non-windowed select control came to substitute the older (IE6-style) windowed control, but it had compatibility issues in IE7 with MS Office 2003 applications, so the registry setting 'FEATURE_USE_WINDOWEDSELECTCONTROL' was introduced to enable reverting this change. I didn't find any confirmation that that issues are not present in newer versions of MS Word, but from what I've found about possible issues and tested that - they are not reproduced (crashes when using select control with keyboard).

It is likely that I'll accept this solution and remove the setting FEATURE_USE_WINDOWEDSELECTCONTROL for MS Word 2010. If anybody knows the reason not to do this, please let me know.