Update to Internet Explorer’s Cookie Jar

As a part of the August Cumulative Update for Internet Explorer, a small enhancement was made to Internet Explorer’s HTTP Cookie handling. This post describes that enhancement, and presents some other considerations for using cookies on your site. A knowledge base article referencing this change can be found here.

Background

In the past, IE’s cookie jar stored a maximum of 20 cookies per domain. If more than 20 cookies were sent by the server, older cookies were automatically dropped by the browser. The dropped cookies could lead to lost website settings, an empty web shopping basket, or similar problems. In order to store more than 20 name-value pairs per domain, web developers were forced to create a “dictionary cookie”, a single cookie that contains multiple name-value pairs. Creation of dictionary cookies is described in this Knowledge Base article.

Note that IE’s cookie limit is applied on per-domain basis. If http://example.com sets 20 cookies, each with Domain=example.com, and http://subdomain.example.com also sets 20 cookies, each with Domain=subdomain.example.com, then 40 cookies will be sent on subsequent requests to subdomain.example.com.

New Cookie Limit

As a part of the Internet Explorer update announced yesterday, the cookies per domain limit has been increased from 20 to 50. This change was made to simplify the development and hosting of web applications on domains that use a large number of cookies.

Please note that even after installing this update, two other cookie limits remain unchanged:

The DOM's document.cookie property will return an empty string if the current cookie string is longer than 4096 bytes

For functionality and performance reasons (discussed next), it’s recommended that you continue to use the smallest cookies possible.

Watch Your Weight

You might be tempted to take advantage of the new higher cookie limit and add more cookies to your site. Unfortunately, cookies can dramatically impact the size of HTTP requests, slowing down the user’s browsing experience significantly. Many of today’s web users have connections with asymmetrical bandwidth, having download speeds 2 to 5 times faster than their upload speeds. This means that in some cases, HTTP request size is a more important factor than the size of the server’s response in determining overall transfer time.

There are three strategies you can use to minimize the impact of cookies on your site’s site performance:

Minimize the size of your cookies

Deliver static content from a different domain

Use the Path attribute to send cookies only when necessary

The first strategy is simple: use the shortest cookie names and values possible. For instance, rather than naming a cookie USERNAME, name it U.The seven bytes saved might not sound like much, but multiplied over dozens or hundreds of requests, these savings can add up.

The second strategy can yield even better results, particularly if your pages use many static resources (images, CSS, JS, etc) that do not change based on the value of the visitor’s cookie. For instance, if you use the Fiddler Web Debugger to look at the Office Online clipart site, you’ll see that the static clipart images are delivered from http://officeimages.microsoft.com rather than http://office.microsoft.com. This means that the relatively large cookie set on office.microsoft.com isn’t sent when requesting each clipart thumbnail, saving more than 2K of request bytes per page of search results.

The last strategy is similar to the second, except that you can undertake it with just one domain. If you can keep all of your pages that need access to cookies within a single path (e.g. http://example.com/webapp/) you can use the Path attribute on the cookie to specify that the cookie should only be sent for requests within that path. This will ensure that requests sent outside of that path (e.g. http://example.com/images/) are not forced to carry unneeded cookies.

You can easily use Fiddler to monitor your uploaded cookie sizes. Inside Fiddler, click Rules > Customize Rules. Scroll down to OnBeforeResponse, and add the following line:

After you save the script, the size of the uploaded cookie (if any) for each request will be shown in the User-defined column at the far right side of the Web Sessions list.

Protecting Your Cookies

While you’re looking at your cookie code, you should determine if you need to expose your cookies to scripts running on your site. If your cookies are only used by your server, and your scripts don’t require access to your cookies, use the HttpOnly attribute to help protect your site against cookie theft via cross-site scripting attacks. Simply add the HttpOnly attribute to your Set-Cookie headers, and Internet Explorer will ensure that your cookie is not available to any script running in your pages. Cookies with the HttpOnly attribute are still sent in each HTTP request, but will not appear in the script-accessible document.cookies property. This means that if a hacker finds a cross-site scripting hole in your site, he cannot easily use the hole to steal logged-on visitors’ cookies.

Over the coming months, I’ll be posting more tips for developers. If you have any suggested topics, please leave me a comment below. Thanks!

The 4096 byte limit on cookies from a single domain was acknowledged as a problem by Microsoft four years ago. Isn’t that enough time to have corrected it? Because of this limit in Explorer and Explorer only, I am having to redesign my entire approach to cookies. And now you’re upping the allowed number of cookies without upping the byte limit along with it? Does this make sense? Personally, I think the whole thing is disgraceful.

I keep adding preferences that visitors can set (cookies expire after 30 days) at my latest test case (17 total options with 44 total choices to choose from) and only had a vague idea that there was a ceiling though I usually stick to using integers for the value…exactly what kind of sites use 5KB+ sized cookies?

Well this is a welcomed change I suppose. Now if the Webkit team would be so kind as to "allow" JavaScript to create cookies and understand how to handle multiple HTTP queries in a single request work (to any extent) Safari (gah, the latest version that is) wouldn’t be such a pain to work with. Thanks for the post!

I don’t think anyone ever acknowledged it as a "problem" but rather an intentional limitation. And since such a limit has been there for four years, it makes one wonder why you’re having to "redesign" anything.

The post mentions that there are perf problems caused by uploading huge cookies, so maybe they’re really doing you a favor?? Since you’ve got the data on the client anyway, why not use IE’s userdata feature to avoid wasteful roundtrips?

Furthermore it is good to see that MS is finally paying some attention to the problems with state-management although I think the total number of cookies allowed per domain was the least of the problems. I agree though that it does not make much sense to increase this limit but do nothing about the size limit (which is still a leftover of the /minimum/ requirements mentioned in the Netscape cookie draft and RFC2109).

What is really needed is an overhaul of RFC2109/RFC2965 since there are numerous problems with these standards and state-management in general resulting in many differences in implementations between UA’s…

@Matt – interesting to see that IE has a userdata feature, but that is obviously only for IE, and would then require a different piece of code to handle one browser, and standard cookie code to handle all other browsers.

Marty: well, the problem with 1 and 2-letter domains is mostly in combination with a 2-letter TLD (and without www subdomain), but there is more:

y.com works

y.org does not work

y.net does not work

on the other hand, Firefox behaves the same in a.m. situations. I’m not sure what the actual rule used here is, it isn’t even what the Netscape cookie draft describes because there .com, .org en .net are all ‘special toplevel domains’.

Like I said before: we definitely need a new specification for this because at the moment state management is a complete and utter non-interoperable mess.

Correction, my testcase was flawed: all of the abovementioned examples (y.com, y.org, y.net) actually do work in IE7 and other browsers as well, so the problem is mainly with 1 and 2-letter domains with a 2-letter TLD.

Hi. I hate to post support questions on the blog, but maybe you guys can point me in the right direction.

I run Windows Server 2003 x64 edition, which supplies both a 32- and 64-bit edition of Internet Explorer. Recently (in the last month or so, after the last batch of security updates) my 32-bit edition of IE stopped working altogether (it just exits immediately without presenting any UI at all).

I often need to run the 32-bit IE because it seems the Office 2007 integration with SharePoint 2007 does not work with the 64-bit IE. Now I am really stuck.

I tried downloading and running the 32-bit version of IE from Microsoft, but the installer complains "This installation does not support your system architecture (32/64bits)".

Given that my 32-bit installation is completely hosed, is there any way (short of reinstalling the OS) to restore it?

note that it says that those are /minimum/ requirements, as does RFC2109 ( http://www.ietf.org/rfc/rfc2109.txt – Feb 1997) which can be seen as the standard that followed up on the Netscape draft (although IE’s implementation is still mainly based on the Netscape draft wereas other browser vendors’ implementations are more based on RFC2109).

It is however true that the Netscape draft also says that servers should not expect clients to be able to handle larger limits, wereas RFC2109 is more clear on the fact that the requirements are a bare minimum (using the words "at least").

RFC2109 does not document behaviour when the implemented limits are exceeded, the Netscape draft does define that behaviour including the behaviour for cookies larger than 4KB (trim to fit but leave the name intact when the name itself is less than 4KB).

Thank you! The -extoff trick works. IE 7 32-bit is now loaded and seems to be working. However, the Tools|Manage Add-Ons menu is grayed out and cannot be used. How can I find out which add-on is causing the problem and then disable it?

I need to report something to someone at Microsoft that is MS related though not IE related. I do not believe the correct place to report the topic is viable at this time (will clarify in email). Please contact me and I’ll get back to you with all the info I can, thanks!

PS: Name is direct contact link and feel free to remove this OT post once you get this, if you’re not with MS please don’t contact about this post.

@fduch – I take it you are joking about the "Firefox is finally dead" bit. I don’t see Firefox doing anything more than growing and growing. I personally find it is the very first thing I install on a PC after the OS (if not already there)

Even my neighbors’ 4 year old kids (twins), say… "to get on the Internet, you click on the Fox". Talk about your market saturation levels!

I always minimize everything about IE. Actually right at the moment I am using IE6 because I had to perform an in-place install on my XP MCE SP2.

Now, the problem that usually arises after an in-place install of XP MCE is that I cannot use http://windowsupdate.com (Or WindowsUpdate.Microsoft.Com, or whatever it is now). Never fails to fail to install the update. I do not know why this is, because each time I do In-Place install (IE, A Non-Destructive Windows Re-Install) on XP Pro/SP2, it never affects my ability to do Windows Update through the current URL for Windows Update.

I have been looking for a solution for that problem for some time. So, the first thing I do when I get a "Fresh" or an "In-Place" install of XP is to trim Internet Explorer. First thing I attack is the overall amount of space used for storage- And I move the location of the IE Temp Folder: I make a temp folder in the Windows folder. Then, I limit the amount of IE storage to 25 MB, and after that I clear out the stuff in "View Objects" except for the Windows Update Control.

Then I work my way across the Internet Options control panel removing and shutting off anything that will slow down my browser, but I always keep the popup blocker turned on. Sometimes I have the Phishing Filter on, sometimes not, if I am in a hurry and I know that the site I am heading for is safe. And Finally, I make sure that the Temp folder for IE gets dumped the moment IE is shut.

Since I deal with a lot of Web Content that is on CD or other storage, I allow Active Content from CD and from Files- I have several programs that are basically Websites that run off of the Disk- And these have certain controls that have to install.

Finally, I always use a home page that has the least amount of graphics and RSS feeds and Poo and Garbage… The Non "I-Google" Google site is the least graphic intensive site, if you compare that to Yahoo, Hotmail, MSN, and, worst of all, AOL: And if your Tabbed Browsing Windows do not load your homepage, but a blank page instead: Then you got it made and you are walking way from your search at the same time others are still waiting for their 2nd or 3rd page hit to finish loading.

The Problem with browsers like IE7 and Firefox, especially FF 2.x, is, if I may coin a term, Bloatation- In IE Bloating occurs when every utility and instant messenger you want to install, decides to install unwanted (and unneeded) Toolbars. IDM Ultra-Edit 11? Or is it version 12, wants to install the Google Toolbar.

When a program decides to install a Toolbar, absolutely do not let it.

If I keep the amount of sheer temp storage way down, and if I do not allow toolbars, and if I have less cookie storage, then I am happy cos my page is finished loading when everyone else’s is choking on Phishing Filter: Not that safety features are useless, but, and I said this over at ZDnet: Too many people depend on little POS "Security" add-ons and toolbars and features, instead of using intelligent Web Browsing. And that means, looking at the descriptions under each hit, instead of randomly hitting search results, not knowing what is going to literally pop up in your browser. Pages with viruses embedded are actually pretty easy to identify and avoid, they all use a sort of Template.

Anyway, any decent domain, ought not to really need more than 20 cookies. Most of the domains in my "cookie Jar" have 5 cookies or less.

What version of Javascript will IE8 support? I’m developing new applications and want to know if I should put in checks for the native versions of foreach() etc. or just skip the query because they won’t be there.

(yes, I am serving up different Javascript for IE vs. all the other browsers since I have to work around so many bugs.)

That comment is clearly trolling. What puzzles me though is the logic or rather complete lack of it behind the argument.

@resim

See teh comments earlier to this post. The update does apply to IE6 on XP SP2. By the way there is no such thing as IE6 SP2 for XP. The SP2 update is an XP only thing and not available for other versions of Windows.

@rc

They’ve said they are working on IE8 but will not discuss it until they are ready. I’d certainly expect to hear something in the next year or so. If you don’t believe them then that is your right but don’t make statements that have no foundation. It doesn’t do anyone any good and makes you look foolish making anything sensible that you do say seem less credible.

Microsoft needs to do something about this hole in the web. At least release a dumbed down version of IE7 for other Windows versions, with just the newer rendering engine. IE6 still has more market share than IE7.

@DMassy "I’d certainly expect to hear something in the next year or so." – WHAT?!

A YEAR! Are you serious!?!? So, this is the new status quo?! 2 years of silence and no public bug tracking between releases?!

Wow, that sounds like a super-duper plan! Who dreamed up this public relations nightmare?

Seriously, if IE intends to be a big player in the online/web browser/development platform game, they need to get their act together.

In a world of open standards, with technology changing by leaps and bounds every quarter, WAITING TWO WHOLE YEARS to talk about the next version of "your version of the web platform" is mind-boggling!

Are you telling us then, that not only has the last 3,4,5 years of griping about NO DECENT 2 way communication and NO BUG TRACKING gone completely unheard?

Those of us that STILL^H^H^H^H^H believe in the IE team are really loosing any faith we had left!

I was under the impression that the IE team was hard at work making a public bug tracking system, but hadn’t announced it, since is wasn’t quite ready yet…. and now you tell us (effectively), that we can kiss that idea goodbye (cause we need it now, not after IE8 is built) and that we won’t hear any details about IE8, until 4TH QUARTER, 2008 or even later…. if we’re lucky!

OMG – I’m absolutely speachless!

Unless DMassy does not speak on behalf of MS, and there is comm tools on the way asap, you’ve officially just lost massive support from the development community.

"said they are working on IE8 but will not discuss it until they are ready. I’d certainly expect to hear something in the next year or so."

((((((((((((((((((((())))))))))))))))))))))))

Can we get EricLaw, or better yet Chris Wilson on the line here to set things straight!

Whats the story? Has the cat been let out of the bag, that indeed MS has dropped development on IE again? That they don’t care about developer community input?

Does this mean that we’ll know nothing about fixes for IE, until IE8 ships, and the IE Team will once again say "what bug?", "We never knew this was an issue", "thats strange, hmm, maybe we’ll fix that in the next (IE9) version".

We’re getting tired of the run-around here. We don’t need source code access, but a window into the bakery shop would be an obvious no-brainer.

I ran a scan of the posts on the IE blog. I don’t see a timeline, ETA, or even a roadmap for IE8? Nor do I see any info on what things were fixed after IE7 shipped, what we can look forward to seeing in IE8 in terms of fixes and features.

Is PNG Gamma going to be fixed?

Is the DOM going to be fixed?

Is support for the major CSS items developers want going to be fixed?

Is XHTML going to be fixed?

Is Find-as-you-type going to be fixed?

Is the prompt dialog going to be fixed?

Is the zoom going to be fixed?

Is the button element going to be fixed?

Is the button chrome (XP-stretching) going to be fixed?

Is fuzzyType going to be fixed?

Is the status bar going to be fixed? (try clicking on blank spots… boing! mystery actions!)

Is the QuickTabs going to be fixed?

Is the toolbars going to be fixed?

Is the javascript console/debugging going to be fixed?

Is favorites going to be fixed? (and why does deleting one take a day and a half)

Is printing going to be fixed?

Is scripting on the localhost going to be fixed?

Is the options dialog going to be fixed so that the content is readable and manageable?

Is styling of optgroups, and options going to be fixed?

Is marquee going to finally be removed?

Is location-less fullscreen going to be fixed?

Is the "lets make popup windows really ugly with a readonly select list location bar with 10 empty entries in it because that would make the end user experience oh such a joy" going to be fixed?

Is viewing an image by itself going to be fixed?

Is viewing a frame outside its container going to be fixed?

There’s a million and one questions that we have about bug fixes and missing implementations and features.

But the question we all want to know is:

=============================

ARE YOU SERIOUSLY BUILDING A WALL OF SILENCE ON IE8 UNTIL 2009, OR IS A BUG TRACKER IMMINENT, AND DETAILS FORTHCOMING?

I’ve repeatedly said I think that the IE team are doing themselves and the developer community a huge disservice by their silence. They do need to become more transparent about what is likely to happen and when. That doesn’t change the fact that they are understandably reluctant to say anything before it is certain.

Given the silly and frequently abusive comments on this blog it’s pretty amazing that any of the team bothers to engage in conversation here.

@Jimmy

Complying with the W3C standard recommendations is no easy task. If you think it is then why not go and write a browser yourself? Clearly other browsers are ahead in this regard but no other browser is perfect when it comes to implementations of W3C recommendations either. Before you make broad statements such as "the IE team never made IE confirm to W3C standard" though you should really be more specific. There is no such thing as a single W3C standard recommendation and IE does comply to some standard recommendations. Which standard recommendations you are referring to? No browser conforms to all W3C recommendations, such a goal probably makes little sense. The IE team understands where they need to focus their resources. Time alone will tell if they can deliver. Silly and abusive statements in the comments on this blog don’t help establish a conversation and certainly don’t encourage team members to comment here.

I would love to see the IE team be more public about progress but I’d equally like to see fewer silly comments on this blog. Only when both of those things happen can an interesting conversation take place that might be useful to all concerned.

Gecko engine has VERY POOR support for Unicode standard, although Unicode is the underlying technology for HTML, SSS and many other standards. Without reasonable Unicode support there is no point in supporting other Unicode-based standards.

@DMassy: Which comments are the silly ones? The ones that ask about features or bugs? The ones that speculate about when IE8 will ship? All of these questions keep getting asked, because they never get answered. Plain and Simple. If all this blog is meant to be, is a news feed, then please just post the RSS feed, and disable comments.

@rc: Gecko engine doesn’t do unicode well? well, depends which part of unicode you are referring to! I can point out huge swaths of the unicode character set that IE can’t render, and Firefox, Opera, and Safari can. Besides that, poster "Firefox" above is right, starting with the Gecko engine, would put IE leaps and bounds ahead in terms of improving their browser, however it would imediately break all legacy sites that rely on hacks/broken behavior for IE.

@Firefox: your site "http://www.webdevout.net/ie-is-dangerous&quot; is quite nice, it highlights with very little bias the security differences between IE and other browsers. It will be interesting to see if IE7-no-rights mode and Vista’s UAC will make a big dent in what historically has been a very insecure browser.

@paul: wow! a nice list of things that need attention! I wonder if it will get any?

Id like to add to the list:

– is there any documentation on the IE security bar in IE7, and how and when it RELOADS a page, when the user clicks "some option meaning go ahead", and when it just continues to render the page. In the cases where it doesn’t reload, sometimes there are issues because IE drops content/info before finishing the render. (e.g. if auto-file downloads were sent to the client, they get dropped)

– same question, but has there been any fixes to the endless-loop scenarios, where the user clicks "ok, continue" and then the page reloads, but the setting is temporary, thus the user is stuck. ( I had a great example of this in IE Feedback, but who even knows where that went!)

– i would pay $10 to fix the "about;blank’ line that appears every time I try to load a page, or open a new tab. Did the "User Interface" team never get a chance to look at IE7 before it shipped?

So is Microsoft up to the challenge? (hint: the challenge is to post helpful information of any kind about IE8 on this blog before 2008/2009/2010!)

Clearly not all the comments are silly. But here are three examples from comments on this particular post. There are much sillier ones on other posts here 🙂

1. "Dear IE developers, I have a suggestion for you: switch from Trident to Gecko."

If you don’t know why this suggestion is silly then it shows a lack of understanding of the market. Compatibility is one reason. The other being that I wouldn never expect Microsoft to abandon such a key platform technology to someone else.

2. "Every time I read the sign on the websites that claimed to be compatible with IE, I wish I could legislate a law coercing MS to comply with the standard.

The reality? IE is bundled with MS Vista. Worse, the IE team never made IE confirm to W3C standard."

There is no single W3C standard. If you want to have a conversation and show yourself to have some understanding of the issues at all then be specific about which recommendations and why they are needed. That’s pretty easy considering that IE is lacking in a few key areas. Do you really think that legislation is the answer? Please!

3. "When could I have a clean vista free of Internet Explorer?"

It should be pretty clear that as 3rd party software and parts of Windows rely on IE being present as part of the OS that this really isn’t going to happen. What is the point anyway. If you don’t want to use IE then use a different browser as the OS default. Oh and please don’t start on about bundling or are you against Apple shipping Safari with the Mac?

These are just a few examples from a quick glance at the comments here. I can only assume that the reason for the recent increase in these types of comments is the fact that school is back in. Certainly there is a lack of maturity in many of them.

I totally agree that the IE team are doing themselves no favors by their silence and lack of explanation of even simple issues. The team clearly has big challenges ahead of them and need to engage with the developer community in a way that they currently aren’t.

paul’s list above starts to get specific but then loses focus. E.g. "Is the QuickTabs going to be fixed?" "Is the toolbars going to be fixed?" I can only guess at what he is referring to here. I’d love to see a full dialog around issues like this with repro steps etc. Unfortunately a blog like this is not really a good place and the IE team continues to fail to present a public bugtracking system with links to appropriate KB articles that would help people with workarounds.

It’s all a little sad and I can understand why people here are venting their frustration. If the IE team does care about developers then they have to do better and show the developer community that they understand the issues and plan to address them.

@rc

Don’t trust your sources. The only source I’d trust about what is happening with IE8 is from the team itself.

@rc: Either your sources don’t really work here, or they enjoy messing with your head.

@Paul: No, Microsoft continues to invest in IE. I’m sorry we don’t have anything to announce yet, but we are hard at work on the next release and feedback from the community on IE7 is helping to guide our work.

You’ve listed some great issues here (e.g. CSS), but you’ve also listed some trivial issues that don’t really negatively impact anyone (e.g. clicking in the status bar icon wells), as well as some "issues" which are entirely by design for security reasons (e.g. prompt restrictions), and some which are simple preferences where the majority of users prefer the default we’ve chosen (ClearType). Some of the issues are ambiguous (e.g. QuickTabs) and I’m not sure what you’d like to see.

@up to the challenge: The about;blank issue you mention is almost certainly caused by registry corruption or a buggy extension; I’ve never seen that issue elsewhere.

"I can point out huge swaths of the unicode character set that IE can’t render, and Firefox, Opera, and Safari can"

Unicode is not only set of characters. Unicode describes behavior of combining diacritical marks, line breaking rules, bidirectional issues, case conversion, normalization, decomposition and many other topics.

IE has its drawbacks in supporting all that, but Firefox (and other Gecko-based browsers) seem to not support Unicode AT ALL, except of collection of characters which is only tip of the iceberg.

@EricLaw: "but we are hard at work on the next release and feedback from the community on IE7 is helping to guide our work"

Thats funny? because I’ve been trying to submit bugs, test cases, and feature requests but MS shut the IE Feedback site down.

So either there is some magical site that you are pulling this data from.. or you are pulling stale data from the old feedback site.. or you are just making this up.

WE HAVE TONS OF FEEDBACK to provide on IE7, but ALL VIABLE AVENUES to present it to you have been closed.

Posting bugs to this blog is not the answer, nor does it even scratch the surface about the issues with IE7.

Please advise where bug reports can be sent, and where features can be requested, and obviously most importantly so that we are not overwhelming MS with duplicates a location where we can search for previously submitted issues.

For example, where is the list of "known to MS" issues with "CSS conflicting with inline form element style declarations"? I came across another nice one today I would love to post.

Finally, your quote:

"I’m sorry we don’t have anything to announce yet"

That’s fine. But please do tell us when you *think* you might have some news to tell.

If anyone from Microsoft is reading these, I think I found a problem with something.

I was checking for updates on update.microsoft.com (using Microsoft Update, not Windows Update), and installing the Microsoft SilverLight control (yes, it is probably stupid to do those things at the same time). IE froze for a second and then an error occurred with "npcontrol". It said the typical "We’re sorry" and the program died but did not send any sort of crash information like programs usually do.

I know this probably is not enough information (in fact, I know its not – and there’s no way to be for sure for instance what programs were in memory at that time that are no longer there), and this is not something that seems to happen that much, but heres what I can tell you.

Did you bother to look at the table or not? The W3C’s own Amaya browser intended for editing crashed regardless of the media type. If you can’t even get your own color coded messages right don’t even bother posting here.

@AC – Thanks for trolling. As noted by EricLaw, this *IS* a "bug/feature" in IE7, and it *IS* found in every install of IE7.

As for whether it is a bug or a feature lets go look at every other browser since the dawn of web browsers…

notice anything?

oh yes! none of them put that address in because to an end user it means nothing.

as a developer though, I’m so glad MS removed the javascript: protocol abilities from the about:blank page, because that was certainly a major issue, with blank pages, loaded up from no server anywhere, to run arbitrary JavaScript code that might cause security issues……. NOT.

that sure makes debugging in IE so much easier, especially since there is no JS console.

now its my turn to troll… if there were details about the upcoming changes in each new version of IE, then we would know about these "new" things ahead of time, and if they were as goofy as this one, then we could hopefully express such, and have them squashed before they make it into the final release.

Anyone remember IE 7+ The special IE 7 version for Vista a.k.a "lets break naming standards for the software industry, that will be cool" — which very quickly got shot down by the developer community as a silly idea.

why does IE take a differnt width when i set paddings and stuff in css.

follow the standard box model and chris wilson can you talk with the visual studio team to generate validating code and use less tables because tables and frames are OUT (tables are only used for real data stuff not for website layouts. CSS ftw!

Ive been reading all the comments with much interest recently about the IE development and tracking issues.

I took a look to see if there were any other sites that offered a public database of issues that was very complete but there simply isn’t one.

I did however find a site that tracks vulnerabilities (in all kinds of software by many manufacturers)

This link (minimized using tinyurl) will take you to a list of the "Verified, Microsoft Internet Explorer" vulnerability issues. It won’t show CSS and DOM bugs that render badly, but it will at least explain some of the memory and crashing issues.

If anyone knows where a good public database of IE rendering and behavior bugs is, please post a link, i’m sure there are literally thousands of people interested in finding out the issues, and workarounds for them.

It’s a page though and still not the same a database which is what is really needed. I’m sure someone could establish a wiki for the collection of issues and links to workarounds. However everyone just complains and fails to do anything about it. People are looking to Microsoft to supply such a databse, which they probably should. I’m not sure we’ll see anything before IE8 enters beta though. We’ll see….

"I’m sure someone could establish a wiki for the collection of issues and links to workarounds. However everyone just complains and fails to do anything about it. People are looking to Microsoft to supply such a databse, which they probably should."

I’d start my own bug tracking site if I knew MS weren’t going to release their own, but they refuse to comment.

Clearly there is a challenge to having a public bug database that is truly useful rather than just full of noise and poor bug reports with lack of reproducible steps. However other teams manage to do this so the challenge can clearly be met if there is the commitment to do it. There is little point though if the team is not willing to put the necessary resources into making it work. The bug reporting mechanisms in place while IE7 was under development were clearly not working well enough to continue with for a fully released product. When we will see anything from the IE team on this is unclear. I suspect they will not establish anything until IE8 enters beta when they will actually be really interested in bug reports. Who knows when IE 8 will enter beta though! The real shame is that there is a use to a bug database to all developers using currently released and supported versions of IE in pointing people to recommended workarounds to issues. Without such support web developers end up frustrated and feel the IE team does not care about them at all.

So like this seems like such a run-around. "we don’t want your feedback or bug reports until it is too late to change our code" – how exactly does this help anyone?

At the moment IE8 beta has not been announced, and we have no idea which week, month, quarter, year it is to be available. I’m tired of waiting on thin air to hear when stuff is going to happen!

If there is a plan to release:

A.) A bug tracking system

B.) An alpha/beta version of IE8

C.) A targeted release date for IE8

D.) A roadmap for IE8

E.) A feature list for IE8

*ANY* of the above, in the next 6 months, please announce that you have such plans.

i.e. "We plan to disclose an overview list of potential feature for IE8 in the next 6 months"

HOWEVER, if you are *NOT* planning to release information on *ANY* of the above items, *ALSO* release a statement as such, so that we *AT LEAST* know that you *ARE LISTENING*!

i.e. "We do plan to release details on IE8, the version we are currently working dilegently on, however we will not have any news to distribute to this blog on IE8 until Q2 of 2008."

WHY IS IT SO HARD TO PUT A ONE LINE STATEMENT ON THIS BLOG TO INFORM US WHAT IS ACTUALLY GOING ON!?

We know IE6 is bad, leaks mem like a seive, can’t do DOM worth beans. We know IE7 was a massive step in the right direction, rebounding IE out of the gutter and back into the picture, but we’re desperate for news on IE8, we want a browser that is at least close to being able to compete with the other modern browsers (Firefox, Safari, Opera, Camino & Konquerer…)

Its embarrassing to tell end users that the zooming feature in IE7 will let you see things better, but at the cost of links that are hard to click, form elements that are distorted out the wazoo, don’t even try framesets, and expect all DHTML widgets to behave very strange.

Ditto for all the "sexy" stuff they see in other browsers, but can’t see in IE… no rounded corners and all that jazz. (PS bloated hacks don’t count)

If for no other reason, give us a glimmer of hope as to when IE8 will be a reality.. so we can see a glimmer of hope – as to when we can tell end users that IE6 is no longer supported.

End users should not have to use a browser over 3 years old.

OK – end rant, time for a Joke.

How many "Program Managers on the IE Team" does it take to provide 2 way communication with the Developer Community?

Why do you persist in making these statements which members of the IE team deny. They have no basis beyond your assertion that people at Microsoft outside of the IE team make these statements. Anyone familiar with the culture at Microsoft will tell you that teams routinely trash talk each other and usually have little or no clue what other teams are actually doing. The only source you can trust is the team concerned themselves. Work on IE8 continues as they have repeatedly said, but they are not going to discuss it before they are ready.

It’s fine to disagree with the team for their silence which I believe is a huge mistake on their part. Their silence certainly doeasn’t help. However please don’t make these statements as though they are fact when they are only rumour that you alone persist in pursuing.