More IE8 Extensibility Improvements

Anith » More IE8 Extensibility Improvements

Anith » More IE8 Extensibility Improvements — Wed, 11 Mar 2009 03:25:24 GMT

PingBack from http://www.anith.com/?p=17401

re: More IE8 Extensibility Improvements

Florin — Wed, 11 Mar 2009 08:19:56 GMT

In RC1 the IE7 Standards mode is the default rendering mode of the WebBrowser control. Are you going to change this and make IE8 Standards the default rendering mode in the final version of IE 8 or in the future versions of the browser?

re: More IE8 Extensibility Improvements

mattcrow [msft] — Wed, 11 Mar 2009 10:32:44 GMT

@Florin Yes, IE7 mode is still the default mode for applications; we needed to do this from a compatibility standpoint. Looking at it from an IE8 and Win7 perspective, we wanted to make sure we didn't break existing applications that depended on the web browser control. As new versions of apps are released and legacy ones are replaced, we'll revisit which mode will be the default one in future versions of IE.

re: More IE8 Extensibility Improvements

Viktor Krammer — Wed, 11 Mar 2009 12:09:05 GMT

@MattCrow

Let developers also choose the rendering mode programmatically with a new API in addition to the registry setting.

We also need APIs for tab management, enable/disable/query the state of InPrivate mode, new event when the user refreshes the page, offical APIs for getting the information form SSL (EV) certificates, etc.

re: More IE8 Extensibility Improvements

Sheldon — Wed, 11 Mar 2009 15:25:09 GMT

do I read this correctly that I have to set a GLOBAL value for my emulation mode? e.g. this value will apply to ALL embeded IE instances?

Shouldn't this RegKey be "per" application, not assigned per user in the OS?

Or am I missing something here?

re: More IE8 Extensibility Improvements

Jeffrey Gilbert — Wed, 11 Mar 2009 17:40:02 GMT

Which mode allows it to function as well as ff 1.0 from a decade ago?

Internet Explorer 8 : sulla compatibilità

Pietro Brambati Blog — Wed, 11 Mar 2009 18:15:50 GMT

[Update 11/3] IE8 al momento è stato rilasciato in versione RC1. Una delle cose che preferisco del nuovo

re: More IE8 Extensibility Improvements

mattcrow [msft] — Wed, 11 Mar 2009 19:36:45 GMT

@Sheldon Yes, this will apply to all embedded IE instances for a given EXE name. You can assign this key to individual users (HKCU) or to the whole system (HKLM).

I wasn't super clear on those items. I've sent in an update request for this post to clarify. Thanks for the comments.

re: More IE8 Extensibility Improvements

8675309 — Wed, 11 Mar 2009 22:49:42 GMT

so this means donwloadable pogo games might or might not work?

re: More IE8 Extensibility Improvements

8675309 — Wed, 11 Mar 2009 22:50:10 GMT

so this means donwloadable pogo games might or might not work?

re: More IE8 Extensibility Improvements

Ian Boyd — Wed, 11 Mar 2009 23:56:33 GMT

Dogfood IE8 at 120dpi or higher, and live with its slow rendering day after day. See how long it takes you before you can't stand it, and force IE to run at 100% (96dpi) on a 125% (120dpi) machine.

re: More IE8 Extensibility Improvements

Giacinto — Thu, 12 Mar 2009 01:13:50 GMT

when are available the final version of ie8?

re: More IE8 Extensibility Improvements

David — Thu, 12 Mar 2009 02:19:51 GMT

So, when are you guys going to release the official copy of IE8? I was also hoping you guys could find a way to make it render pages faster then it does now. When I open it up sometimes, pages load really fast, then something happens and pages end up loading slow again. I have emptied out my Internet Cache, and that still has not fixed the problem.

Keep up the good work!

re: More IE8 Extensibility Improvements

PatriotB — Thu, 12 Mar 2009 08:01:49 GMT

Quite unfortunate that its a per-process setting -- and can't even be set via CoInternetSetFeatureEnabled.

Unfortunately it looks like WebOCs used by toolbars or extensions in IE *and* Windows Explorer are defaulting to IE8 mode, simply because of the process name. Why wasn't this done on a per-WebOC basis?

re: More IE8 Extensibility Improvements

David W. — Thu, 12 Mar 2009 09:06:53 GMT

I can only pray this interface has been guarded against say, people adding keys for "explorer.exe" and "iexplore.exe".

Please confirm we won't suffer another 10 years of abusive apps!

re: More IE8 Extensibility Improvements

anonymuos — Thu, 12 Mar 2009 15:09:37 GMT

Microsoft needs to design another extensibility layer for Internet Explorer which allows writing extensions in XAML, XML and JavaScript so lots more free killer and quick extensions can be written. The current compiled/binary extensions model makes development of extensions slow and limited to predefined interfaces.

re: More IE8 Extensibility Improvements

Aaron — Sat, 14 Mar 2009 07:22:54 GMT

I know its somewhat unimportant, but I found that the ease of use of IE6 far out wieght that of IE7, and used stayed with IE6 just for the purpose of having an easy to use control panel about the address bar. But in IE7 the features I commonly used where moved or taken away, things like the history feature. I haven't gotten a chance to see IE8, but I think it would be simpler to use if the layout was more similar to IE6 than IE7.

re: More IE8 Extensibility Improvements

pete.d — Mon, 16 Mar 2009 02:27:11 GMT

The last comment, by Microsoft, found at the blog article "WebBrowser Control Rendering Modes in IE8", claims (and I quote) "We’ve made a few improvements to our extensibility model in IE8 RC1 based on feedback we’ve received"

Well, you certainly didn't make improvements to the rendering modes for the WebBrowser control based on the feedback you've received. You got clear, unequivocal feedback that a global settings, that doesn't even use any sort of signed/unique identifier for the application is an AWFUL strategy, and that we would much prefer a programmatic API with which to control this.

Even ignoring the issues that have been brought up already, you are completely screwing new applications, which may need to render web pages with different modes, or which need IE8 standards mode in a secure, reliable way, just to preserve backward compatibility.

Not that backward compatibility isn't important, but you REALLY need to come up with a better solution. Such as that already suggested: provide a proper API to control this on a per-instance basis.

re: More IE8 Extensibility Improvements

pete.d — Mon, 16 Mar 2009 02:55:02 GMT

And yet another reason this registry value thing is flawed: when you run your program in Visual Studio, it's actually hosted by the "<program name>.vshost.exe" executable. So to get the IE8 standards mode, you need to add both your regular program name, AND the "<program name>.vshost.exe" name to the registry.

Come on. You can do better.

At the very least, get the X-UA-Compatibility "meta" tag to work correctly, so we have _some_ option that's more reliable and less global than a registry hack.

re: More IE8 Extensibility Improvements

pete.d — Mon, 16 Mar 2009 03:17:34 GMT

That last comment might have made more sense had another comment I'd posted made it through. In particular, while using the X-UA-Compatibility "meta" tag is documented as an alternative to the registry value, it does not appear to have any effect, at least for me.

Which is too bad. Injecting a "meta" tag into the HTML is IMHO not great, but still a better approach than setting some registry value. It allows per-document control over the rendering mode, which is almost as good (and in some cases, better) as per-control control, and provides nearly the same benefit (it's simply less convenient) than an actual API (e.g. new property) in the WebBrowser control.

But, it doesn't work, so I'm stuck using the registry value. YUCK!

re: More IE8 Extensibility Improvements

jiangsheng — Fri, 20 Mar 2009 22:12:47 GMT

Now Visual C++'s add variable wizard is broken... seems it opted it self in whatever feature IE team provides.

Is Visual C++ used by the IE team? This is the second time IE's new feature break Visual C++'s add variable wizard.

re: More IE8 Extensibility Improvements

MenuBox Browser Container — Sat, 21 Mar 2009 06:15:56 GMT

I completely second Viktor Krammer and pete.d. Even we had already posted about this on this same blog, on March 28, 2008.

The application IMHO needs to be able to programmatically choose the compatibility mode at runtime, last but not least because it may be multitasking. Have you never had TWO browser windows open, showing different content? Other API features would also be desirable.

re: More IE8 Extensibility Improvements

Pissed_developer — Mon, 23 Mar 2009 21:31:37 GMT

MSIE8 in release has broken the Add New Projects wizard for Smart Device Projects in Visual Studio 2008, and removing IE8 restored this functionality. Needless to say, IE8 will not be placed on any of my systems anytime soon.

Of course, I know the IE team doesn't use Visual Studio, preferring Source Depot and the internal MS command line build environment. That's fine, but out here in the real world we use VS2008 so fix the problem!

re: More IE8 Extensibility Improvements

Vyacheslav Lanovets — Tue, 24 Mar 2009 22:36:07 GMT

In fact, I filed a bug today against Visual Studio 2008 that IE8 breaks Smart Devices Wizard. I see this on Vista 64-bit. If anyoone can validate in other environments (like 32-bit), please, validate!

https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=426333

The reason why I filed that for VS2008 is because of huge gap I see between qualification of MS developers of desktop tools and MS developers of Windows CE tools. So I beleive this is a bug in Visual Studio 2008 for devices.

Only because I found solution here

http://www.eggheadcafe.com/software/aspnet/32004994/ie8-installation-breaks-v.aspx I did not spend too much time with this problem.

re: More IE8 Extensibility Improvements

EricLaw [MSFT] — Wed, 25 Mar 2009 04:37:19 GMT

@Vyacheslav: We're working with the VS Team to resolve the issue with the VS wizards. Thanks!