none
WPF Webbrowser

    Question

  • Was wondering what MSFT's plans are for the WPF Webbrowser, as far as I'm concerned it digressed from the old Windows.Forms.Webbrowser by making everything MSHTML.  Not that we can't use it, but it requires a lot of browser DOM internals knowledge which literally can take years to learn.  It also crosses the mysterious COM Divide, which has a mindset of its own.

    I've read in these forums that "there wasn't enough time".  But I'm almost wondering if this is the plan, to leave it as a non-managed code wrapped object.  MSFT has made the IExplorer a hallowed first class object on it's platforms, but has not allowed us loyal MSFT coding adherants to utilize it full force in our applications.  Call it Legacy code lag if you want (the same with thier office products) but to me this is what they want.  IE is so important to them that they can't even create or tolerate any developer's attempt to integrate this into an application subserviant to that application.  IE is a top level control which among other things dissallows any other parent owning that window.  When you get the Webbrowser in code you don't get toolbars, and other truly "open" architecture.  You have to create parts to make it "Act" like it's the real thing.  This makes for "Cheesy" imitations of IE.  And it forces the developers to take the time to learn way too much of IE Internals.  For example, how many IHTMLDOCUMENT interfaces do you really need?  The real answer is 1 not 3 or 4.  It's just an ongoing problem (IMO) with the MSFT Flagship products, developers can use them but they are "Crippled".

     


    Javaman, Cowboy Coders Unite!
    Tuesday, January 25, 2011 2:21 PM

Answers

  • There are a couple of comments that I would contribute...

     

    First, I doubt this landscape will change much.  IE is not a WPF application - it's using native APIs, and only going "more native" over time (in order to take advantage of Direct2D and other accelerated APIs).  Given it's huge history and backwards compatibility requirements, the API is probably not going to be simplified.  (I do wish they'd make a clean wrapper around this and expose it to WPF, however...)

    Second, you can use the C# wrappers for WebKit.  This is a much leaner API than the IE API, and has some advantages from a developer's POV.  The DOM code is (in my opinion) a bit easier to work with.

     

    That being said, the biggest annoyance to me, right now, is the airspace issue.  Since IE is exposed via COM, it's got it's own airspace problems.  There have been announcements that MS is actively working on removing airspace restrictions for future versions of WPF (see Rob's talk at the PDC).  This would have a HUGE impact on the usability of not only Webbrowser, but also 3D content, other COM issues, hosting silverlight, and many other nice perks... I really, really hope they get the airspace thing figured out.


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    • Marked as answer by Mr. Javaman Tuesday, February 01, 2011 3:07 AM
    Tuesday, January 25, 2011 4:42 PM
  • Hi all, 

    We really appreciate all your valuable feedbacks!

    I must admit that the current WPF WebBrowser control has less desirable features. As I have explained above, we are working on the next release of the WPF. In order to get a better visibility and help for Product Group with the coming version, could you kindly post the suggestions to our Connect feedback portal. Our developer will evaluate them seriously and take them into consideration when designing future release of the product.

    https://connect.microsoft.com/WPF

     

    Improving the quality of the products and services is a never-ending process for Microsoft. Thanks again for choosing us.

     

    @Mr. Javaman, thank you for your enthusiastic and friendly help. All your participation and support are very important to build such harmonious learning environment for MSDN community. Since this issue needs your feedbacks to us and depends on the exact design of WPF vNext, could you please kindly change your issue type to “General Discussion”?

    Best regards


    Yves Zhang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by Mr. Javaman Monday, January 31, 2011 10:58 AM
    Monday, January 31, 2011 10:10 AM

All replies

  • There are a couple of comments that I would contribute...

     

    First, I doubt this landscape will change much.  IE is not a WPF application - it's using native APIs, and only going "more native" over time (in order to take advantage of Direct2D and other accelerated APIs).  Given it's huge history and backwards compatibility requirements, the API is probably not going to be simplified.  (I do wish they'd make a clean wrapper around this and expose it to WPF, however...)

    Second, you can use the C# wrappers for WebKit.  This is a much leaner API than the IE API, and has some advantages from a developer's POV.  The DOM code is (in my opinion) a bit easier to work with.

     

    That being said, the biggest annoyance to me, right now, is the airspace issue.  Since IE is exposed via COM, it's got it's own airspace problems.  There have been announcements that MS is actively working on removing airspace restrictions for future versions of WPF (see Rob's talk at the PDC).  This would have a HUGE impact on the usability of not only Webbrowser, but also 3D content, other COM issues, hosting silverlight, and many other nice perks... I really, really hope they get the airspace thing figured out.


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    • Marked as answer by Mr. Javaman Tuesday, February 01, 2011 3:07 AM
    Tuesday, January 25, 2011 4:42 PM
  • MSFT?  Should we continue to learn IE internals or wait for a wrapper?
    Javaman, Cowboy Coders Unite!
    Wednesday, January 26, 2011 3:12 PM
  • Hi Mr. Javaman,

    Thanks Reed for the reply!

    Currently our developers are working on the future release of WPF which including WPF WebBrowser. We have taken the compatibility and Airspace issues into serious account when designing the products.

    The exact timeframe of this release has not been announced though. WPF vNext is working to fix Airspace for WebBrowser hosting, allows composition of other WPF content on top of WebBrowser. we are making the existing browser integrate into WPF content better.

     

    Best regards


    Yves Zhang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, January 28, 2011 6:56 AM
  • In .Net 4 the WebBrowser control in its current state is useless.  I shouldn't have to learn the internals of IE to use a WebBrowser component.  I shouldn't have to reference some damn library that is also currently bugged in visual studio and has been from at least 2007!!  And I also shouldn't have to start hosting WinForm controls so I can get some functionality that may or may not even work.  The control feels like some very sloppy implementation.  Although at this point I would rather see a property grid implemented first, how this control was left out is mind boggling.
    Friday, January 28, 2011 2:00 PM
  • Agreed, the webbrowser is the single most important component in developing applications of any kind, and MSFT has kept the doors opened only to C++ and Native Windows programmers and only IF they play by the rules of it being a TOP MOST container.  We are told year and year, we'll have it next year.  Instead we have to resort to hosting Window Forms controls in WPF.  It could be argued that the Windforms webbrowser itself is less than stellar. 

    Let's don't even bring up the Silverlight restrictions making access to the DOM impossible.  Yet we can via ASP.NET accomplish what we need.  This tells me that ASP.NET is higher on the foodchain than Silverlight.

    But alas the flagship WPF product is without a managed browser, that was and continues to be an oversight affecting many developers in negative ways.  How long does it take to write a wrapper?


    Javaman, Cowboy Coders Unite!
    Friday, January 28, 2011 2:20 PM
  • Hi all, 

    We really appreciate all your valuable feedbacks!

    I must admit that the current WPF WebBrowser control has less desirable features. As I have explained above, we are working on the next release of the WPF. In order to get a better visibility and help for Product Group with the coming version, could you kindly post the suggestions to our Connect feedback portal. Our developer will evaluate them seriously and take them into consideration when designing future release of the product.

    https://connect.microsoft.com/WPF

     

    Improving the quality of the products and services is a never-ending process for Microsoft. Thanks again for choosing us.

     

    @Mr. Javaman, thank you for your enthusiastic and friendly help. All your participation and support are very important to build such harmonious learning environment for MSDN community. Since this issue needs your feedbacks to us and depends on the exact design of WPF vNext, could you please kindly change your issue type to “General Discussion”?

    Best regards


    Yves Zhang [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by Mr. Javaman Monday, January 31, 2011 10:58 AM
    Monday, January 31, 2011 10:10 AM
  • Hey Reed;

       I just took a look at webkit, I like the really clean DOM stuff, and the browser methods are simple.  Could this be the replacement for IE with developers?  What about Silverlight?


    Javaman, Cowboy Coders Unite!
    Tuesday, February 01, 2011 3:09 AM
  • Hey Reed;

       I just took a look at webkit, I like the really clean DOM stuff, and the browser methods are simple.  Could this be the replacement for IE with developers?  What about Silverlight?


    Javaman, Cowboy Coders Unite!

    A lot of dev's seem to like it for desktop development, but it won't work in Silverlight (as it's native code) - at least not unless you wrap it in COM and use it out of browser...

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    Tuesday, February 01, 2011 5:06 PM