Why can't MS create a new browser from scratch based purely on .Net? The current browser is enough of an embarrassment that it would serve them well to release something new that is:

• As standards compliant as possible (yes, even pass the stupid Acid tests 100%)
• Secure. Using .Net will give them a lot of security out of the box. There is your sandbox right there. You need to try really hard to create an insecure app with .Net
• Fast*
• Have a good plug-in API. Using .Net will allow much easier plugin development, including being able to force plugins to be secure. No untrusted code. No memory leaks from badly written plugins. No invalid memory access, corrupted memory, etc.

*Note, I say "fast", because even though .Net apps will always be slightly slower than native apps, the overhead is not that much, and currently IE is roughly 20 times slower than the competition in some places, so creating something newer that is faster than what we have now should be possible with a well designed, well implemented .Net version.

And don't tell me they can't afford it. Yes, this would be a monumental task, but IE is one of MS' apps that are quite visible to the public , the press and end users. It is hurting their image. Putting resources into developing a better IE should be a high priority I believe.

Thoughts?

• They've already made a huge investment in the Trident engine which is now standards compliant and works fine.
• It would break backwards compatibility with existing websites since you'd have to recreate the issues in IE7 for its compatibility mode
• MSHTML is used by a lot of programs, introducing the CLR will introduce problems like if the program already uses the CLR, but uses a different and incompatible version to whatever "IE.NET" uses
• The NSAPI and ActiveX plugin systems are here to stay. Adobe and Apple aren't going to bend over backwards to make a managed interface for Flash and QuickTime respectively.

BitFlipper said:

You need to try really hard to create an insecure app with .Net

You really, really don't.

.NET might make a small class of bug less likely but it's still very easy to introduce security flaws if you don't take the time to architect things correctly. Especially if you're getting untrusted data from the Internet.

W3bbo said:

No, because:

• They've already made a huge investment in the Trident engine which is now standards compliant and works fine.
• It would break backwards compatibility with existing websites since you'd have to recreate the issues in IE7 for its compatibility mode
• MSHTML is used by a lot of programs, introducing the CLR will introduce problems like if the program already uses the CLR, but uses a different and incompatible version to whatever "IE.NET" uses
• The NSAPI and ActiveX plugin systems are here to stay. Adobe and Apple aren't going to bend over backwards to make a managed interface for Flash and QuickTime respectively.

• Works fine? Are you seeing how it is losing in almost any comparison with FF or Chrome, speed and compliance wise? Maybe that is the problem with IE - its developers think it "works fine".
• Just as FF or Chrome doesn't break backwards compatibility, why would a new MS browser be any worse of than those? If people want to view websites that can only work in IE8, let them keep IE8 installed (side-by side).
• There is nothing preventing MS from creating a stand-alone browser that does not replace, or even use, the current MSHTML renderer. keep MSHTML as is for all the reasons you list.
• ActiveX - keep using IE8 if you need that. Introduce a better plugin API with the new browser.

At some point the current IE line needs to die, and MS needs to create something better to replace it. Other people are creating better alternates.  I am a long-time IE user and supporter, but it is getting harder and harder to justify staying with it. Its performance compared to other browsers is just plain pathetic. MS should fix it before everyone abandons it, unless they are fine with that outcome.  Maybe they don't care about the browser any more.  That is also fine.  But just let me know in that case and I'll switch now instead of hoping things will get better somewhere down the line.

AndyC said:

BitFlipper said:

*snip*

You really, really don't.

.NET might make a small class of bug less likely but it's still very easy to introduce security flaws if you don't take the time to architect things correctly. Especially if you're getting untrusted data from the Internet.

I hardly call a lack of memory leaks and corrupted memory "a small class of bugs". While I develop .Net apps these days, some of my co-workers spend huge amounts of time tracking down obscure memory corruption bugs in their C++ code. And from my days of developing C++ apps in the past, this is also what I remember wasting endless time on.

And lets not foget how FF struggles with plugins causing all sorts of memory leaks and instability.

A "small class of bugs"? Hardly.

BitFlipper said:

AndyC said:

*snip*

I hardly call a lack of memory leaks and corrupted memory "a small class of bugs". While I develop .Net apps these days, some of my co-workers spend huge amounts of time tracking down obscure memory corruption bugs in their C++ code. And from my days of developing C++ apps in the past, this is also what I remember wasting endless time on.

And lets not foget how FF struggles with plugins causing all sorts of memory leaks and instability.

A "small class of bugs"? Hardly.

It protects against buffer overrun type attacks (mostly), but it's certainly possible to leak memory in a .NET app (even though a memory leak isn't necessarily a security issue) even if it more difficult than with unmanaged code. And there are plenty of other attack vectors which .NET by itself can't protect you from.

staceyw said:

IMO, they should.  It could be an OS Codeplex project and go from there.  Not to replace IE as such, but more like a OS research project.  They will need one for Singularity anyway.  They probably have one already in research mode.  You could make one today using the browser control in .Net.  Not sure if the control itself is managed or native.

The web browser control in .NET is just the native code rendering component. If there is a compelling reason to write one in .NET then why not start a project on CodePlex today?

FWIW I think there are advantages to having a webbrowser written entirely in WPF. Not necessecarily because of "security", "plugins" or "speed" but because it would open up the possiblity of applying transforms and other WPF-y effects that you can't do on an interop'd control. That would be a far more compelling argument to me. I'm also not naive enough to believe that such a thing would be trivial (though I'd certainly be interested in helping if there was a project underway!)

AndyC said:

staceyw said:

*snip*

The web browser control in .NET is just the native code rendering component. If there is a compelling reason to write one in .NET then why not start a project on CodePlex today?

FWIW I think there are advantages to having a webbrowser written entirely in WPF. Not necessecarily because of "security", "plugins" or "speed" but because it would open up the possiblity of applying transforms and other WPF-y effects that you can't do on an interop'd control. That would be a far more compelling argument to me. I'm also not naive enough to believe that such a thing would be trivial (though I'd certainly be interested in helping if there was a project underway!)

WPF Browser project?  http://khaos.codeplex.com/ is available ...

Herbie

Dr Herbie said:

AndyC said:

*snip*

WPF Browser project?  http://khaos.codeplex.com/ is available ...

Herbie

See, now that is interesting.

AndyC said:

Dr Herbie said:

*snip*

See, now that is interesting.

very

But I don't really see otherwise why..

stevo_ said:

I wouldn't get to excited, I don't think its going anywhere.. theres just a lot of work that needs to go into a browser.. writing one in .net would be interesting from an extensibility point (perhaps, but still less so interesting than extensions in say firefox- which are much more approachable).

But I don't really see otherwise why..

The reason is simple. Anyone could use the same core to build browser ontop of .Net. Any machine supports .net platform would be able to run the program easily. For example, run you own version of browser on Win Mo, on Win CE based GPS system, on many other Win CE bases systems.

stevo_ said:

I wouldn't get to excited, I don't think its going anywhere.. theres just a lot of work that needs to go into a browser.. writing one in .net would be interesting from an extensibility point (perhaps, but still less so interesting than extensions in say firefox- which are much more approachable).

But I don't really see otherwise why..

Paste the following into XAMLpad:

<Window
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <Grid>
        <Rectangle Width="40" Height="40" Fill="Beige" HorizontalAlignment="left"/>
        <WebBrowser  Margin="15" Source="http://channel9.msdn.com" />
        <Rectangle Width="40" Height="40" Fill="AliceBlue" VerticalAlignment="top"/>
        <Menu VerticalAlignment="Top">
            <MenuItem Header="_File">
                <MenuItem Header="_New"/>
                <MenuItem Header="_Open"/>
                <MenuItem Header="Close"/>
        </MenuItem>
        </Menu>
        <Label VerticalAlignment="Center" HorizontalAlignment="Center">This Text should should appear over the top of everything</Label>
    </Grid>
</Window>

Notice how the webbrowser appears over the top of everything. It's a limitation of hosting a native control in a WPF application, which really limits the things you can acheive. A 100% WPF based managed webbrowser control would allow you to integrate HTML content in a much more natural and flexible way.

magicalclick said:

stevo_ said:

*snip*

The reason is simple. Anyone could use the same core to build browser ontop of .Net. Any machine supports .net platform would be able to run the program easily. For example, run you own version of browser on Win Mo, on Win CE based GPS system, on many other Win CE bases systems.

 

Uh you could do that in c++, both will need platform abstraction layers... but you wouldn't want to do that because the UI / experience of a phone is different to a desktop.. the core of the rendering engine should be re-used, and that would have significantly less dependencies than a UI would..

Also AndyC, that example doesn't mean you should do it in .NET, it just means there needs to be a better way to interop the drawing layers in WPF and native.. maybe they already do have a good way but the web browser control just isn't compat..

But I'm pretty sure they could make that work faster than it would for them to write an entirely new browser..

.NET is great, I solely program .NET, in-fact I've had such a brief time in native world that I hardly remember it, but I at least know that native isn't obsolete to .NET - and that I can't see any reason why they wouldn't instead- write an entirely new browser in native..

stevo_ said:

magicalclick said:

*snip*

Uh you could do that in c++, both will need platform abstraction layers... but you wouldn't want to do that because the UI / experience of a phone is different to a desktop.. the core of the rendering engine should be re-used, and that would have significantly less dependencies than a UI would..

Also AndyC, that example doesn't mean you should do it in .NET, it just means there needs to be a better way to interop the drawing layers in WPF and native.. maybe they already do have a good way but the web browser control just isn't compat..

But I'm pretty sure they could make that work faster than it would for them to write an entirely new browser..

.NET is great, I solely program .NET, in-fact I've had such a brief time in native world that I hardly remember it, but I at least know that native isn't obsolete to .NET - and that I can't see any reason why they wouldn't instead- write an entirely new browser in native..

steveo_ said:

Also AndyC, that example doesn't mean you should do it in .NET, it just means there needs to be a better way to interop the drawing layers in WPF and native.. maybe they already do have a good way but the web browser control just isn't compat..

Unlikely, doing that would mean pretty much redeveloping large parts of Win32, since it is fundamental Win32 decisions that lead to the limitations involved. And that in itself would be not only an enormous job, but a compatibility nightmare. And even after all that it might not even be fixable without breaking basic Win32 assumptions - remember it's not necessarily just layering, but the ability to truly treat it as a WPF control, including applying transformations, animations or embedding the control onto a 3D surface whilst remaining functional.

Given that Trident no longer has any actual dependencies on real Win32 controls, it would probably be easier to port that into WPF via C++/CLI if they wanted to fix that. It's questionable whether that would have any benefit for Microsoft though, given it's not something they necessarily need themselves. I still think it would be a useful third party control though. 

AndyC said:

stevo_ said:

*snip*

Unlikely, doing that would mean pretty much redeveloping large parts of Win32, since it is fundamental Win32 decisions that lead to the limitations involved. And that in itself would be not only an enormous job, but a compatibility nightmare. And even after all that it might not even be fixable without breaking basic Win32 assumptions - remember it's not necessarily just layering, but the ability to truly treat it as a WPF control, including applying transformations, animations or embedding the control onto a 3D surface whilst remaining functional.

Given that Trident no longer has any actual dependencies on real Win32 controls, it would probably be easier to port that into WPF via C++/CLI if they wanted to fix that. It's questionable whether that would have any benefit for Microsoft though, given it's not something they necessarily need themselves. I still think it would be a useful third party control though. 

I hear WebKit has a reasonably portable back end. I wonder if it could be ported to render to a Direct3D surface which could then better interop with WPF via D3DImage.

DCMonkey said:

AndyC said:

*snip*

I hear WebKit has a reasonably portable back end. I wonder if it could be ported to render to a Direct3D surface which could then better interop with WPF via D3DImage.

The fundamental issue here is that Windows Vista even Windows 7 doesn't support GDI redirection for child HWNDs. If this is supported, there will be a much better interop story with the MIL rendering path.

Zhou Yong

Many other things become possible and interesting.

ManipUni said:

It would be too slow. Plus it has very few benefits. .Net addons and expansion can be accomplished without having the entire browser on the platform, and it would only solve a single type of security issue.

I disagree.  Having it vector based is a single huge feature for browsers.  Animations and graphics would become better and easier for the programmers also.  Essentially what we are talking about is Silverlight which does this and is .Net based.  This is the reason silverlight needs a runtime in the browser to pull off its magic.  However, with a .net browser, you would not require silverlight and could just use the standard .net runtime and wpf.  TMK, you can't vector scale any browser today (only thumbnail it).  A plugable .net pipeline is the future.

ManipUni said:

It would be too slow. Plus it has very few benefits. .Net addons and expansion can be accomplished without having the entire browser on the platform, and it would only solve a single type of security issue.

"It would be too slow. Plus it has very few benefits. .Net addons and expansion can be accomplished without having the entire browser on the platform, and it would only solve a single type of security issue."

Please explain why using .net would make it too slow? or perhaps you mean something else would be slow?

for the same reason they can't create a new browser in C++

staceyw said:

ManipUni said:

*snip*

I disagree.  Having it vector based is a single huge feature for browsers.  Animations and graphics would become better and easier for the programmers also.  Essentially what we are talking about is Silverlight which does this and is .Net based.  This is the reason silverlight needs a runtime in the browser to pull off its magic.  However, with a .net browser, you would not require silverlight and could just use the standard .net runtime and wpf.  TMK, you can't vector scale any browser today (only thumbnail it).  A plugable .net pipeline is the future.

-> This is the reason silverlight needs a runtime in the browser to pull off its magic.

This is an interesting hypothesis, could you please elaborate on which basis you make this type of conclusion, you don't know that SL could be hosted out of browser?

Zhou Yong

staceyw said:

Being .Net/WPF based could be an interesting story.
1) Being vector based the free scaling/sizing would be new.
2) Browser-in-browser UX (e.g. picture-in-picture).  You could easily add other brower windows inside others for some interesting features.  Each browser could also be at a different scale or clipping region.
3) Make client follow ASP.Net component model and pipeline on the client.  Can hook in anywhere in the pipeline.  Allows you to program and script your browser UX and sessions.  A Favorite, for example, could be a piece of script that sets up some tabs or a browser-in-browser experience.

Many other things become possible and interesting.

-> 3) Make client follow ASP.Net component model and pipeline on the client.  Can hook in anywhere in the pipeline.  Allows you to program and script your browser UX and sessions.

If you use WPF for a reasonable period of time, you might think WPF's control/component model is much better.

Zhou Yong

footballism said:

staceyw said:

*snip*

-> This is the reason silverlight needs a runtime in the browser to pull off its magic.

This is an interesting hypothesis, could you please elaborate on which basis you make this type of conclusion, you don't know that SL could be hosted out of browser?

Zhou Yong

"This is an interesting hypothesis, could you please elaborate on which basis you make this type of conclusion, you don't know that SL could be hosted out of browser?"

Hi Zhou.  You missed my point.  You keep saying .Net would provide little value.  Silverlight is essentially a browser that using XAML instead of HTML.  That is a good example of .Nets value, and it is not slow.  In fact, switching content can be orders faster then older methods.  SL3 can be hosted out of browser, but not sure how that fits to what we are saying.

footballism said:

staceyw said:

*snip*

-> 3) Make client follow ASP.Net component model and pipeline on the client.  Can hook in anywhere in the pipeline.  Allows you to program and script your browser UX and sessions.

If you use WPF for a reasonable period of time, you might think WPF's control/component model is much better.

Zhou Yong

"If you use WPF for a reasonable period of time, you might think WPF's control/component model is much better."

I think I was agreeing with that.  I am saying take the same track Scott Gu did with ASP.Net on the browser side using a pipeline model where you can hook in almost anywhere  (i.e. redirect popups to a log file if you want, or log site hits, etc)  Using powershell snippets or other .Net language. 

http://htmlrenderer.codeplex.com/

footballism said:

staceyw said:

*snip*

-> This is the reason silverlight needs a runtime in the browser to pull off its magic.

This is an interesting hypothesis, could you please elaborate on which basis you make this type of conclusion, you don't know that SL could be hosted out of browser?

Zhou Yong

"-> This is the reason silverlight needs a runtime in the browser to pull off its magic.

figuerres said:

footballism said:

*snip*

"-> This is the reason silverlight needs a runtime in the browser to pull off its magic.

This is an interesting hypothesis, could you please elaborate on which basis you make this type of conclusion, you don't know that SL could be hosted out of browser?

Zhou Yong"

that does not mean that the browser is not there...

the SL3 OOB is just a window on the desktop that is the "Parent COntainer" for the SL runtime to draw into.

if the SL app uses any .Net bits that need to access the IE engine then IE still has to be installed for that to work.

Next is my guess, on a system that does not have IE, like on a Mac the SL runtime hooks on to some local library that supplies the bits?

I might be wrong but that's how i take it the SL3 OOB works.

"that does not mean that the browser is not there..."

I did not say otherwise.  The browser (in terms of SL) is really only used for the display canvas and a bridge for clicking back into legacy html pages (IE should feel so used )  However the browser proper (e.g. IE) is not required for SL.  So SL/xaml is, in effect, a new .net based browser - that parses xaml instead of html and has its own display processor.  This is shown clearly with SL hosted outside the browser using its own host.  My point has only been that .net tech in browser senerios works today and has value, unlike what others are saying.  I have only pointed out SL as a prime example.

staceyw said:

figuerres said:

*snip*

"that does not mean that the browser is not there..."

I did not say otherwise.  The browser (in terms of SL) is really only used for the display canvas and a bridge for clicking back into legacy html pages (IE should feel so used )  However the browser proper (e.g. IE) is not required for SL.  So SL/xaml is, in effect, a new .net based browser - that parses xaml instead of html and has its own display processor.  This is shown clearly with SL hosted outside the browser using its own host.  My point has only been that .net tech in browser senerios works today and has value, unlike what others are saying.  I have only pointed out SL as a prime example.

Stacyw: i was replying to football's question.  i agree with your points. i think silverlight is very interesting new development.

in fact i am working on getting familiar with it in hopes of not having to mess with flash  in the near future.

i do not really like coding in flashes actionscript.... bleh!  .Net Rocks!

figuerres said:

staceyw said:

*snip*

Stacyw: i was replying to football's question.  i agree with your points. i think silverlight is very interesting new development.

in fact i am working on getting familiar with it in hopes of not having to mess with flash  in the near future.

i do not really like coding in flashes actionscript.... bleh!  .Net Rocks!

@figuerres.  Cool.  Have been playing more with it in vs2010 which finally makes it usable for mortals.  Blend 3 beta gets close, but 2010 is going to be way cool for SL/WPF.  Can't wait till VS 2010 Beta2.  Am really liking the SL layout  and the sharp look you get and not having to deal with html crazy spacing, paragraphs, and image space hacks, etc.  Struggling a bit now on how to deal with layout that goes below the browser window space as it gets clipped and scrolling does not seem to work as expected - but I am almost sure this my issue. 

staceyw said:

figuerres said:

*snip*

"that does not mean that the browser is not there..."

I did not say otherwise.  The browser (in terms of SL) is really only used for the display canvas and a bridge for clicking back into legacy html pages (IE should feel so used )  However the browser proper (e.g. IE) is not required for SL.  So SL/xaml is, in effect, a new .net based browser - that parses xaml instead of html and has its own display processor.  This is shown clearly with SL hosted outside the browser using its own host.  My point has only been that .net tech in browser senerios works today and has value, unlike what others are saying.  I have only pointed out SL as a prime example.

-> So SL/xaml is, in effect, a new .net based browser - that parses xaml instead of html and has its own display processor.  This is shown clearly with SL hosted outside the browser using its own host.  My point has only been that .net tech in browser senerios works today and has value, unlike what others are saying.  I have only pointed out SL as a prime example.

Nope, the parsing of XAML and rendering of SL visual tree are all done in unmanaged code, core CLR is only used to expose those features to managed code, since in V1, people still needs to use Javascript which desktop developers doesn't enjoy writing and web developers are tired of writing in it too, so core CLR is just very thin wrapper around the underlying unmanaged SL runtime.

Actually, the existing WebBrowser control could be retrofitted to workaround the infamous airspace issue by rendering HTML in HWNDless mode, no need to rewrite it from scratch.

Zhou Yong