locked
Project Spartan and the WebBrowser control RRS feed

  • Question

  • I'm a C# WinForms developer working in Visual Studio 2010 and I use the WebBrowser control in my desktop applications for users to view web content through the desktop app.

    I have 2-questions related to the upcoming Project Spartan browser, which is supposed to replace IE as the browser.

    1. Will the Spartan browser (or whatever its final name will be) continue to support the WebBrowser control in the toolbox? The control currently utilizes the functionality of the user's existing IE browser. If IE continues to be present on new Windows 10 desktop systems along with Spartan, then it probably won't be an issue.

    One issue the Web Browser Control on Windows has, is that it’s perpetually stuck in IE 7 rendering mode by default. This is can be seen in articles like (see the section entitled Browser Emulation) or

    Web Browser Control – Specifying the IE Version

    or WebBrowser ActiveX Control – Google Maps Invalid Character Scripting Error

    This requires a registry setting to set its emulation mode. Making the setting in the registry works. However, I would like to "Future-Proof" my application to account for any changes to the user's browser and Project Spartan certainly could prove to be a game changer if it won't support this development control.

         2. Therefore, I would also like to know how Project Spartan will address browser emulation modes.

    Thanks

    Saturday, March 21, 2015 9:18 PM

Answers

  • The webbrowser class in Windows Forms and WPF are based on Trident. It is unclear what designer you are in, as the toolbox contents are designer-dependent. If you are using the Windows Forms designer, then what you are seeing is the webbrowser class in Windows Forms. 

    I did not imply Microsoft would introduce another control. In fact I said the opposite. Microsoft is unlikely to provide you a way for you to use the new engine, given their attitude on browser hosting. 



    Visual C++ MVP

    • Marked as answer by Fred Bao Friday, April 17, 2015 7:00 AM
    Sunday, March 22, 2015 3:01 PM

All replies

  • Both IE 12 and Spartan are going to be based on both Trident and EdgeHTML. So the Trident-based WebBrowser class will continue to work. 

    EdgeHTML is being developed with hosting in mind (IE 12 is a supported host) however it is unlikely Microsoft will provide hosting API to third party as hosting and reuse are part of legacy technology in IE SDK documentation now. 



    Visual C++ MVP

    Sunday, March 22, 2015 12:53 AM
  • Hello Sheng and thanks for your reply.

    In your comments you stated that "the Trident-based WebBrowser class will continue to work." However, is the existing WebBrowser control in my .Net Framework 4.0 Visual Studio 2010 toolbox, based on the "Trident WebBrowser class"?

    That is my primary concern, as my applications, which use the browser control, utilize IE's functionality. If IE12 and Spartan will use a different rendering engine, then I have to wonder if applications making use of the .Net 4.0 WebBrowser control will break.

    Do your comments of both IE 12 and Spartan being based on Trident and EdgeHTML, imply that Microsoft will introduce a different browser toolbox control, or will there continue to be backwards compatibility for the existing browser control? Thank you again for your insight.

    Sunday, March 22, 2015 2:36 PM
  • The webbrowser class in Windows Forms and WPF are based on Trident. It is unclear what designer you are in, as the toolbox contents are designer-dependent. If you are using the Windows Forms designer, then what you are seeing is the webbrowser class in Windows Forms. 

    I did not imply Microsoft would introduce another control. In fact I said the opposite. Microsoft is unlikely to provide you a way for you to use the new engine, given their attitude on browser hosting. 



    Visual C++ MVP

    • Marked as answer by Fred Bao Friday, April 17, 2015 7:00 AM
    Sunday, March 22, 2015 3:01 PM
  • Hello Sheng and thanks for your explanation.

    I guess I will continue to use the existing C# .Net 4.0 WebBrowser control until such time as Microsoft effectively breaks that functionality in my application; at which time I will be forced into implementing a 3rd party browser tool.

    If they haven't thought about supporting existing functionality of their controls, then I'm sure I won't be alone in looking outside MS for controls that will continue working.

    Thanks again. :-(

    Monday, March 23, 2015 9:06 PM
  • I completely agree. We have thousands of customers using our software that relies on the WebBrowser control, and requires users to have IE installed. If MS insists on completely ignoring 3rd party developers, I'm sure this will be the end of IE or Spartan or whatever they like to call it.

    I guess there is no other option than switching to xulrunner or CEF. At least it'll make it easier to ditch Windows and support Linux and Mac. Just such a shame considering the amount of effort we have put into Windows development.

    Thursday, April 23, 2015 12:18 PM
  • About two years ago I found my MSHTML apps broke on https sites and I shifted to using the Awesomium webkit wrapper.

    Scripting sites from externally from c# and such is important for many applications for sites that don't provide native APIs. Microsoft should see such functionality as part of support apps on the PC that reach out rather than just the web as a publishing medium.


    Thursday, April 23, 2015 9:39 PM
  • Hello Bob. I'm with you on this one. The MS WebBrowser control worked (Ok) but required registry hacks for its rendering.

    Therefore, I too have moved to using an Awesomium browser v1.7.5.0 in my C# WinForms Apps.

    The up-side to this is that it is blazingly fast and won't be affected by what browser the end user is using, or has had upgraded.

    Nevertheless, it is a shame that the visual studio toolbox controls supplied by MS don't keep pace with their other developments.

    Thursday, April 23, 2015 10:11 PM
  • Agreed. It looks like another case of Microsoft assuming how everyone should do things, rather than helping to support flexible approaches that fit real problems.

    We have critical apps that utilize the WebBrowser control for kiosks and production use where we need to be able to lock the browser down to just the required functionality. No freeform URL entry, no spawned windows, etc...

    I guess I'll be looking at Awesomium or something along those lines.

    Monday, May 11, 2015 2:27 PM
  • I am most worried with this trend, since Microsoft Edge new rendering engine will likely liberate webdesigners from worrying about IE compatibility. Right now there are already several websites that state mandatory use of Mozilla Firefox/Google Chrome and won't work under IE7 standards (that is, default .NET WebBrowser control standards). I foresee this will be a general rule a year ahead from now.

    If Microsoft refuses to update .NET WebBrowser control, or supply a new one which targets directly to MS Edge's engine and capabilities, it will render obsolete or even unusable a massive amount of effort  invested by those developers that are still faithful to .NET languages.

    I would like to know this for sure: there will be actually no managed. NET or unmanaged COM access to Microsoft Edge Browser whatsoever?

    If the answer is "No, there won't be", then MS is forcing developers to use third party components (like Awesomium mentioned by some in this very thread), which is just one step less than relinquishing the whole .NET standard in favor of other languages and platforms.

    I've read that WebView component (available for Windows Store/Windows Phone apps) will be updated in order to follow MS-Edge developments. So what's the fuss about making it available in WinForms/WPF platforms, or enriching WebBrowser with the same feature?

    • Edited by VBobCat Tuesday, June 30, 2015 12:45 PM
    Tuesday, June 30, 2015 12:37 PM

  • I just tried the c# webbrowser control on Windows 10 Insider Preview and when I set

    FEATURE_BROWSER_EMULATION to exactly 12001 then the webbrowser control sends a user agent string containing "Edge/12.9200_AGENT" and the control renders webpages without problems.


    Now I am puzzled as this leaves us with two possibilities:


    a) Contrary to consensus in the developer community the Windows 10 webbrowser control does indeed use the new Spartan / Edge engine.


    b) Windows 10 webbrowser control still uses the old Trident engine and the user agent string is wrong, being a bug in Windows 10 Insider Preview.


    Could someone please confirm what is right and what is wrong?


    Website used for checking user agent: http://ipinfo.info/html/privacy-check.php


    Tuesday, June 30, 2015 12:48 PM
  • Maybe it allows emulating Edge's agent string, but continues to render pages as Trident would do.

    One could try using that control to load a page that is targeted specifically to Mozilla browsers and wouldn't render well with Trident? Based on the results, one could figure if it is Edge after all, or just a buggy agent string emulation possibility...

    It would be nice if someone could test that and post the results here.

    Saturday, July 4, 2015 2:35 AM
  • Justs checked it out on Windows 10 insider preview Build 10159 with html5test.com. The browser scores 347, identical to IE 11, so it appears to be using the Trident engine. The Agent string is wrong, however. It shows "Edge" and "Windows 8" instead of "IE11" on "Windows 10".

    See for yourself:

    webbrowser cotrol on Win 10 Preview 10159 showing wrong user string with Trident

    Saturday, July 4, 2015 11:16 AM
  • I use the web browser control in a 64 bit app and that is already broken in Windows 10 - it does not work in a 64 bit process, just gives me a white background and no render.  Enabling 64 bit mode in IE11 makes no difference. The 32 bit build of my code works has the browser control rendering but we are going all 64 bit for the future.

    Not sure what to do - is there a switch somewhere to allow the browser control to operate in a 64 bit process?

    Wednesday, July 8, 2015 11:15 PM