Category: IE7

The other day, my wife explained that she has been telling her team to use IE6, since IE7 breaks her ASP.NET application.  She has been keeping this a secret from me, since obviously it is a grave violation of trust between mates.  She came to me only because IT is forcing upgrade of IE7 on her team, and she needed help.

It took me only a few moments to find the problem.  ASP.NET is pretending to issue XHTML and claims to adhere to strict doctype.  At the top of the .aspx page was an XHTML doctype (click the image to see it; curses on WordPresses buggy “security filter”):

I deleted it, and now the site renders the same in IE7 as in IE6.

~

This simple trick should fix your problem.  If you’re interested in hearing why, please read on. 

The short explanation is this: IE7 is far more standards-conformant than IE6, so pages that rely on conformance bugs in IE6 look bad on IE7.  ASP.NET pretends to be standards-conformant, but that really just means “IE6 bug-compatible”.  If you tell ASP.NET to stop pretending, then IE7 says “Oh, this page isn’t really standards-conformant — I’ll render it bug-compatible with older versions of IE”.

So, why does ASP.NET even bother adding that DOCTYPE if it is deceptive?  Well, there are two reasons, neither very satisfying.  The first is that the XHTML political lobby insisted that “XHTML gooood, HTML baaaad”.  So everyone was arm-twisted into emitting XHTML.  The problem is, when the political lobbying started, none of the web browsers actually supported XHTML, they just pretended.  So a server like ASP.NET could choose between emitting code that was XHTML, or emitting code that looked as much like XHTML as possible without breaking Netscape and IE.  Code that looks like XHTML without breaking the browsers is a tiny subset of “actual XHTML”.

Farcial as it may be, it was the best anyone could do, and it got the complainers to stop kvetching.  Now we can all live under the illusion that we support XHTML, even if trivial little changes and isomorphic infosets would break half the world.

The problem is, as soon as you claim to be XHTML, the modern browsers assume that you are also using real CSS.  This goes for Firefox as well as IE.  But IE6 didn’t support CSS properly; so now the GUI web designer tool had two choices:

1. Emit good CSS, so the code that looks good in Opera but not IE6, and maybe looks good in Firefox
2. Pretend to be good CSS (by the DOCTYPE), but emit code that looks good on IE6 and hope it works in Firefox or Opera

It’s clear which choice was made.

Enter IE7.  The newest version of IE, like the newest versions of Firefox and Opera, does a much better job of rendering standards-conformant pages.  Suddenly, writing code that looks good only in IE6 seems like a bad idea.  And even if that wasn’t such a bad idea, pretending that it’s standards-conformant sure seems silly.  It just makes our hard work to adopt standards in IE7 look bad.

Well, that’s the story.  Knowing this, you have two choices:

• Use the legacy design tool and tell ASP.NET to stop pretending that it’s emitting real standards-conformant code.
• Use more modern design tools (like Expression) and let ASP.NET rightly claim that the code is standards-conformant.

 

I whipped up a quick tool to allow Firefox to integrate with Vista’s Common RSS Feed List.  You can download and install it here.

After installing, you need to select “Tools | Options” in Firefox, then click the “Subscribe … using” radio button, the “Choose Application” button.

Browse to C:Program FilesMicrosoftCommon Feed ListCommon Feed List.exe.  After selecting this, you can switch back to “Show me a Preview”.

Now every time you view an RSS feed, you will have the option to subscribe to it using the Common Feed List, which will make the feed show up in Vista Sidebar, Windows Live Mail Desktop, IE7, or any other client you have configured to sync with the feed list.

If you want to look at the source code, you can download it here.

~

When you subscribe using the Common Feed List, you are using the RSS engine built-in to IE7.  Feeds subscribed in this way save your machine bandwidth, since only one copy of each feed is downloaded even if multiple applications use the feed.  You also get multi-machine sync of feeds and read/unread status, and ability to read your feeds in the cloud or on Macintosh or mobile for free.

IE7 on Windows Vista runs in a “sandbox” called Protected Mode, which limits the amount of damage that can be caused by in-process exploits.  Since protected mode is an operating system level constraint applied on a per-process basis, protected mode does not apply to IETab running in Firefox on Vista.  Therefore, if you want Protected Mode, you should use IE7, which includes the subscribe experience shown above by default.

~

Update: The downloads linked above have been updated to support Firefox 3 (Thanks, Warren!).  The code should work on both Vista and Windows 7.  If you need the old version that works with Firefox 2, you can get it here. 

CNET recently wrote a review of Vista, where they complained that “IE7 RSS feeds get preferential treatment”.  They say:

“… there’s a Gadget for subscribed RSS feeds. We downloaded and installed Firefox 2, made Firefox our default browser, and quickly set up a few RSS feed subscriptions. Guess what? The Windows Vista Gadget was unresponsive to our efforts, displaying only the default MSN feeds from Microsoft. You have to use Internet Explorer 7 or choose a Firefox-friendly Gadget instead.”

I understand the disappointment, but this is a limitation in Firefox, not Vista.  And it’s easy to correct.  I would happily help anyone associated with Firefox add the required support.

If the reviewer had instead chosen to subscribe using Bloglines toolbar, Newsgator, FeedDemon, or any of a number of other non-Microsoft RSS readers, they would have seen the subscription update in the gadget.  The subscription in Microsoft Office Outlook and Windows Live Mail Desktop would update, too.  In other words, the fact that the gadget is able to share the feedlist is a demonstration that we have made the shared feedlist totally open — and plenty of ISVs already take advantage of this fact.

Firefox isn’t actually an RSS engine, which is why the reviewer seems confused.  Firefox simply allows you to associate feeds with an external reader.  On Vista, any app which wishes can register to tap into the shared feed list, and we support any number of applications all sharing the same list.  Allowing FF to register the shared feedlist on Vista as an external app would be trivial, and would enable Firefox to better integrate with the whole ecosystem of RSS readers — including cross-machine and cloud sync as supported by Newsgator.

I understand why Firefox might be hesitant to integrate with the shared feedlist.  It’s not available on Linux, after all.  But it’s certainly not a MSFT-only feature — in fact, quite the opposite.  It’s the feature that opens up our RSS platform to a whole ecosystem of vendors who are already taking advantage.

~

Update: I wrote the ten lines of code necessary to make Firefox integrate with Vista’s RSS platform.  Here it is.

Two cool articles on Ajaxian today.  One discussing ways that JSON is replacing XML as data transport for some web scenarios, and another showing how XML Data Islands can let you grab XML without needing to explicitly parse with MSXML.

If you’re using the code sample for launching a low integrity process in the protected mode for Internet Explorer whitepaper, you may be getting an error that complains about RtlLengthSid.  We’re working to update the code sample.  In the meantime, look at the code below.  You’ll have to add all of your own error checking, but you can get the basic idea:

#include “windows.h”
#include “Sddl.h”

__cdecl main(/*int argc, TCHAR argv[]*/)
{
   BOOL                  b;
   HANDLE                hToken;
   HANDLE                hNewToken;
   PWSTR                 szProcessName = L”c:windowsnotepad.exe”;     // For example
   PWSTR                 szIntegritySid = L”S-1-16-4096″;  // Low integrity SID
   PSID                  pIntegritySid = NULL;
   TOKEN_MANDATORY_LABEL TIL = {0};
   PROCESS_INFORMATION   ProcInfo = {0};
   STARTUPINFO           StartupInfo = {0};
   //ULONG                 ExitCode = 0;

   b = OpenProcessToken(GetCurrentProcess(),MAXIMUM_ALLOWED, &hToken);
   b = DuplicateTokenEx(hToken, MAXIMUM_ALLOWED, NULL, SecurityImpersonation, TokenPrimary, &hNewToken);
   b = ConvertStringSidToSid(szIntegritySid, &pIntegritySid);
   TIL.Label.Attributes = SE_GROUP_INTEGRITY;
   TIL.Label.Sid        = pIntegritySid;

   // Set the process integrity level
   b = SetTokenInformation(hNewToken, TokenIntegrityLevel, &TIL, sizeof(TOKEN_MANDATORY_LABEL) + GetSidLengthRequired(1));

   // Create the new process at Low integrity
   b = CreateProcessAsUser(hNewToken, szProcessName,NULL, NULL, NULL, FALSE, 0, NULL, NULL, &StartupInfo, &ProcInfo);
   return 0;
}

Dare is on a roll, complaining about the RSS experience in IE7. He points to a bunch of people who say that IE7 isn’t an RSS aggregator, and then for good measure, posts again saying that IE7 isn’t like RSS Bandit (an RSS aggregator).

In fact, a week earlier, Jane Kim (PM for RSS in IE7) posted to Dare’s blog, explaining that IE7 is not an RSS Aggregator. Are you noticing a pattern here?

Dare says as much; IE7 was not intended to replace tools like RSS Bandit, NewsGator, or Outlook 12. It’s not a matter of trying to keep small ISVs in business, as much as a decision to put the RSS-Bandit style reading experience in the products where it belongs; namely Outlook and OE. IE7 doesn’t read NNTP feeds either; that’s what OE is for.

As for the argument that “you only have one chance to make a first impression”, I would just note that the orange XML icon has been on thousands of web sites for a long time. People already have an impression of what happens when they click on that thing. The user experience in IE7 is vastly better than IE6, especially with feeds that have some metadata. And the glide path from IE into an Aggregator like Outlook 12 or RSS Bandit is much shorter.

Now, you can argue that MSFT should build a full RSS Aggregator into IE. I would disagree (is Thunderbird hosted in a Mozilla frame?), but you can argue that. And you can argue that Microsoft should have delayed IE7 until Outlook 12 shipped an integrated aggregator experience, or you could even argue that IE7 shouldn’t have shipped without . But you can’t argue that the user experience for RSS in IE7 isn’t vastly better than IE6 for users and aggregator vendors alike.

Get it at http://www.microsoft.com/windows/ie/ie7. This release is primarily intended to help web site designers and extension developers prepare for the broad release of IE7 Beta and RTM in coming months. I have been using IE7 builds exclusively for several months, so it is possible to do this, but we are aware of a number of issues that will need some attention by site owners and developers prior to RTM. Check out IEBlog for more.

We’ve announced that the RSS platform in Vista will permit only well-formed XML. Most people are celebrating, but there are some comments that indicate some people may be confused.

To clear things up, this statement is ONLY about well-formed XML. It is NOT a statement about validity, or conformance to any other spec, including any RSS/Atom spec. Per the XML spec, well-formed is a very specific definition. If a document is not well-formed, it is not XML, period. A document can be invalid, yet still be well-formed, but if it’s not well-formed, it is never going to be valid, and is not RSS or Atom either (since it’s not XML).

Sam Ruby (who is not confused)responds positively to the news, and asks “Question: how will IE7 deal with Priorities in the Presence of External Encoding Information?” He’s talking about RFC 3023, which is referenced in appendix F of the XML spec. This is a non-normative reference, and is not a wellformedness constraint (nor a “must”), but it’s worth responding.

The short answer is that we do not implement RFC 3023 currently. The RSS platform uses MSXML (inXML conforming mode)to fetch and parse the data, so the behavior is inherited from MSXML. Since MSXML is used by most products that we ship, it means the platform is consistent. And nearly every other stack in the industry ignores RFC 3023 as well, so it’s not a widely accepted interop point at the moment.

The longer answer is that there are good arguments for having a well-defined standard for handling external encoding information. Without a spec that all of the vendors implement, the matrix of interop for edge cases can be pretty complex. However, I don’t think RFC 3023 in current form is a good starting point. Implementing would break a large chunk of the web, and the spec could easily be modified to be just as useful without breaking so many feeds. No vendor is going to unilaterally adopt RFC 3023, because it would mean their products would croak while their competitors’ continue to work. By the same token, the RSS platform is not going to unilaterally deviate from what MSXML does, because it means you would get behavior inconsistent with the rest of Microsoft products.

So, “well-formed” is a conservative bet, since practically everyone requires it anyway (it’s very, very difficult to read non-WF on Microsoft stack now). Requiring RFC 3023, on the other hand, would be attempting to make a much bigger change to current state of the web, and not likely that the RSS platform alone is in a position to force such a sea change. Such a change would need to be made lockstep across the whole Microsoft platform, and in concert with others in the industry.

As has been reported, IE7 consolidates URI parsing code into a single library. I’ve been playing with this a bit. To IE6, the following 6 URIs are equivalent. To IE7, only 5 of the 6 are the same:

1. file:/c:/foo bar/x.txt — IE6 Works, IE7 Works
2. file:/c:/foo%20bar/x.txt — IE6 Works, IE7 Fails
3. file://c:/foo bar/x.txt — IE6 Works, IE7 Works
4. file://c:/foo%20bar/x.txt– IE6 Fails, IE7 Fails
5. file:///c:/foo bar/x.txt– IE6 Works, IE7 Works
6. file:///c:/foo%20bar/x.txt– IE6 Works, IE7 Works

Since it impacts the single slash file:/, it doesn’t appear to impact http:// URIs.

~

Update: more on this at http://blogs.msdn.com/freeassociations/archive/2005/05/19/420059.aspx.

Wow, it’s nice to see the folks at positioniseverything endorsing the demise of CSS hacks in IE7.

Second to useragent string detection issues, CSS hacks that used to work in IE6 but no longer work in IE7 (due to CSS fixes) will probably be the most common cause of compatibility issues for IE7, and will cause some short-term pain to existing sites that use the hacks. The long term benefits of having IE support more of CSS for new site development, however, are large. Thanks to p.i.e. for keeping sight of this important point.