Wednesday, July 9th, 2008
Category: Browsers
, IE
Tavs Dokkedahl sent in a great email about work that he and Allan Jacobs have done on bringing DOM event implementations to IE. Here it is in full:
About a year ago or so I put out the Uniform Event Model (UEM) script which
was an implementation of the W3C DOM 2 Event Interface for IE. As it turned
out that release was very premature - the script was simply incomplete and
definitely not ready for production use.
The design ideas however were good enough. Since then Allan Jacobs has
joined the JSLab team and together we have written a new version of UEM
which is much more stable and modular.
This first release includes support for:
- DOM 2 Event Interface in IE
- DOM 2 UIEvent Interface in IE
- DOM 2 MouseEvent Interface in IE
- DOM 2 Legacy keyboard handling in IE (fancy way of saying “handle it like
Firefox”)
The code is unobtrusive - no special syntax or semantics are needed. A lot
of documentation is available
There still exists issues with some types of events but at large the code is
stable and is performing well enough to be released to the public. Hopefully
we can get some feedback on how to improve it and catch some early errors.
The size of the script is about 32Kb (when minified) it its basic form but
additional modules are available for inclusion. The download page can be
found at http://www.jslab.dk/jdc.download.php
We are currently working on finishing the DOM 3 KeyboardEvent and DOM 3
textInput interfaces (for IE, Firefox, Opera and Safari) besides various DOM
corrections for other browsers than IE.
Thursday, July 3rd, 2008
Category: IE, Security
The IE8 team has created a blitz on its blog with a slew of posts on security. There is a ton of great stuff here, and is well worth going into detail on each post:
IE8 and Trustworthy Browsing
At first they set the scene:
This blog post frames our approach in IE8 for delivering trustworthy browsing. The topic is complicated enough that some context and even history (before we go into any particular feature) is important, and so some readers may find this post a bit basic as it’s written for a wide audience. In previous posts here, we’ve written about IE8 for developers: the work in standards support, developer tools, script performance, and more. In future posts, we’ll write about IE8 for end-users (beyond the benefits of improved performance, activities, and Web Slices). This post starts a series about trustworthy browsing, a topic important for developers and end-users and everyone on the web. By setting the context and motivation with this post, the next posts that dive into the details of IE8 will build on this foundation.
Trustworthy refers to one of our overall goals: provide the most secure and most reliable browser that respects user choice and keeps users in control of their machine and their information. For reference, Microsoft’s framework for Trustworthy Computing in general spans four areas: security, privacy, reliability, and business practices.
IE8 Security Part III: SmartScreen® Filter
For Internet Explorer 8, we’ve built upon the success of the Phishing Filter feature (which blocks over a million phishing attacks weekly) to develop the SmartScreen® Filter, a replacement that improves upon the Phishing Filter in a number of important ways:
- Improved user interface
- Faster performance
- New heuristics & enhanced telemetry
- Anti-Malware support
- Improved Group Policy support
IE8 Security Part IV: The XSS Filter
The XSS Filter operates as an IE8 component with visibility into all requests / responses flowing through the browser. When the filter discovers likely XSS in a cross-site request, it identifies and neuters the attack if it is replayed in the server’s response. Users are not presented with questions they are unable to answer – IE simply blocks the malicious script from executing.
With the new XSS Filter, IE8 Beta 2 users encountering a Type-1 XSS attack will see a notification.
IE8 Security Part V: Comprehensive Protection
As we were planning Internet Explorer 8, our security teams looked closely at the common attacks in the wild and the trends that suggest where attackers will be focusing their attention next. While we were building new Security features, we also worked hard to ensure that powerful new features (like Activities and Web Slices) minimize attack surface and don’t provide attackers with new targets. Out of our planning work, we classified threats into three major categories: Web Application Vulnerabilities, Browser & Add-on Vulnerabilities, and Social Engineering Threats. For each class of threat, we developed a set of layered mitigations to provide defense-in-depth protection against exploits.
Wednesday, June 11th, 2008
Category: IE
The IE team has created a new value for the X-UA-Compatible header in IE 8 IE=EmulateIE7.
We already had IE=7, which causes the page to be displayed in “IE7 Standards mode.” This forces both quirks and standards mode pages up that path, and people were asking for a solution that only pushes the non-quirks mode ones to change, thus the new option:
In response to the great IE8 Beta 1 feedback we’ve received so far, we are introducing the “IE=EmulateIE7†tag to address this problem. EmulateIE7 tells IE8 to display standards DOCTYPEs in IE7 Standards mode, and Quirks DOCTYPEs in Quirks mode. We believe this will be the preferred IE7 compatibility mode for most cases. Support for IE=EmulateIE7 is available now as part of the IE June Security Update for IE8 Beta 1. Installing this update will enable you to verify you’ve applied the EmulateIE7 tag to your site correctly.
Implementing the HTTP header is beneficial if a site owner wants most of their site to render as it did in IE7 or if there are no plans to update site content. Inclusion of this header honors any Quirks mode pages that belong to the site.
Using the meta-tag on a per-page basis is beneficial when the publisher wants to opt-in specific pages to render as they did in IE7.
The X-UA-Compatible tag and header override any existing DOCTYPE. Also, the mode specified by the page takes precedent over the HTTP header. For example, you could add the EmulateIE7 HTTP header to a site, and set specific pages to display in IE8 mode (by using the meta-tag with content=â€IE8â€).
Using the IE=EmulateIE7 compatibility tag is a simple way for users to continue their current experience when browsing your site until you can update with more standards-compliant content. Although adding this tag will prevent most display issues, you may also need to update your site to properly detect IE8. To learn more about IE8 document compatibility and browser detection, check out the IE Compatibility Center.
Monday, June 9th, 2008
Category: IE, Microsoft, Testing, Tutorial
Hedger Wang has been scanning a lot of Chinese blogs lately for solutions to IE6 and memory leak issues. One of the things he stumbled upon is a pretty nifty way of nulling the objects to stop memory leaks by using the try ... finally construct. So instead of this solution which leaks memory:
JAVASCRIPT:
-
-
function createButton() {
-
var obj = document.createElement("button");
-
obj.innerHTML = "click me";
-
obj.onclick = function() {
-
//handle onclick
-
}
-
obj.onmouseover = function() {
-
//handle onmouseover
-
}
-
return obj;//return a object which has memory leak problem in IE6
-
}
-
var dButton = document.getElementsById("d1").appendChild(createButton());
-
//skipped....
-
You can use the following which doesn't:
JAVASCRIPT:
-
-
function createButton() {
-
var obj = document.createElement("button");
-
obj.innerHTML = "click me";
-
obj.onclick = function() {
-
//handle onclick
-
}
-
obj.onmouseover = function() {
-
//handle onmouseover
-
}
-
//this helps to fix the memory leak issue
-
try {
-
return obj;
-
-
} finally {
-
obj = null;
-
}
-
}
-
var dButton = document.getElementsById("d1").appendChild(createButton());
-
}
-
More demos, proof of concept examples and the "finally" explanation is available on Hedger's blog: Finally, the alternative fix for IE6's memory leak is available
Category: IE, JavaScript, Performance
Tom Trenka has followed up his last post on String performance with a deep dive on IE that dispells the myth of Array.join.
Tom goes through tons of tests across versions of IE and using varying sizes of data.
In Conclusion
First things first—with the performance improvements with IE7, we no longer need to consider using an alternate path when doing large scale string operations; using Array.join in an iterative situation gives you no major advantages than using += in the same situation. In addition, the differences with IE6 were slight enough to allow you to not bother forking for that specific version.
The only time considering using an array as opposed to a string for these kind of operations is when you are aware that the fragments you are appending are very large (on the order of > 65536 bytes); doing this will cause the GC issues Dan Pupius talks about in his analysis of object allocation and the JScript garbage collector.
From there, we can progress to programming techniques—with Internet Explorer, it is much better to call Builder.append with as many arguments as possible than to simply iterate and push things in one at a time.
It is also better to start small; try to structure your string operations so that very large string operations are minimized. In this case, using a temporary buffer to assemble a set of strings together and then adding them to a much larger string is better than constantly adding small fragments to a larger string.
And as always, minimizing the size of an iteration will help get extra performance out of JScript.
The raw numbers have been made available to scour over.
Wednesday, June 4th, 2008
Category: Browsers, IE
Bill Gates gave his last talk, appropriately, to developers at TechEd. No matter what you think of the guy, he is an icon that helped create the software industry. Without him and Steve Jobs, who do we have? :)
In his speach he talked about Internet Explorer, and how IE 8 will have an update in a couple of months:
Gates also highlighted Microsoft's flagship Web technology, the Internet Explorer (IE) browser, which has been an asset and a curse for the company over the years. While it allowed Microsoft to secure its dominant position in Web-browsing technology, it also triggered Microsoft's U.S. antitrust woes, something that haunts the company to this day. IE also has taken a hit in the past several years as Mozilla Firefox, an open-source browser, has gained a loyal following, forcing Microsoft to step up development and make its own product more innovative.
Gates revealed that beta 2 of the next version of IE, IE 8, will be available in August. He also stumped for what has been his pet interest during his years at Microsoft -- natural human-interface technology that allows people to interact with computers in ways similar to how they interact with each other. Last week, Microsoft revealed that the next version of Windows, Windows 7, will include touchscreen technology, a fact he mentioned in his talked.
I have a funny feeling that we are going to see some really cool things to come out of IE 8. A few surprises.
Tuesday, May 20th, 2008
Category: Browsers, IE, Standards
IEBlog has posted about the IE 8 support of postMessage, which is great news.
They link to a MSDN article that discusses the support, and a use case.
Jeff Walden noted that "the interface implemented by the current IE8 beta lags the HTML5 specification by several revisions in backwards-incompatible ways, so if you're going to experiment with this, be aware that what you're doing will break in a future revision of IE8." and detailed the differences.
It appears that only Firefox 3 RC 1 and Webkit Nightly have implemented the current spec.
Tuesday, May 6th, 2008
Category: Browsers, IE
Whenever I see a post on the IE Blog that has a title like IE and XP SP 3 I hope to see "oh, and IE 6 users will be upgraded". How much pain would be relieved when IE 6 usage is minimal?
Unfortunately, I was disappointed again:
XPSP3 will continue to ship with IE6 and contains a roll-up of the latest security updates for IE6. If you are still running Internet Explorer 6, then XPSP3 will be offered to you via Windows Update as a high priority update. You can safely install XPSP3 and will have an updated version of IE6 with all your personal preferences, such as home pages and favorites, still intact.
Friday, April 18th, 2008
Category: Browsers, IE, XmlHttpRequest
Kris Zyp gives us a glimpse at a potential future with his 100 line Ajax wrapper that tries to do the right thing cross browser for the various cross-domain models:
With IE8’s new XDomainRequest feature, a new API is added for cross-site requests, instead of using the W3C cross-site access proposal. Just for fun, I thought I would provide a little glimpse of what the classic Ajax request wrapper function may look like for the next era of web developers. Just a few simple calls to XMLHttpRequest would be way too easy, so instead we get do this:
JAVASCRIPT:
-
-
function doRequest(method,url,async,onLoad,onProgress) {
-
var xhr;
-
if ((onProgress || isXDomainUrl(url)) && window.XDomainRequest) {
-
// if it is x-domain or streaming/incremental updates are needed we will use IE's XDomainRequest for IE
-
// streaming/interactive mode is broken in IE's XHR, but for some reason works in XDR (with onprogress), so we will
-
// need to use XDR if incremental updates are necessary
-
// see bug https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=334813
-
if (url.match(/^https:/) && !onProgress) {
-
// XDR doesn’t work for secure https communication
-
// see bug https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=333380
-
loadUsingScriptTag(url); // script tag insertion can be more secure than XDR
-
// in some situations because it supports https
-
return;
-
}
-
xhr = new XDomainRequest;
-
// relative paths don’t work in XDomainRequest, see bug https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=333275
-
if (!url.match(/^http:/)) { // test to see if it is an absolute url
-
url = absoluteUrl(location.href,url); // must have a function to turn it into an absolute url
-
}
-
if (!(method == “GET†|| method == “POSTâ€)) {
-
// XDomainRequest does not support methods besides GET and POST
-
// see bug https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=334809
-
// We will try to add the method as a parameter and hope the server will understand… good luck :/
-
url += “&method=†+ method;
-
method = “POSTâ€;
-
}
-
function xdrLoad() {
-
if (xhr.contentType.match(/\/xml/)){
-
// there is no responseXML in XDomainRequest, so we have to create it manually
-
var dom = new ActiveXObject(â€Microsoft.XMLDOMâ€);
-
dom.async = false;
-
dom.loadXML(xhr.responseText,200);
-
onLoad(dom);
-
}
-
else {
-
onLoad(xhr.responseText,200); // we will assume that the status code is 200, XDomainRequest rejects all other successful status codes
-
// see bug https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=334804
-
}
-
}
-
if (async === false) {
-
// XDomainRequest does not support synchronous requests
-
// see bug https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=336031
-
// so we will try to block execution on our own (which is not really possible in any reasonable manner)
-
var loaded;
-
xhr.onload = function() {
-
loaded = true;
-
xdrLoad();
-
}
-
xhr.open(method,url);
-
xhr.send(null);
-
while(!loaded) { // try to block until the response is received
-
// I am sure the user won’t mind just clicking OK so we can block execution
-
alert(â€Waiting for the response, please click OK because it probably is here nowâ€);
-
}
-
return;
-
}
-
else { // do an asynchronous request with XDomainRequest
-
xhr.onload = xdrLoad;
-
xhr.open(method,url);
-
xhr.onprogress = onProgress;
-
}
-
}
-
// we will mercifully skip all the branches for ActiveXObject(â€Microsoft.XMLHTTPâ€) to accomodate IE6 and lower
-
else {
-
xhr = new XMLHttpRequest; // use the standard XHR for same origin and browsers that implement cross-site
-
// W3C requests and streaming
-
xhr.open(method,url,async);
-
xhr.onreadystatechange = function() {
-
if (xhr.readyState == 3) // interactive mode
-
onProgress(xhr.responseText);
-
if (xhr.readyState == 4) // finished
-
onLoad(xhr.responseText,xhr.status);
-
}
-
}
-
xhr.send(null); // finally send the request whether it be XDR or XHR
-
-
// and supporting functions
-
function absoluteUrl : function(baseUrl, relativeUrl) {
-
// This takes a base url and a relative url and resolves the target url.
-
// For example:
-
// resolveUrl(â€http://www.domain.com/path1/path2″,â€../path3″) ->â€http://www.domain.com/path1/path3″
-
//
-
if (relativeUrl.match(/\w+:\/\//))
-
return relativeUrl;
-
if (relativeUrl.charAt(0)==’/') {
-
baseUrl = baseUrl.match(/.*\/\/[^\/]+/)
-
return (baseUrl ? baseUrl[0] : â€) + relativeUrl;
-
}
-
//TODO: handle protocol relative urls: ://www.domain.com
-
baseUrl = baseUrl.substring(0,baseUrl.length - baseUrl.match(/[^\/]*$/)[0].length);// clean off the trailing path
-
if (relativeUrl == ‘.’)
-
return baseUrl;
-
while (relativeUrl.substring(0,3) == ‘../’) {
-
baseUrl = baseUrl.substring(0,baseUrl.length - baseUrl.match(/[^\/]*\/$/)[0].length);
-
relativeUrl = relativeUrl.substring(3);
-
