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 critical platform changes we’ve made in these areas.


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:

Dialog box "Message from webpage - Please designate the path of the new firmware."

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


If <a> is not followed by a text node, link is extended infinitely


TextArea width:100% on page refresh renders


IE hard assert possiby related to <col></col> giving blank page.


*Very* slow reaction in sites built with JS framework


IE8 RC1 javascript engine bug


overflow:auto generates scrollbars even if overflowing element is within overflow:hidden


background image not or not correctly rendered


[RC1 build 18372] [abs. pos.] Image shrinks unexpectedly after hovering a link


IE8 RC1 (Stds Mode) SCRIPT tag causes Major REGRESSION rendering alignment bug


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


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.


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

Comments (39)
  1. Joe says:

    The keyboard shorcuts below is not working at all

    Use the TAB key to move between section headers

  2. Tom P says:

    Thanks for the information Kris K.

  3. picky says:

    c:fakepath doesn’t work for the critera <8 characters (<= 8 maybe? 😉

  4. Joe says:

    I can’t use keyboard to access more list of History or favorite header using the tab key.

    anyone know what the keyboard shorcuts to view more list history and favorite

  5. Jane Barrister says:

    Can you provide a statement about what Microsoft is doing about using IE8 with SharePoint?

  6. Zian Choy says:

    History: CTRL+H

    Favorites: CTRL+I

    Just the same as IE7.

  7. Joe says:

    Zian, I mean to expand the history and favorite list in smart address bar. Tab key to access section doesn’t work at all.

  8. Joe says:

    Zian, I mean to expand the history and favorite list in smart address bar using a keyboard. Tab key to access section doesn’t work at all.

  9. Joe says:

    Zian, I mean to expand the history and favorite list in smart address bar using a keyboard. Tab key to access section doesn’t work at all.

  10. Seth [MSFT] says:

    @joe: Hi Joe, we changed the TAB key to cycle through items in the address bar rather than the section headers, in response to user feedback. When looking at user data, we saw that very few people actually expand these sections.

    To expand the sections, you’ll need to use the mouse. A better option would be to refine what you’ve typed in the address bar so the result you’re looking for comes up in the top 5 results. Hope this helps!

  11. Joe says:

    thanks Seth for the information anyway, sorry about the multiple comment internet issue causing me to post multiple times.

  12. martin says:

    Thanks Kris,

    For the record though:

    "415727 IE8 RC1 (Stds Mode) SCRIPT tag causes Major REGRESSION rendering alignment bug"

    was not fixed in IE8 RTM it reproduces on my app also.  I had to move the script tag to an "ugly" location between TR tags to get around this.


  13. EricLaw [MSFT] says:

    @picky: Nice catch!  Should be <= 8.

    @Jane: Can you please be more specific?  The IE team uses SharePoint with IE8 every day.

  14. SiSL says:

    Oh well, may be you should not fix that overflow path…


    <dl><dt>Title</dt><dd>… Content .. </dd></dl>


    Normally if you have max-height, or height on DIV and your content has higher height than your div’s designated height,

    With overflow: auto, you were supposed to get scrollbars, no?

    Not happening. I’ll double check again but this was supposed to be working, works in IE6, works in IE7, worked in IE8 RC, works in FF 3.0.7, works in Opera 10, Works in Chrome and works in Safari…


  15. SiSL says:

    Oh forgot to add Div is called by a function to display: block and was normally display: none, not overflow: hidden

  16. SiSL says:

    Sorry, I felt whiney a bit. Bu really good work since RC on IE8. Congratulations and thanks for all work, especially loved Text-area fix 🙂

  17. Soum says:

    So far so good, but when is IE finally going to stop showing local filesystem items opened from the Windows Shell in IE history?

  18. Soum says:

    So far so good, but when is IE finally going to stop showing local filesystem items opened from the Windows Shell in IE history?

  19. Jane Barrister says:

    I’m not an IT Pro, but our IT team says they are going to prevent IE8 updates until they have sorted out the problem with SharePoint. I’ve found some reference to problems here: http://blog.drisgill.com/2009/03/problems-with-ie8-standards-mode.html.

  20. Anonymous Coward says:

    Heaven forbid that firmwares should support Firefox, which sends only "upload.txt", or Linux, Mac OS, or BSD, which use forward slashes instead of backslashes. Sending only "upload.txt" exposed these problems and encouraged fixing them, but now countless web developers won’t notice until their users complain. Thanks Microsoft.

  21. jace says:

    Thanks for correcting the tab behavior in the address bar!!

    I use tab to cycle through individual items and very much disliked the behavior of cycling through the section headers.

  22. EricLaw [MSFT] says:

    @Jane: The problem with blank menus is caused by a bug in ASP.NET, for which a fix is expected to be imminent from that team. However, note that by-default you’re unlikely to ever notice this problem if your SharePoint sites are on your Intranet, because IE8 will by-default use EmulateIE7 mode for Intranet pages.

    @Anonymous Coward: Just for clarity– the filename sent to the server matches what Firefox sends; only for local JavaScript do we provide the compatibility mitigation.

    Punishing users to force websites to have better code rarely works, since users simply won’t install the new version.  The firmware issue we’re referring to was left unfixed by the vendor for well over a year, so it’s unlikely that we could have effectively forced them to change anyway.

    Furthermore, as noted originally, there’s a Catch-22 here: To get a fix for the script installed, the user would have to update the firmware, but they cannot update the firmware without the fixed script already installed.

  23. Anonymous Coward says:

    The catch-22 could have been resolved simply by temporarily changing the browser settings or disabling JavaScript. Fixing the bug would ensure that the _next_ million firmware interfaces work in all browsers and not just Internet Explorer. Some old firmwares may never work right, but fixing IE would have made sure that no new ones are designed with this bug.

  24. Dan says:

    Anonymous, you don’t really understand normal users, do you?  How exactly is the user supposed to know that "Please designate the path of the new firmware" means that they should go disable Javascript?  And what makes you think that would actually help, since the firmware could very well require Javascript to function correctly.

    I think the most likely outcome here is that all browsers will adopt what Opera10 and IE8 are doing.

  25. Anonymous Coward says:

    You have a point that setting "Include local directory path when uploading files" temporarily would be more likely to work than disabling JavaScript. Even so, is a run-of-the-mill user going to be updating firmware? If the user is intelligent enough to update firmware, they’re probably intelligent enough to use Google to figure out why they’re getting a cryptic error message. Furthermore, the problem would diminish over time if all new routers shipped with firmware free of this bug, which would be practically guaranteed if the latest versions of Internet Explorer required it.

    And again, IE8’s solution of "C:fakepathupload.txt" makes little sense on Unix platforms, where drives are not named and forward slashes are used instead of backslashes. This is far from a universal solution.

  26. Anonymous Coward says:

    Sorry, that should have said drives are not _lettered_ on Unix platforms, not that they are not named.

  27. Dan says:

    <<be practically guaranteed if the latest versions of Internet Explorer>>

    They made this change over a year ago, and this has been broken for Firefox (which has >20% share in some markets) for years.  So methinks that maybe your assumption is incorrect.

    <<IE8’s solution makes little sense on Unix platforms>>

    Not to point out the obvious, but IE doesn’t run on Unix.  Having a Windows browser simulate the Windows filesystem isn’t exactly surprising, and since they did this for compatibility, returning a Unix path would make no sense at all.

  28. Anonymous Coward says:

    I meant the latest stable version of IE. Firmware is less likely to be tested against IE8 betas.

    My point about Unix was that making everyone use "C:fakepath" is not very interoperable (at best, it’s an ugly solution) because it doesn’t make sense to simulate the Windows filesystem on a Unix platform. Do you seriously expect all Linux browsers to start using "C:fakepathupload.txt" for "compatibility"? Much better (more secure, intuitive, and interoperable) to just use "upload.txt" on all platforms.

  29. Jane says:

    Thanks for the info, I’ll pass that on to our IT team. Can you post the URL to the ASP.NET fix when it comes out?

  30. AndyC says:

    @anonymous: since the c:fakepath bit is just an arbitrary bit of text (that just so happens to resemble a Windows path) what exactly prevents a Unix browser from doing the same?

  31. Anonymous Coward says:

    Nothing. "C:fakepath" just makes no sense on Unix. It’s a hack (a poor design) no matter how you look at it. Doubly so because what JavaScript sees is different from what IE actually sends over HTTP.

  32. B. Gordan says:

    @EricLaw [MSFT]

    >> Punishing users to force websites to have better code rarely works

    That is totally incorrect, firefox pushed for standards now websites have changed a lot. They send correct mime-types now, more and more sites have standard compliant html and javascript code etc…

    Real problem is browsers are not showing bugs on a website, so QA people are unaware of the bugs created by the web developer. I am not telling you should popup error message for every error (actually there is a setting, which at many QA shop are asked to forcefully disabled by the dev team). I say instead of popup, show something on the status bar, ie upon error there should appear a "Show Error Messages" button, which list all HTML, JavaScript, CSS errors. And IE should not allow an option disable that button.

    If you continue to provide "C:fakepath", at least some web developers will continue to make mistakes and QA never catches, and they never fix their code.

    For Router companies,

    * there is not that many Router companies as the number of websites.

    * sooner you fix this in IE beta, more Router  companies will send patch before users in mass start using IE8.

    * you can ask beta testers to test with their Routers and find the problem ones. Then Microsoft can contact those companies to issue patch before IE releases to mass.

    * Many of the Router Javascript issue can be solved by Bookmarklets

    * To those users who dont know how to use Bookmarklets can be provided with a *.exe program which runs and send patches to the Router.

    These are just from experience working in IT for two decades

  33. Julian Reschke says:

    Was it considered to just send


    instead? That would still be "correct", and have a backslash to scan for.

  34. EricLaw [MSFT] says:

    @Julian: We considered it, yes, but I believe I’ve also seen cases where the script scans for a drive letter at the front.  Ultimately, since this is a compatibility feature, our goal was to emulate as closely as possible the legacy behavior.

    @B: You’re entitled to your opinion, but having worked on browsers for four years, I must disagree with your conclusion that users should be penalized by browser releases to compel websites to change.  

    As noted previously, the router software in question was broken for over a year in IE8 betas, and for multiple years in Firefox.  The vendor has not yet shipped a patch, despite the fact that I sent them the required code change over a year ago.

    If users don’t install IE8 because it doesn’t work with their favorite products, older IE versions will remain popular use for longer, an outcome that no one wants.

  35. Alex (previously Anonymous) says:

    @EricLaw: Could you provide a list of specific sites and firmwares that have this problem, so that we can verify the issue?

  36. EricLaw [MSFT] says:

    @Jane: The ASP.NET team released their hotfix for the blank menus issue.  You can learn more about this here: http://weblogs.asp.net/bleroy/archive/2009/03/23/asp-menu-fix-for-ie8-problem-available.aspx


  37. Uploading File Fails in IE8 due to Security Fix for INPUT type=file

  38. Support says:

    In testing with Internet Explorer 8 we discovered a problem in uploading files. This applies to both

Comments are closed.

Skip to main content