Hosting a WebBrowser control in a web page

[jmi0]

I need to have my web application (html, jsp, etc.) to host a
WebBrowser control by using the object tag for an assembly which
contains my custom user control which contains the WebBrowser control.
The problem is that the WebBrowser control won't load. It's prematurely
disposed when the control object being accessed in my C# code
InitializeComponent().

The info I've gathered so far seems to attribute this behavior to
security concern. While I was informed this is not a designed feature
for web page hosting, I've been seeing examples (in VB script) for the
usage. I, however, couldn't get these examples work for me either.

If the .net framework runtime indeed blocks the control's deployment in
a web page due to security concern, is there a way to bypass it? By
signing it, granting permission or other machnisms?

btw, my web server is Tomcat, not IIS. I, however, don't think it's
relavant because any other non-WebBrowser controls displayed just fine.

Any one has any insight on this?

Thanks in advance,
Jason

 

[Dmytro Lapshyn [MVP]]

Hi,

Wouldn't a simple IFRAME tag be a decent workaround for hosting another
instance of Web browser within a Web page?

 

[Jason]

Hi Dmytro,

I'm very interested in your suggestion about using the IFRAME for this.
Can you possiblly give me some simple illustration/sample of it? I
suppose that the IFRAME object can be used in javascript to get some
information about its contained browser and the pages being browsed such
as the number of frames in the page.

Appreciate your help,
Jason

 

[Alec Yu]

I have a solution to run your control fully trusted.
See http://en.ezlag.com/site/335/lagloadernet.aspx

The main reason for WebBrowser control not working in IE,
is due to the fact that IE is itself an ActiveX document container,
WebBrowser control is implemented as an IE instance hosted in
a .NET Windows Forms control, and thus you are trying to put
a ActiveX/.NET Windows Forms control containing an ActiveX
document container in another ActiveX document container,
which violates an IE limitation documented in Microsoft support
knowledge base KB311765. See
http://support.microsoft.com/default.aspx?scid=kb;en-us;311765

DsoFramer introduced in that document is not a stable solution,
even though you may google out more about DsoFramer and its
enhancements.

I spent weeks overcome this container-in-a-control-in-another-container
issue, and extended it to work with .NET Windows Forms control
based smart clients, as to allow them running fully trusted and install
..NET framework automatically on machines never installed .NET
framework runtime.