Please read my blog's comment policy here.
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.
The about URL protocol no longer triggers Mixed Content Notifications.
The New Tab Page no longer omits HTTPS pages unless the option “Do not save encrypted pages to disk” is set.
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.
> IE9 will download the FavIcon for a LINK REL="ICON" tag if a TYPE attribute is present with value "image/x-icon".
Theoretically, <link rel=icon href=foo.ico> (without the `type` attribute) should work too. Will this work in IE9?
Also, why `image/x-icon`? I thought the correct MIME type for favicons was `image/vnd.microsoft.icon`.
@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.
> 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?
@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).
What's the difference between "shortcut icon" and "FavIcon"?
@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.
@Parashuram: Because the user can easily type the protocol-specifier back into the address bar directly and get the execution behavior. There's really no warning prompt we could show the user that they would understand.
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?
@Jonas: Sorry, there's no option or registry switch for that.
- 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.
> 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.
@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.
@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.
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.