What is a good alternative to WPF WebBrowser Control?

Question

I have an MDI WPF application in which I need to add web content. At first, it’s great that I have 2 options built into the Frame structure, and WebBrowser . Given that this is an MDI , it does not take a long time to find that none of them will work.

The WPF WebBrowser control wraps IE WebBrowser ActiveX Control , which uses the Win32 graphics pipeline. The " Airspace " problem pretty much sums it up as "Sorry, layouts won't play well together."

Yes, I thought about taking snapshots of web content by displaying them and displaying mouse and keyboard events back to the browser control, but I can't afford the performance penalty, and I really don't have time to write and test it thoroughly.

I was looking for third-party controls, but so far I have found Chris Cavanagh Office WPF Chromium Web Browser . Which completes Awesomium 1.5 . Together they are very cool, they go well with WPF layouts. But they do not meet my performance requirements. They are VERY HEAVY for memory consumption, not CPU friendly. Not to mention pretty buggy. If you are interested, I will clarify.

So, do you know any of the stable WPF web browser?

Thanks.

Answer 1

I do not think that there are many fully managed web controls. There is unusual at http://www.modeltext.com/html/ (I am its author).

This is a Windows Forms control, not WPF. Windows Forms - The WPF compatibility FAQ suggests that this is not a problem; but I don’t know if the "airspace" problem precludes the use of the Windows Forms control.

On the positive side:

• Fully managed
• Artist: low processor at least (I don't know what your memory requirements are)
• May have more than one instance in the application

On the minus side:

• Only a subset of the features that will be supported by the main browser (so it depends on what you want)
• Beta quality

---

Edit:

Sounds like a nice job.

Thanks.

For this application I need a fully functional browser (I have to support javascript).

In this case, this will not work for you: this control provides the .NET (not javascript) DOM APIs; therefore, applications can implement and install DOM event handlers that are written in C # rather than in javascript.

And yes, placing a control in a WPF application will work fine until you need to stack your objects. All winforms controls will suffer from this problem due to rendering pipelines. See the link above. Did you consider the native port of WPF?

A WPF port may be possible as it maps to / through an abstract context-like interface, of which I have two full / different implementations:

• One uses System.Windows.Forms and System.Drawing
• My other automated test environment that implements a modest dialog template for testing GUI regression.

It is theoretically possible I could implement a third one for WPF using System.Windows.Controls and System.Windows.Media .

Kind of random, but it might seem interesting to you: http://blog.spencen.com/2008/01/19/html-to-flowdocument-converter.aspx

Thanks for that: I find it interesting. WPF RichTextBox provides many editing features.