RTM Platform Changes

Original: RTM Platform Changes

Hi, I'm Kris Krueger, the Test Lead for the developer platform in Internet Explorer.

When we announced the IE8 Release Candidate, the call to action for site owners, software developers, designers, and administrators was to test with the Release Candidate build and make any changes necessary to create the best possible customer experience with IE8. We stated that we would continue listening to feedback from the community, but would be very selective about the changes to the platform made from there on out. This is an important point – we wanted to be mindful of the work we'd asked you to do. We didn't want to "pull the carpet out from under you" by changing fundamental ways the IE platform behaved. We did, though, commit to acting on the most critical issues, particularly reports concerning security, backwards compatibility, and completeness with respect to planned standards work. I'd like to communicate the cr

Security

For IE8 Beta-1, we closed off the information-disclosure problem whereby JavaScript can read the .value attribute of a file upload control and determine the full local pathname, which might include information like the user's name, profile directory, etc.  Specifically, we changed from ALLOW to DENY for the Internet Zone "Include local directory path when uploading files" security setting.  So, rather than sending the filename "C:\users\bill\desktop\temp\upload.txt", we instead send just "upload.txt".

Over the last few months, we've run into a significant number of sites (e.g. education products, several movie sharing sites, etc) and devices (e.g. popular home routers) that this security improvement breaks, because the sites use JavaScript to attempt to parse the filename (e.g. to determine its extension).  In many cases, the script will attempt to get the indexOf() the last REVERSE_SOLIDUS (\) character in the string, and since we now return only the leaf filename, those scripts will fail to parse the string and complain to the user.

For instance, here's a screenshot of the dialog you get from the router's firmware update UI after you click the "Start to Upgrade" button:

Clearly, the user can't easily understand what caused this problem.  While we'd obviously prefer that developers fix broken scripts, in some cases this would be really tricky.  In the router's case, for instance, the user would need to update the firmware to get the fix, and it is the firmware upgrade code itself that's broken! 

In light of this, we started looking into compatibility mitigations for this problem.  One proposal was that we could prepend a bogus path to the leaf filename so that such scripts will continue to work.  We wanted to use a prefix which is descriptive (e.g. so it can be searched for by any confused web developers looking into problems) and which is simple (contains no special characters) because the parsing code we're trying to help out is likely not very robust. 

Upon investigation, we found that Opera 10 alpha is already doing this compatibility mitigation, although their prefix ("C:\fake_path\") includes an underscore that we'd like to avoid because we don't want to use special characters and would like to ensure that file path segments are <8 characters.

We elected to prepend "C:\fakepath\" in order to mitigate the compatibility problem.  We only provide this compatibility mitigation in the value attribute's accessor; we do not send the fake path to the server.

Backwards Compatibility

During the Beta / RC cycle, we asked for your input via the http://connect.microsoft.com feedback channel. In the released version of IE8, we've fixed many of the top platform issues identified using the Release Candidate build. These issues were prioritized based on votes by the community.

Feedback ID	Issue Title
406278	If <a> is not followed by a text node, link is extended infinitely
414825	TextArea width:100% on page refresh renders
409478	IE hard assert possiby related to <col></col> giving blank page.
412015	*Very* slow reaction in sites built with JS framework
413508	IE8 RC1 javascript engine bug
413587	overflow:auto generates scrollbars even if overflowing element is within overflow:hidden
414849	background image not or not correctly rendered
415317	[RC1 build 18372] [abs. pos.] Image shrinks unexpectedly after hovering a link
415727	IE8 RC1 (Stds Mode) SCRIPT tag causes Major REGRESSION rendering alignment bug
415039	body backgroud-image is not displayed unless body.style.height='100%' set explicitly

We also received strong customer feedback asking that we version a set of DOM features we had previously added to IE8's Quirks and IE7 standards mode.

Below is the list of features that have been hidden from IE7 Standards mode to improve compatibility with IE7.

• The JSON object is now hidden
• [DOM object].toString() enhancements reverted so that only "[object]" is returned, just like IE7
• object.defineProperty/object.getOwnPropertyDescriptor APIs are now hidden

Standards

As part of our commitment to standards we have fixed a small number of tests listed on the official W3C CSS 2.1 test suite.

Before you run these tests make sure that you follow the prerequisites listed at the Windows Internet Explorer Testing Center.

http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t090501-c414-flt-ln-00-d.htm
http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t090501-c414-flt-ln-02-d.htm
http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t090501-c414-flt-ln-01-d-g.htm
http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t0803-c5504-imrgn-l-05-b-ag.htm
htt .w3.org/Style/CSS/Test/CSS2.1/current/html4/t051103-dom-hover-01-c-io.htm
http://www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t1605-c545-txttrans-00-b-ag.htm

After shipping the RC build we listened to feedback on our HTML 5 DOM storage implementation.  We acted on this feedback by making two changes to IE8's DOM storage implementation so that we match the HTML 5 spec.  The first change is that we now return null and not undefined for keys that don't exist in DOM storage.  The second change is that we removed the length and remainingSpace properties when iterating DOM storage using a for..in statement. We also removed the binary IDOMStorage and IEnumDOMStorage interfaces from IE8.

Thanks for all the feedback, your feedback has helped us make a better browser!

-Kris Krueger
Test Lead