RE: IE8 Beta Feedback

Thank you to everyone who has provided the IE Team with feedback on IE8. Your dedication to making this product the best it can be is truly amazing. Here is an update on the feedback channels mentioned in IE8 Beta Feedback blog post back in March of 2008:

IE8 Technical Beta – We invited a group of beta testers, including anyone who emailed us, from around the world to test and submit issues on IE8 through Microsoft Connect. Compared to feedback during IE7, we received a high percentage of actionable bugs. We appreciate the time everyone took to file detailed bug reports with the IE Team.

What happens now? All Postponed bugs are now active for consideration in the next version of Internet Explorer. We resolved and closed all other bugs submitted since IE8 Beta 1. The Internet Explorer 8 Feedback website on Microsoft Connect will remain open and we will not delete any of your previously submitted bugs. Right now we are looking for new IE8 bugs and bugs that have regressed (meaning the bug was previously fixed and now occurs in IE8 RTW).

In the next couple of months, we will introduce a new type of feedback form designed specifically to handle improvements for the next version of Internet Explorer. Please stay tuned for more information.

Public Votes on IE8 Technical Beta bugs – We have opened up the bug database for the IE8 Technical Beta for everyone to view and vote on issues. There is no need to create a Microsoft Connect account.

What happens now? This site will remain open to the public. Please continue to rate the bugs most important to you.

Report a Webpage Problem Tool – The Report a Webpage Problem Tool is a control you can download and install in IE8. When you encounter a site that is not rendering correctly, you can submit a report.

IE Beta Newsgroup – This new newsgroup is the all-in-one place to discuss items about IE8 betas. Thank you to everyone, especially the IE MVP’s, for helping the IE Team monitor our newsgroups and filing bugs on other’s behalf. Great team work!

We are looking for new IE8 RTW bugs, particularly issues where something worked in an IE8 beta release and does not work in IE8 RTW. If you believe you have one of these issues, please take the following steps:

If you don’t find your issue, you can visit the IE General Newsgroup and post your issue there. Members of the technical beta will be monitoring this newsgroup and can file a bug about the issue on your behalf.

Once again, thank you for your help in making IE8 great!

Allison Burnett + IE Team

Edit 3/23/09: typo correction, Windows 7, not Windows 8 🙂Edit 3/31/09: Please use the General IE newsgroup for issues which area not already in Connect, not the Beta newsgroup. Corrected this reference.

I am assuming you are referring to the bugs closed “Won’t Fix”. We will not be reactivating these bugs. The definition of “Won’t Fix” is:

“Won’t Fix – we know that we will not be addressing the reported issue, usually because it risks breaking the code in other, more serious ways or because the effort to fix the issue is not justified for the improvement.”

"We invited a group of beta testers, including anyone who emailed us…"

You did? The original "IE8 Beta Feedback" post says something different: "…tell us why you are a great beta tester. There is a limit to the number of people we will add…"

Although I did find a couple of bugs, I didn’t attempt to sign up to the tech beta as I didn’t want to use up a slot that somebody else may have deserved more. In addition, I didn’t think that I would be a "great beta tester" as finding one or two bugs isn’t really that great. Now you’re saying that everyone that emailed you received an invitation.

Although the bugs I found have been fixed, I wonder how many other people were in a similar situation, and how many potential bug reports may have been missed.

What I find the most appalling is how InPrivate Filtering subscriptions were silently nuked from the product (since Beta) and MSDN documentation. That was truly a promising feature. Of course the fact that Filtering doesn’t stay on is another idiocy that was probably thanks to lawyers.

I’ve only occasionally looked at this blog but my impression over the months is that this blog and the IE8 team’s approach are quite above other departments at Microsoft. Well done and kudos! I hope it’s contagious.

Maybe people dislike monopolies only when they don’t deliver. Maybe you guys could turn things around for MSFT!

At this time we do not plan on fixing this issue. We appreciate the report, but unfortunately we are at a stage where need to choose what we work on to maximize the value for customers and web developers.

I am convinced that bugs 361181, 407963 and 366200 should be reopened and fixed. Bug 366200 is a rather *_pretty serious_* bug. The 2 others involve CSS 2.1 compliance, correct conformance to the spec.

We updated our systems in preparateion for IE8 and ran against this bad bug. Can IE detect this type of problem? The DNS request for a web page url lookup would go out and get returned ok but the http request would fail as it is blocked by a third party firewall that has problems. This third party firewall was unknown to us and embedded in a VPN client. Can we get IE to detect interception of DNS/HTTP/HTTPs/FTP requests on the local machine?

There may be a conflict between the Cisco VPN client and AT&T Global Client as they may include the ZoneAlarm firewall device driver (c:windowssystem32vsdatant.sys).

Different versions of the ZoneAlarm device may cause networking conflicts such as IE fails to load, IE gets DNS errors for HTTP sites but not HTTPS sites (i.e., HTTP port 80 is blocked but not HTTPS port 443). I do not know if this is an issue with our current desktop/laptop XP image.

The readme file for ZoneAlarm mentions that there may be a conflict when different versions of the ZoneAlarm related files (device driver, DLL files) are installed and/or upgraded:

When you install Cisco VPN client, then install a 4.x version of Zone Labs Security software, Zone Labs Security software upgrades a DLL that is also used by the Cisco VPN client. If you either uninstall Zone Labs Security software 4.x or install an earlier version, you must also uninstall the Cisco VPN client, otherwise the shared DLL will not be downgraded to a compatible version. [11913]

————–

Port 80 Blocked Windows XP

Symptom: Port 80 Is Blocked On A Windows XP PC. Various browsers all produce failures appearing because http is blocked IE port 80. Alternate ports like HTTPS over 443 may work just fine. Other traffic besides port 80 may also be blocked like ICMP (ping) or SSH on port 22.

This blocking behavior is usually due to a firewall being installed and activated. First check the Windows XP firewall and disable that. Look in the control panel, Windows Firewall icon. If this firewall is disabled check for other software based firewalls installed like Zone Alarm or products from Mcafee and Symantec like Norton or other personal firewall products.

In other cases we’ve seen port 80 blocked on Windows XP where no firewall seems to exist. In the case i’m thinking of it was a Cisco VPN client that was the problem. The Cisco VPN client has a Zone Alarm firewall. Sometimes even after the Cisco VPN client is uninstalled port 80 is still blocked and a user cannot use a browser to http but can use https. In this case try the following solution.

Restart the Windows XP PC in Safe Mode.

Run Regedit.exe to open the registry editor.

Navigate to HKEY_LOCAL_MACHINESystemCurrentControlSetServicesvsdatant

Click start in the right pane and modify the value to 3.

Restart the PC and port 80 should no longer be blocked and you can use http with any browser.

You did a great job with CSS2 guys ! Are you planning to release any update of IE 8 after a little while to fix the remaining CSS2/HTML issues that could lead to developpers making hacks again ? I’m especially thinking about getting a optional update that would be available on Windows update. Most of IE’s competitor are able to do that and people get updates more regularly, so that bug have a shorter lifetime on those browsers. Could a non-compliance bug be considered as being the most important issue after a security issue ? In my opinion, non compliance should be considered as a reliability issue !

I fully understand hAl; he’s right. The resolution field of many closed bugs is misleading or obscur. What does/did [by design] mean exactly now that IE 8 final release is out? What does/did [wont fix] mean exactly now that IE 8 final release is out? Both questions are relevant furthermore if a courtesy, polite pre-edited message state that the bug report will be nevertheless tracked (and hope to address it later), will be [re-]considered or re-assessed in the future.

Some bugs were closed that way for different reasons with various degree of importance:

Some bug reports were closed for not being reproducible but it may turn out they were real bugs (and reproducible and important) worth tackling, addressing and fixing. Some bug reports were poorly edited, difficult to understand, without a testcase, etc… but it may turn out they were real bugs (and reproducible) worth fixing.

I am very excited that a more standards compliant browser is available from microsoft. The copious amounts of money and time ie6 and even 7 has eaten of my design company is staggering. Beyond time and money, more disturbingly has been the limit that was placed on my teams creativity. Oh I’ve prayed for market-share to shift to firefox. IE 8 is a great step in the right direction, however I am again still waiting and wanting the very things that other browsers are already giving – opacity, rounded corners, text shadows, canvas!

I truly ask: why would you continue to make a product if it is inferior? Is that not a great dis-service to your customers? As often MS is the gatekeeper to technology, why stifle it? Mozilla is open source, however they do have alliances around $$ – so include them in windows installs under the rule that the search box defaults to ms live searches.

I don’t care how it happens, I just want to make beautiful functional websites.

IE file save as should not reload any content from the remote server since it all should either be cached on disk or memory.

Printing to PDF using pdfcreator is my usual way of saving web pages for email or future reference. Saving as HTML usually breaks down in the future as a large number of web pages have references to remote objects that either a) require context/cookies to render or b) won’t exist in a few months.

I’d appreciate a way to save a web page as a single html file + all of the non-html parts as individual files (e.g., include all external css/javascript files in the main html file).

Can we get a shift-right click or equivalent setting (maybe in menu command view page properties – elements) to allow us to block flash/silverlight objects for a particular url (e.g., *.adserver24.net)?

A single button to ‘show blocked objects’ on a given web page would help also.

This is the same as skipping the 10+ minutes of trailers/ads/junk at the beginning of a DVD.

@Roman: Unfortunately, the blog site is having some database connectivity issues. They’re working on it.

@Greg: If you put unwanted sites in the Restricted Sites zone, their ActiveX controls will not run. I know this isn’t the user experience you’re asking for, and it becomes cumbersome once there are more than a dozen or so, but it is a workaround available today.

@Greg: IE’s File > Save respects the HTTP caching headers set by the server. If those headers are set such that cached resources must be revalidated, then the server will be sent the request to ensure freshness.

<<I’d appreciate a way to save a web page as a single html file + all of the non-html parts as individual files>>

That’s the "Webpage, Complete" option in the dropdown.

<<e.g., include all external css/javascript files in the main html file>>

I am in full agreement with Gérard Talbot and hAI; the resolutions for the bug reports are so coarse and unreliable that they are nearly useless. Prior to the mass-closing of bugs before the IE8 RTW release, most of the bugs in my watchlist were actually closed ones… because I strongly suspected that they had been closed incorrectly, or that the resolution didn’t reflect the actual status of the bug, and so I was waiting for them to be reopened.

This makes for a great deal of unnecessary hassle for those of us volunteering our free time to help report and triage these bugs.

As a web app developer, these are the top ten things I would most like to see in IE9 and it’s development:

1. CSS Color Level 3 which includes opacity. Please make sure your implementation of opacity works properly with transparent pngs, Canvas with alpha less than 100% and SVG with alpha less than 100%. The current IE opacity does not play well with transparent pngs or VML with alpha less than 100%.

I tested it and it runs pretty good. Now the only thing is the design, is MS going to facelift the interface. Google chrome is setting new trends and would be good if IE8 came up with an enhanced GUI to back up the progress you guys made.

Running IE 8 on Vista Ultimate, fully patched. About 50% of the time when I close IE 8 (either the whole app or just a single tab) I get a crash. Those crashes are split evenly between mshtml.dll and the Flash ocx file.

I’ve not seen a flood of reports about this, which makes me think my experiences are isolated. However, the exact same thing is happening on two different computers I’m using–computers that are both running Vista and IE 8 but are otherwise completely unidentical.

b) Reloaded web page is identical (or close enough – e.g., only ads changed) so that refreshing it just wastes time

c) Web server refresh changes the content of the page and I want to save the exact data I’m looking at (e.g., output from a real-time report viewed as html in a browser)

Printing:

– Can we get print to PDF?

– Can we get print to PDF as images (e.g., tiff or high quality jpegs)

– Can we get print to tiff (Office has had this for a long time)

– Can print print the web page you are viewing and not reload it from the remote web server (I do not know if this happens, but printing someitmes appears to very slowly reload the page)

Lastly, save to a compresed file would be nice (ZIP file). This helps as I usually save the web page to PDF/html then ZIP it and either email it to someone or put it into a library of useful documents (e.g., How to install our internal software may have one or more troubleshooting documents which have been saved from the web). This greatly reduces production support time since we can immediately direct future developers towards the most useful and pertinant documents.

We used to include the URL for helpful web pages but found that after about 1 year they become dead, require a new login id, don’t work, have content changed/removed.

It’s also nice to send a web page as a pdf/tiff/zip via email since the email will last much longer than the web page (as mentioned above).

1) When trying to vote on the bug database, it requires ‘sign in to rate’, which is not what this article indicates. After actually signing in, if you try to vote you’re taken to ‘page not found’. So… this whole endeavor not working as intended, at least for some, if not all, of us.

2) Bug ID 364199 was closed as ‘probably not a bug’ (I paraphrase here). It is in fact a bug on my laptop, and behaves exactly as the original bug report states.

Please REALLY open up the database so we can vote on these bugs or it is useless to both you and us.

@Eric: The version numbers are hinky. If I right-click a Flash object on a website and select "About Flash Player 10", version 10,0,22,87 is reported. If I go into "Manage Add-Ons" in IE and look at the "Shockwave Flash Object", it’s v9.0.28.0.

So I’m actually running the latest version of Flash player.

Also, even if Flash player is buggy that would only explain half of my crashes on window closing. It wouldn’t explain the mshtml.dll crashes.

@John: It’s important to understand that buggy add-ons can crash inside IE DLLs. If, for instance, an add-on passes a null pointer into an IE dll (e.g. mshtml) that DLL will be on the top of the stack when the crash occurs. You must look at the full stack of the crash to determine the origin of crashes.

In your C:windowssystem32macromedFlash folder, how many different .ocx and .dlls do you have?

@Gerard: Congratulations, you did what three HTML validators and several humans failed to do — found an HTML error. Thank you! When the error is corrected, IE8 rendered properly. I’ll follow up in postings I made on this in the newsgroup.

ps. IE8’s DevTool interface to validation doesn’t work for me — when I select it, after the ‘do I want’ popup, nothing happens. I’ve posted elsewhere but no ideas. So I did the ‘validation’ manually at htmlhelp.com and w3.org

@hAl: I don’t think I can — doesn’t it require registration which is now closed?

@Gerard: (follow-up to above) I guess the HTML validators don’t mind or warn about missing </td>’s, which led me to the below HTML, which appears to cause the IE8 rendering anomaly mentioned above but is cleaner.