IE9 RC Minor Changes List

Artykuł
02/11/2011

Back in September, I published a list of minor changes in IE9 Beta. In today’s post, I will provide an updated list of things that have changed in the IE9 Release candidate. Note: This list also includes a few changes that were present in Beta that I didn’t mention at that time. 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.

Improvements in IE9 that impact issues or features previously discussed on this blog can be found by searching for the tag BetterInIE9.

Standards / Interop Improvements

Navigation triggered by window.location manipulation now sends a HTTP Referer header.
The postMessage() API now has asynchronous behavior for IE9 mode pages.
IE9 respects a FavIcon specified using a LINK REL="ICON" element (not requiring REL="SHORTCUT ICON") if a TYPE attribute is present with value "image/x-icon". Update IE11 dropped the type attribute requirement.
When in IE9 Browser Mode, IE now sends context-specific ACCEPT headers.
globalCompositeOperation support was added to CANVAS.
CANVAS supports toDataURL() after drawing same-origin VIDEO content. Note: The toDataURL() method incorrectly returns a trailing null byte at the end of the string; the fix for this just missed the RC build.
Several network cache correctness (age vs. max-age, Expires < Date) and clock-skew issues were fixed.
In IE9 standards-mode only, we now always encode FORM data as UTF-8 if the Accept-Charset attribute is present with the value “UTF-8”. The design of FORM encoding in IE8 and earlier was to use the encoding of the submitting page by default. IE8 and earlier submit the form data using UTF-8 only if the FORM specified Accept-Charset=UTF-8 and the form contains some text that cannot be encoded in the page's encoding.
IE8 and IE9 Standards mode now correctly handle BASE tags that use the file:// protocol.
When uploading files from pages in IE9 document mode, IE will no longer send PNG and JPEG files with the pre-standards MIME types (image/x-png and image/pjpeg). Instead, IE will send image/png and image/jpg. Behavior in legacy modes is unchanged.
SCRIPT tags now fire an onload event.
File downloads may specify non-ASCII names by adding a filename* token to the Content-Disposition: attachment header. IE9 supports RFC5987 for UTF-8 filenames in the filename* parameter.
For IE9 Browser Mode, localStorage and sessionStorage evaluate the protocol/scheme when isolating storage per-origin.
The intrinsic size (up to 128x128) of a custom cursor is respected in IE9 document mode. Legacy IE modes scale all cursors to 32x32.
window.prompt() no longer triggers a security warning when called from the Internet zone.
Input and button elements inside anchor tags will now navigate if clicked.
The XMLHttpRequest object will create a responseXML document property if the server returns a MIME-type ending in +xml. Previously, the document would only be created for text/xml or application/xml.
FTP View now works properly with Unix FTP servers that have advanced permissions set.

Networking

SOCKS v4 proxies are supported again after being broken in IE9 beta.
Visiting pages on the Visual Studio Test Server (e.g. by hitting F5 in an ASP.NET web project) no longer shows Page Cannot Be Displayed errors (Connect #601047)
The FindMIMEFromData function used for MIME-sniffing now ignores any querystring component in pwzURL, if present.
Premature FIN detection was removed from WinINET. This is the subject of a future blog post .
Space characters embedded within Download filenames are no longer replaced with underscore characters.
Executable file downloads are no longer renamed when run from the cache.
When evaluating which, if any, registered MIME Filters to load, URLMon will now ignore the charset attribute in the server-specified Content-Type header.
If IE encounters a file download that is delivered with the wrong MIME type and is sniffed to .ZIP, it will not treat that file as a zip file if the file extension is on a list of known formats that are ZIP-derived. That list contains [".zipx", "accdt", "crtx", "docm", "docx", "dotm", "dotx", "gcsx", "glox", "gqsx", "potm", "potx", "ppam", "ppsm", "ppsx", "pptm", "pptx", "sldx", "thmx", "vdw", "xlam", "xlsb", "xlsm", "xlsx", "xltm", "xltx"].
Fixed IE9 Beta introduced regression whereby content delivered via the RES protocol was interpreted using an incorrect MIME type. That bug broke a number of applications.
For a file delivered as text/plain, if non-text characters are found (octets outside the 9-13, 27, 31-255 range), IE will treat the file as not really being text/plain and will trigger a file download dialog.
Downloaded files can now be saved from HTTPS sites even when sent with no-cache headers.
The XDomainRequest object no longer always fails when IE is running in InPrivate Browsing mode.
The proxy bypass list now supports a <-loopback> token enabling proxying of traffic sent to 127.0.0.1 or localhost.
When constructing the UserAgent string, IE9 no longer reads the Pre and Post Platform registry keys under \Internet Settings\User Agent\ . It only reads those keys under \Internet Settings\5.0\User Agent\ .
The about URL protocol no longer triggers Mixed Content Notifications.

Security

The prefix JavaScript: is stripped from any text pasted into the IE9 address bar. This mitigates a socially-engineered XSS attack common on social networks wherein users were tricked into performing self-inflicted XSS injections upon themselves. No, CTRL+C,ALT+D,CTRL+V, ENTER will not give you magical powers.
Interoperable :visited link protection was added to mitigate CSS History Probing. Unsupported styling patterns are now logged in the F12 Developer Tools console.
CSS MIME-type validation introduced in IE9 Beta was extended. Now, regardless of document mode or origin, if X-Content-Type-Options: nosniff is specified, the “stylesheet” MUST have a Content-Type of text/css or it will not be applied.
Pinned Site Mode treats certificate errors as fatal (with no override link). Combined with the fact that the pinned site itself can be pinned with a proper HTTPS URL, several “man-in-the-middle” threats are thwarted when a secure site is pinned to the taskbar.

Miscellaneous Changes

The window.navigator.appMinorVersion value was changed from “Beta” to “RC”. For the final release, it will be set to “0”.
In-place shell navigation within the Web Browser Control is no longer blocked.
.NET Framework XAML Browser applications (XBAPs) no longer run from the Internet zone; they still function in the Local Intranet and Trusted Zones.
The Format JavaScript option was added to F12 Developer Tools Script tab configuration button.
Direct Intranet Navigation is now possible. The Go to an intranet site for a single word entry option was added to Tools > Internet Options > Advanced. This allows you to prefer Intranet-navigation over automatic search behavior.
Drag/drop of favicon to desktop create and launches "sitemode" browser instance. Hold SHIFT to get the legacy behavior of adding a basic shortcut.
After forced restart (Windows Update), IE9’s tabs will be correctly restored.
IE9 features improved support for “Bookmarklets”—URL length limits were relaxed and several security prompts were tuned.
The New Tab Page no longer omits HTTPS pages unless the option “Do not save encrypted pages to disk” is set.

Performance Improvements

Myriad network performance improvements were made. These will be subject of an upcoming post on the IEBlog.
Major performance improvements were made to the XSS Filter.
Major improvements were made to performance of many CANVAS operations.
Significant responsiveness improvements were made when a CSS download is pending.
Find-on-page performance (especially when searching large documents) is dramatically improved.

You can read about other changes at IE9 on MSDN and examine the IE9 RC Release Notes. The team will be posting deep-dive details about major new features in IE9 over on the IEBlog.

That's it for now… I hope you enjoy the IE9 Release Candidate, available for download here.

-Eric

Comments

Anonymous
February 11, 2011
The comment has been removed
Anonymous
February 11, 2011
@Mathias: No, without the TYPE attribute we won't try to use "icon", only "shortcut icon". The problem is that some sites point to a .PNG or GIF or other unsupported format. We use "image/x-icon" because that's the MIME type we've always used. Someone at some point (AFAIK, not related to Microsoft) proposed registration of the MIME type as "vnd.microsoft.icon", but Windows doesn't actually use that, it uses image/x-icon.
Anonymous
February 11, 2011
> The problem is that some sites point to a .PNG or GIF or other unsupported format. Wouldn’t it be possible to check the Content-Type header of the icon to see if the MIME type is supported if the type attribute is omitted?
Anonymous
February 11, 2011
@Mathias: It certainly would be possible (it's just code! :-), but that creates additional network traffic (additional round-trip) and a potential time delay (waiting to download the "shortcut icon" version after the "icon" version has failed).
Anonymous
February 11, 2011
What's the difference between "shortcut icon" and "FavIcon"?
Anonymous
February 11, 2011
@KS: "FavIcon" is our name for the overall feature that assigns an icon to a site. "Shortcut Icon" is the name of the META tag that IE5/6/7/8 look for, while "Icon" is what other browsers tend to look for.
Anonymous
February 11, 2011
The comment has been removed
Anonymous
February 11, 2011
The comment has been removed
Anonymous
February 12, 2011
Eric, one of the most annoying problems I'm facing with an otherwise wonderful IE9, is the inability to run add-ons on pinned sites. I think pinned sites is one of the killer features of IE9, and I have quite a few of them pinned. But unfortunately add-ons like spellcheckers and adblockers don't run on those pinned sites. This is really frustrating. I understand it is a good idea to disable browser toolbars for pinned sites, but spellcheckers and adblockers are just as important on pinned sites as they are on the main browser. So, please consider giving an option to run add-ons in pinned sites. Or, can you please suggest an workaround with the registry? Thank you.
Anonymous
February 12, 2011
@Jonas: Sorry, there's no option or registry switch for that.
Anonymous
February 12, 2011

For a file delivered as text/plain, if non-text characters are found (octets outside the 9-13, 27, 31-255 range), IE will treat the file as not really being text/plain and will trigger a file download dialog. What is the behavior when the content is delivered as Unicode text? I wouldn't expect that behavior for UTF-16, especially given your use of the word octet.

Anonymous
February 12, 2011
> Pinned Site Mode treats certificate errors as fatal (with no override link). Combined with the fact that the pinned site itself can be pinned with a proper HTTPS URL, several “man-in-the-middle” threats are thwarted when a secure site is pinned to the taskbar. Thanks, I can no longer pin my intranet sites.
Anonymous
February 13, 2011
@Alvaro: Sounds like your Enterprise PKI deployment is broken. Your IT admin should configure their root certificate authority as Trusted using Group Policy. Without this step, there's no point in using HTTPS at all, as content can be trivially intercepted and read/modified.
Anonymous
February 14, 2011
@Warren: Good question. In the case of Content-Type: text/plain; charset=utf-16, the file will be treated as a download. That hasn't changed vs. IE8, and Chrome 9 behaves the same way. Firefox4 and Opera11 render the text inline.
Anonymous
February 14, 2011
Hi Eric, Regarding the item for the XBAP, could you elaborate on why the IE team disabled this? I'm thinking that a prompt dialog would have been a better trade-off. Show prompts for full trust XBAPs and no prompts for other XBAPs. Thanks!
Anonymous
February 14, 2011
@Phong: XBAPs are a super-interesting technology, but not one that has gotten much adoption on the Internet. Among the top 100,000 most popular sites, there are zero instances of XBAPs. We believe XBAPs are more commonly used within corporate intranets, which is why this technology remains enabled in the Intranet and Trusted Zone. While prompting seems like a straightforward compromise, we've been working very hard to avoid introducing new security dialogs. Such dialogs are both unpopular, and users often don't make good trust decisions when presented with them. In contrast, ClickOnce deployment is a more commonly-used model.
Anonymous
February 14, 2011
@Eric: Agreed with the decisions. We will bypass this by adding the URL to a Trusted Zone with our Group Policy. I agree that XBAP is a super-interesting technology and does not get much spotlight. We use it heavily at ImageSource, Inc within our ILINX products.
Anonymous
February 15, 2011
Although XBAPs aren't commonly used by the big sites, hundreds of our customers use it daily! They are on the internet, our XBAP is running securely under partial trust, and everyone is happy. This change is forcing us to switch to a ClickOnce deployment which we would have to retest, redeploy, and convince our users is as secure as the XBAP. And the application will no longer run within the IE frame... When we committed to the XBAP technology, there was no reason to believe Microsoft wasn't committed to it as well. Please re-enable XBAPs in the IE9 Internet zone, at least for partial trust applications.
Anonymous
February 15, 2011
@Tor: I'm very interested in learning more about your hundreds of customers. What Internet-Zone sites are your XBAPs in use upon? Thanks!
Anonymous
February 15, 2011
<em> - If IE encounters a file download that is delivered with the wrong MIME type and is sniffed to .ZIP, it will not treat that file as a zip file if the file extension is on a list of known formats that are ZIP-derived.</em> Any chance of .jar being added to this list?
Anonymous
February 16, 2011
[Some Firefox dude wrote a rant bashing IE] Needs a reply? people.mozilla.com/.../ie9 IMHO, as a simple non-WEB developer, IE9 RC is very good and has "good" standards support. It can be improved of course. Just a question: where is the important notification 'Protected mode: On/Off' gone? The status bar is empty.
Anonymous
February 16, 2011
@Hexaae: There already was a reply: blogs.msdn.com/.../a-modern-browser.aspx. The protected mode notification is on the page's Properties dialog. Right-click a page and choose Properties.
Anonymous
February 16, 2011
Eric, I am glad to see in page search preformance is improved but please take a quick look at at this site. (www.cisco.com/.../481rn.html) I still see slowdowns on this page although its much improved from IE 8,
Anonymous
February 17, 2011
@EricLaw Thanks! I didn't notice... anyway I hope you'll reintroduce a better warning/notify for such an important security feature the users will easily keep monitoring. [Sorry for the misunderstanding, I didn't want to bash IE of course. Was just curious about a MS reply to that Mozilla Evangelist... thank you for the reply!] @typhoon87 Perhaps you should report the problems using MS Connect: click on the "gear" to the upper-right and choose "Send feedback"...
Anonymous
February 17, 2011
"IE9 features improved support for “Bookmarklets”—URL length limits were relaxed and several security prompts were tuned." Sounds great! - what are the new limits (was 504/512) - and which prompts changed? (I did notice that users/developers can now drag bookmarklets to their toolbars finally! :-D
Anonymous
February 18, 2011
Speaking of minor changes... In certain sites it is very common to truncate the beginning of http links as "ttp", as some sort of cheap referer-hiding method. A couple of hastily collected samples: yuzuru.2ch.net/.../118 yuzuru.2ch.net/.../526 IE8 used to automatically add the missing h whenever you copy pasted one of those links to the address bar and navigated to it. Now IE9 instead converts the "ttp" to "ftp", which is far less useful in my opinion. Can we get the IE8 behaviour back? I reckon pasting truncated addresses must be more common than somebody miss-typing ftp as ttp. Further, other users at the IE blog have commented about the Paste & Navigate feature and how it would be nice to have "Copy, Paste & Navigate" whenever you have an address selected in the client area, and I agree entirely. Coupled with the above request, I would appreciate if "ttp" addresses were recognised and one was able to "Copy, Paste & Navigate" to them. Opening them in a new tab as an option would be even better. Lastly (since we're dreaming and all), an option to not switch to the newly created tab would be the icing on the cake. The RC is great. Keep up the quick improvement rate, thank you.
Anonymous
February 18, 2011
@Tino: Using "hxxp" still works. FWIW, you might like my "Linkify and Open" context menu extension published at http://www.bayden.com/ietoys/. This is designed exactly for the scenario where a site has deliberately not linked a given string, and it performs a very-aggressive protocol fixup.
Anonymous
February 18, 2011
The comment has been removed
Anonymous
February 18, 2011
@EricLaw: Linkify works like a charm, thanks!
Anonymous
February 19, 2011
I like IE9 RC, but it breaks the mshtml document "DesignMode = "On". My html editor is now ReadOnly. :-(
Anonymous
February 19, 2011
Hi....I have IE9 RC and I'm coming across this pop up from Internet Explorer that says Internet Explorer has modified this page to help prevent cross site scripting. How do I disable it on there cause really can't find out anything...I've looked but to no avail...thanks and hope to hear back from someone soon!!
Anonymous
February 19, 2011
@Don: The XSS Filter is a security feature. You shouldn't disable it; it keeps you safe from Cross-Site-Scripting attacks. You should notify the webmaster of whatever site you see this on that they have a security bug.
Anonymous
February 19, 2011
@Walter: Repro URL please?
Anonymous
February 20, 2011
>> @Tor: I'm very interested in learning more about your hundreds of customers. What Internet-Zone sites are your XBAPs in use upon? Thanks! << @Eric: Sorry for the delay, I've been traveling for a few days. Our customers are Norwegian homeware/furniture retail stores. The users are are navigating to our web site (http://www.langlo.no) and starting the XBAP from there (login information required). We have not had to specify any specific internet zone or other settings for the users, I don't think they even know what that's all about. They are just using IE, and this is of course the great advantage here - the comfort zone and familiarity of IE combined with the power of WPF (incl. 3D) and a full .Net XBAP application under "the hood". Running under partial trust restriction has also allowed us to deploy the application without any problems or objections from our customers' I.T. departments.
Anonymous
February 20, 2011
@Eric: Windows application using the mshtml in a WebBrowser control. Checked out another one, has the same result. Ignores the DesignMode = "On" www.codeproject.com/.../ZetaHtmlEditControl.aspx
Anonymous
February 20, 2011
@Walter: There's something else going wrong in his code. If I set the following code: private void cbDesign_CheckedChanged(object sender, EventArgs e){ var instance = Microsoft.VisualBasic.CompilerServices.NewLateBinding.LateGet( wbView.ActiveXInstance, null, @"Document", new object[0], null, null, null ); var objArray1 = new object[] { cbDesign.Checked ? @"On" : @"Off" }; Microsoft.VisualBasic.CompilerServices.NewLateBinding.LateSetComplex( instance, null, @"designMode", objArray1, null, null, false, true ); The IE9 Web Browser instance enters designMode without any problems. If you change the "Zeta" example to not set the document text after entering design mode, it also works fine.
Anonymous
February 20, 2011
Thanks EricLaw .......this is happening on facebook and only when I try to post or share anything to get posted to there live feed and it just started on Friday.....before that it was fine. So I will get in touch with facebook and tell them they have a security bug in there system. Once again thank you for the info.....have a great Monday!!!
Anonymous
February 22, 2011
As you stated in the Stack Overflow posting, I modifed my code. I tried a thousand different things to no success. So if anyone else stumbles upon this blog posting and has a solution, I would love to read it!
Anonymous
February 22, 2011
@Uwe: As I mentioned, this code works just fine for me. If you look at what the Zeta example does, it resets the designMode attribute a bunch of times during the DOM manipulation (as the HTML is added). If you have a simple Web Browser Control based application, the simple code above works just fine.
Anonymous
February 23, 2011
@Eric Yes, I know and really welcome your feedback! I just cannot get it to work. It is really weird to me that the same test app produces different results on different machines. http://twitpic.com/42ygnb/full
Anonymous
February 23, 2011
Internet Explorer 9 doesn't offer the option to open a html and mht documents served with content disposition attachment, in te save dialog. Can you restore this option? Thanks
Anonymous
February 23, 2011
@Michelle: If you choose SAVE, you can then choose OPEN directly from the dialog. In most cases where HTML content is served with Content-Disposition: attachment, the server is attempting to protect itself against untrusted content running in its security context. By saving the file locally first, this threat is mitigated because the reopened file will not run in the security context of the delivering site.
Anonymous
March 20, 2011
In the beta, if you went to Properties of a Pinned Site, you could change the icon and URL etc. In the RC, this Property Sheet was removed? [Ericlaw: The reason was that the dialog created problems with managing tasks that were defined by the site but didn’t match the startURL changed by the end-user. After removing this functionality, the only use for the dialog would’ve been changing the icon of the image. We couldn’t justify supporting a dialog to update only the icon.]
Anonymous
April 07, 2011
The comment has been removed

Udostępnij za pośrednictwem