Please read my blog's comment policy here.
In every release of the browser, we make many major feature investments, most of which you can read about in posts over on the IEBlog. However, we also make thousands of small improvements that are often overlooked or not broadly recognized. In this post, I will provide a partial list of some of these small improvements which I think are most interesting. Improvements in IE9 that impact issues or features previously discussed on this blog can be found by searching for the tag BetterInIE9.
Of course, because there are thousands of changes that I will not be covering, please do not mistake this for a comprehensive list, and please note that I'm deliberately skipping over the big feature improvements that will be discussed on the IEBlog over the next few months.
ActiveX Phoenix Bits As explained over on the Security Research and Defense blog, a Phoenix Bit allows an ActiveX control developer to release a new version of a control which was previously killbitted to block exploit of a security vulnerability. The Phoenix Bit is a simple mechanism in which the developer specifies (via the registry) an AlternateCLSID for IE to load when web content is found with a reference to the original, killbitted CLSID.
var obj = new ActiveXObject("clsid");
var obj = new ActiveXObject("clsid");
Internet Explorer User Interface
You can read about other IE9 changes over in the IE9 Cookbook on MSDN.
That's it for now… I hope you enjoy the IE9 Beta, available for download here.
Update 2/11/2011: I've just posted the IE9 RC Minor Changes list.
In regards to "to match updated user-interface guidelines", are you referencing the "Windows User Experience Interaction Guidelines"? I've been studying that document lately, and I'm curious if IE uses the same guide?
Otherwise, thanks for another great post. Awesome info here!
@Ken: Yes, that's the one. Sometimes IE is a bit different because we run on multiple different versions of Windows (which may have different UX guidelines) but as we're now on Vista+, I think we're simply trying to follow the latest guidelines.
The relevance of using data URIs in script tags can best be shown in a test case. In the test case below, I test support for the defer script attribute:
dl.dropbox.com/.../test.htm (1 file that tests external scripts support of the defer attribute)
This test case works for every non-IE browser.
Eric: Note that this test case is invalid, and that's why it doesn't work in IE9. Specifically, the DATA URIs are malformed and not legal URLs. To resolve this, properly URL-encode the characters that require encoding.
Here is an IE compatible test case:
dl.dropbox.com/.../test-ie.htm (9 files [1 .htm + 8 .js] that tests external scripts support of the defer attribute)
Specifying the script as a data URI changes the browser to treat the file as an external resources. This affords it all the restrictions, privileges, and attributes that don't apply to inline scripts.
If I were submitting this test case to a bug, it would be much more convenient to submit the single file.
It's absolutely possible to invent uses for using a DATA URI as the source of a SCRIPT element, although most such uses are completely contrived.
I'd be very interested to learn what "restrictions, privileges, and attributes" you believe apply to "external resources".
"The XMLHttpRequest object no longer enforces a strict list of what methods may be used. The only forbidden methods are TRACE and TRACK."
That sounds great, but my tests do not show any change in behavior. Maybe the change didn't make it into this beta?
some tests are at
In the meantime I learned that to get the latest and greatest behavior, the page needs to be in standards mode (which the above is not). I tested this locally, and sure enough, all these HTTP verbs (except TRAC*) now work.
@Julian: clarified, thanks!
WM_HTML_GETOBJECT seems to be buggy in IE9 Beta. For some sites, it works correctly, however, for others, it doesn't return a IHTMLDocument but a strange JScriptTypeInfo object. I found out also that OneNote 2010 no longer captures the URL of a Web page when saving a screen clipping from IE9 windows. Perhaps they might also be affected by the broken behavior of WM_HTML_GETOBJECT in IE9.
I wanted to provide feedback on the address bar/tab area and I thought you might be a good person to mention this to. I find the way that Chrome has the tabs on the top and the address bar below is much more intuitive. I find that I end up shrinking the address bar to make room for the tabs and then I cannot see much off the address bar any more. These two sets of controls seem to always compete with each other. Also, in full screen mode Chrome tends to look better and less cluttered when the address bar is below the tabs. I do think that this is a serious issue and could be easily remedied or offered as a customization so that the user could drag the address bar below the tabs and keep it that way.
Thanks for looking into this and outside of this UI issue, IE9 Rocks!
Alan, your feedback is shared by many. However, unless there's a bug on Connect that collects votes, I think it will be hard for the User Experience team to get a good sense of exactly how broadly the feedback is shared. As I mentioned (blogs.msdn.com/.../ie8-removed-inline-autocomplete-for-the-address-bar.aspx), in IE8, the removal of Inline Autocomplete yielded only 16 votes.
@EricLaw: Per the spec, the defer attribute only applies to external scripts. So I could A) make an external file and refer to it or B) construct the script in a way to make the browser treat it like an external script (read: data URI). That's what I'm referring to by privileges reserved only for external scripts.
@fearphage: I'm not sure what spec you're referring to. DEFER was defined in HTML4.01, and it's simply defined as "-- UA may defer execution of script --". There's nothing that indicates that it applies to only external scripts.
While not actually a showstopper, I thought I'd report this anyway: In editMode, in the Create/Edit Hyperlink dialog box (inkoved by htmlDoc.execCommand('CreateLink'), IE9 still lists the gopher protocol in the Hyperlink Type combo box :-)
And yes, I think EricLaw is the RaymondC of the IE team ;-)
"The async and defer attributes are boolean attributes that indicate how the script should be executed. The defer and async attributes must not be specified if the src attribute is not present."
Maybe things have changed or they are changing? I'm not sure.
If a non-W3C group is redefining existing standardized attributes to mean something else, that's feedback I'd encourage you to provide to them.