RTM Platform Changes

Artikel
03/20/2009

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.

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 https://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.

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

Anonymous
March 20, 2009
PingBack from http://blog.a-foton.ru/index.php/2009/03/20/rtm-platform-changes/
Anonymous
March 20, 2009
The keyboard shorcuts below is not working at all Use the TAB key to move between section headers
Anonymous
March 20, 2009
Thanks for the information Kris K.
Anonymous
March 20, 2009
c:fakepath doesn't work for the critera <8 characters (<= 8 maybe? ;-)
Anonymous
March 20, 2009
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
Anonymous
March 20, 2009
Can you provide a statement about what Microsoft is doing about using IE8 with SharePoint?
Anonymous
March 20, 2009
History: CTRL+H Favorites: CTRL+I Just the same as IE7.
Anonymous
March 20, 2009
Zian, I mean to expand the history and favorite list in smart address bar. Tab key to access section doesn't work at all.
Anonymous
March 20, 2009
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.
Anonymous
March 20, 2009
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.
Anonymous
March 20, 2009
@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!
Anonymous
March 20, 2009
thanks Seth for the information anyway, sorry about the multiple comment internet issue causing me to post multiple times.
Anonymous
March 20, 2009
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. ...(/tr)(script)...(/script)(tr)...
Anonymous
March 20, 2009
@picky: Nice catch! Should be <= 8. @Jane: Can you please be more specific? The IE team uses SharePoint with IE8 every day.
Anonymous
March 20, 2009
Oh well, may be you should not fix that overflow path... <div> <dl><dt>Title</dt><dd>... Content .. </dd></dl> </div> 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... Weird...
Anonymous
March 20, 2009
Oh forgot to add Div is called by a function to display: block and was normally display: none, not overflow: hidden
Anonymous
March 20, 2009
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 :)
Anonymous
March 21, 2009
So far so good, but when is IE finally going to stop showing local filesystem items opened from the Windows Shell in IE history?
Anonymous
March 21, 2009
So far so good, but when is IE finally going to stop showing local filesystem items opened from the Windows Shell in IE history?
Anonymous
March 21, 2009
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.
Anonymous
March 21, 2009
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.
Anonymous
March 21, 2009
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.
Anonymous
March 21, 2009
@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.
Anonymous
March 21, 2009
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.
Anonymous
March 21, 2009
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.
Anonymous
March 21, 2009
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.
Anonymous
March 21, 2009
Sorry, that should have said drives are not lettered on Unix platforms, not that they are not named.
Anonymous
March 21, 2009
<<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.
Anonymous
March 21, 2009
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.
Anonymous
March 21, 2009
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?
Anonymous
March 23, 2009
@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?
Anonymous
March 23, 2009
The comment has been removed
Anonymous
March 23, 2009
@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
Anonymous
March 23, 2009
Was it considered to just send .filename instead? That would still be "correct", and have a backslash to scan for.
Anonymous
March 24, 2009
@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.
Anonymous
March 24, 2009
@EricLaw: Could you provide a list of specific sites and firmwares that have this problem, so that we can verify the issue?
Anonymous
March 26, 2009
@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 thanks!
Anonymous
April 09, 2009
Uploading File Fails in IE8 due to Security Fix for INPUT type=file
Anonymous
May 19, 2009
In testing with Internet Explorer 8 we discovered a problem in uploading files. This applies to both

Freigeben über

RTM Platform Changes

Comments

Zusätzliche Ressourcen

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