Tuesday, May 6th, 2008
Category: IE
, Browsers
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: XmlHttpRequest, IE, Browsers
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);
-
}
-
return baseUrl + relativeUrl;
-
}
-
function loadUsingScriptTag(url) {
-
… do JSONP here if we want
-
}
-
}
-
I think that says.... please just implement the standard IE team! :)
Thursday, April 17th, 2008
Category: IE, Browsers, Tip
Johan Sörlin found that sometimes his unload event never fired in IE:
We recently found a serious bug in IE where the unload event wouldn’t fire on a specific page we had on a site. After some bug tracking we found out that the unload event never fired since all the contents of the page hadn’t finished loading before we navigated to another page.
This is a major problem since the unload event is commonly used to clear circular references etc in IE to prevent memory leaks. So this bug makes all Ajax libraries/frameworks out there that depend on the unload event on IE to fail if the page is unloaded before the contents of the page finished loading.
Here is an example of the bug, run the page in IE and follow the instructions on the page.
He then produced a work around:
JAVASCRIPT:
-
-
function fixUnload() {
-
// Is there things still loading, then fake the unload event
-
if (document.readyState == 'interactive') {
-
function stop() {
-
// Prevent memory leak
-
document.detachEvent('onstop', stop);
-
-
// Call unload handler
-
unload();
-
};
-
-
// Fire unload when the currently loading page is stopped
-
document.attachEvent('onstop', stop);
-
-
// Remove onstop listener after a while to prevent the unload function
-
// to execute if the user presses cancel in an onbeforeunload
-
// confirm dialog and then presses the stop button in the browser
-
window.setTimeout(function() {
-
document.detachEvent('onstop', stop);
-
}, 0);
-
}
-
};
-
-
function unload() {
-
alert('Unload event occured.');
-
};
-
-
window.attachEvent('onunload', unload);
-
window.attachEvent('onbeforeunload', fixUnload);
-
In other IE news, remember not to have a CSS class that uses the (valid) _ character as IE 6 won't be happy.
Thursday, April 10th, 2008
Category: IE, Browsers, Security
Microsoft has put out a set of security updates, and one of them is discussed in a post IE8 Security Part I: DEP/NX Memory Protection.
Over the next several weeks, we’ll blog in greater detail about some of the security improvements in Beta 1, such as the new Safety Filter, greater control over ActiveX controls, and new AJAX features for safer mashups (XDomainRequest and XDM). This is not a complete list of our security investments for the release; we will have more to talk about during future milestones.
Internet Explorer 8 security features target three major sources of security exploits: social engineering, Web server, and browser-based vulnerabilities. This post will cover IE8 Data Execution Prevention (DEP), a feature that mitigates browser-based vulnerabilities.
Eric then goes into detail on DEP:
Internet Explorer 7 on Windows Vista introduced an off-by-default Internet Control Panel option to “Enable memory protection to help mitigate online attacks.” This option is also referred to as Data Execution Prevention (DEP) or No-Execute (NX).
We have enabled this option by default for Internet Explorer 8 on Windows Server 2008 and Windows Vista SP1 and later.
DEP/NX helps to foil attacks by preventing code from running in memory that is marked non-executable. DEP/NX, combined with other technologies like Address Space Layout Randomization (ASLR), make it harder for attackers to exploit certain types of memory-related vulnerabilities like buffer overruns. Best of all, the protection applies to both Internet Explorer and the add-ons it loads. No additional user interaction is required to provide this protection, and no new prompts are introduced.
They also posted about:
Wednesday, April 9th, 2008
Category: IE
The following email was sent out to Microsoft MVPs (read: friendly people :), but we should give them our honest feedback too:
Microsoft has recently released a public beta of IE8. Standards and security are of top importance in this release. To that end, the IE team is planning on releasing IE8 in full standards mode. Releasing in Full Standards Mode offers many benefits in the long term, but short term, could cause some end-user and developer issues. We would love to understand your thoughts around the impact of this specific issue and invite your suggestions on how we can best communicate it.
If you have thoughts and feedback on IE 8 releasing in full standards mode, please respond to the questions below and send your reply to jasontil@microsoft.com with “[IE8 Community Feedback]” in the subject line by this Friday, April 11th at Noon, PDT.
1) IE8 releasing in expected to release in “standards mode”.
(a) What do people in your communities space think about this decision?
(b) What do you predict the impact to be on the customer and/or Developer experience?
(c) Do you have a recommendations on how best to share this information?
2) Our current plan is to communicate this heavily with web site owners and developers. We will be contacting top sites directly, distributing developer FAQs, and writing Knowledge Base articles on authoring to these standards.
(a) Do you think that will be effective at improving the customer experience?
(b) Are there other suggestions do you could offer to transition web sites to be standards-based or to improve the experience for users?
3) Is there anything else you or those in your communities wish to tell us about this issue to improve how we react and respond as Internet Explorer advances to release?
58827.2 rating from 17 votes
Wednesday, April 2nd, 2008
Category: IE, Browsers, CSS
Howard Rauscher tipped us off to this IE 8 ticket that talks about how opacity and IE 8 strict mode do not jive:
Description
IE8 Strict Mode correctly omits the filter: alpha(opacity=xx) in CSS
which allows the user to specify the opacity in pre-IE8 browsers but
does not implement the CSS3 opacity setting. While I understand that
opacity is part of the CSS3 spec which is not finalized, this leaves
developers with an odd regression in functionality where it is no
longer possible to change opacity on css elements (where as it was
with IE 5.5, IE 6.0, IE 7.0, Mozilla Firefox, Apple Safari, among
others).
Comments
So the fact that this has been labeled as by design suggests that IE8
will be the only browser produced in the last 10 or so years that will
not support opacity in its strictest mode. Thats rediculous. I
understand the wish to be standards compliant but how hard is it to
implement reading the css3 opacity tag (even if it still makes use of
the filter, at least it will exist as a future standards equivelant
tag).
At some point standards has to give way to usability. Mozilla, Opera,
Apple all realize that a few tags that maybe are not official CSS 2
spec still need to be available. If major functionality is missing
from the standards compliant version of IE8, who will use it, even if
it is standards compliant.
You'll have a whole host of websites that are standards compliant but
need a few features unavailable in standards compliant mode. So these
websites will be setup to use IE7 mode. And then when IE9 comes out
you'll have to deal with compatibility issues all over again.
Posted by Ames on 3/17/2008 at 3:59 PM
A pretty crazy regression no?
Wednesday, March 26th, 2008
Category: IE, Browsers, Gears
Alex Russell isn't talking about the N+1 select problem when he references the Joel Spolsky piece on IE 8.
We want to applaud the IE 8 team for the work that they have done, but also keep pushing to make sure that it really happens:
I was reminded of a discussion last Friday where I voiced my frustration that as much as IE 8 looks to be a good point release, we know next to nothing about it’s intentions with regards to ship dates or auto-update deployment. I’m not talking exact dates or firm plans here, just “within the next N months” or “we’ll wait N (plus or minus 3) months to put it on Windows Update”. Knowing those things fill in the missing bits of making any plans around IE. No plan is complete without a “who”, a “how”, and a “when”. Right now we’ve got the first two bits (ish), but the third is a mystery….which means we don’t have a collective plan.
By the transitive property of IE being the monopoly market-share browser, we can clearly state that we have no idea when the Open Web will be revved. This is based solely on the IE team’s lack of commitments. This is a terrible result, and one which I think the frenzy over IE 8’s features has obscured.
He then talks about the browser platform:
Which brings us back to IE being a platform. The bits that webdevs care about must change in order for the web to get better, and today webdevs are platform customers without a commitment from their biggest supplier to ship another version beyond the one they’re working on now. If this were any other sort of platform, this would never ever fly. Code-in-escrow would be demanded along with a roadmap, or at a minimum a commitment to an N+1 version in a reasonable time frame. But webdevs don’t have that leverage by virtue of the disintermediation that browser economics now demand.
So as webdevs, we must be canny enough to find a way to “better” which doesn’t put all of our eggs in any particular basket. Every browser that we depend on either needs an open development process or it needs to have a public plan for N+1. The goal is to ensure that the market knows that there is momentum and a vehicle+timeline for progress. When that’s not possible or available, it becomes incumbent on us to support alternate schemes to rev the web faster.
And, how all web developers can push forward with projects like Gears:
Google Gears is our best hope for this right now, and at the same time as we’re encouraging browser venders to do the right thing, we should also be championing the small, brave Open Source team that is bringing us a viable Plan B. Every webdev should be building Gear-specific features into their app today, not because Gears is the only way to get something in an app, but because in lieu of a real roadmap from Microsoft, Gears is our best chance at getting great things into the fabric of the web faster. If the IE team doesn’t produce a roadmap, we’ll be staring down a long flush-out cycle to replace it with other browsers. The genius of Gears is that it can augment existing browsers instead of replacing them wholesale. Gears targets the platform/product split and gives us a platform story even when we’re neglected by the browser vendors.
Gears has an open product development process, an auto-upgrade plan, and a plan for N+1.
At this point in the webs evolution, I’m glad to see browser vendors competing and I still feel like that’s our best long-term hope. But we’ve been left at the altar before, and the IE team isn’t giving us lots of reasons to trust them as platform vendors (not as product vendors). For once, we have an open, viable Plan B.
Disclaimer: I work on the Gears team!
Monday, March 17th, 2008
Category: IE, Browsers, Performance
Now that we have our hands on IE 8 beta, we see developers testing the various features. Ryan Breen continues IE 8 tests on the new connection limits and parallelism:
A few weeks ago, I discussed IE8’s improved connection parallelism, specifically the increase from 2 concurrent connections per host to 6. One open question was the total number of connections allowed — my speculation was that the IE team would stick with a max of 6 rather than triple that value as well.
I was wrong. The new max is an astonishing 18 concurrent connections (editor: limited to 3 hostnames, you can get more concurrent connections with more hostnames).
This is actually slightly faster than the CNAME trick applied to previous IE versions as it does not incur any hostname resolution cost when establishing the first connections.
Sounds good! However, then Ryan discovered some strange results. When running tests against a dreamhost application there would be some downloads that would be very slow indeed, resulting in worse performance than before. Ryan has a hypothesis:
I suspect that my hosting provider (Dreamhost) simply can’t keep up with the dramatic increase in connection parallelism. 18 connections is simply too much of a good thing, and it will present a scaling problem for those who are on small to medium hosts. 10 users hitting at the same time will yield 180 concurrent connections, a pretty significant number for smaller providers.
Dial-up and cellular network users are also likely to be negatively impacted by this change. In the high broadband world where latency is the dominant factor, greater connection parallelism is a boon. But in bandwidth constrained networks, it just leads to thrash where progress is slowed by all the connections trying to share a small pipe.
I’m curious what sort of testing Microsoft has conducted to determine the impact of this change. The connection parallelism approach is used widely (including by the Virtual Earth team), and some servers may not be ready for the increase. My tests were conducted against only one host, but if similar results are experienced elsewhere, this may fall under the rubric of “don’t break the web.”
Tuesday, March 11th, 2008
Category: IE, Browsers, Performance
Steve Souders has posted on IE 8 and performance improvements.
One new nugget of information that I haven't seen anywhere else is the fact that scripts are now loaded in parallel (and execution is still serial of course):
Increasing parallel downloads makes pages load faster. (For users with slower CPUs or Internet connections it could possibly be worse, but for most users it’s faster.) The HTTP 1.1 spec recommends that browsers only download two items in parallel per hostname, but the spec was written in 1999. Today’s clients and servers can support more parallel downloads, so IE8 has increased the number of downloads per hostname from 2 to 6.
Increasing parallel downloads makes pages load faster, which is why downloading external scripts (.js files) is so painful. Firefox and IE7 and earlier won’t start any parallel downloads while downloading an external script. These days, with the greater adoption of Web 2.0 and DHTML, many sites contain multiple scripts which means those pages will have long periods where all other downloads are blocked. It’s understandable that these scripts need to executed sequentially (code dependencies) but there’s no reason they couldn’t be downloaded in parallel. And that’s exactly what IE8 has done. It’s the first browser I’ve seen that has implemented this critical improvement for load times. Facebook has got to be thankful for this. They have 17 external scripts on their page. In most browsers this causes the page to load slowly for users coming in with an empty cache. But for users coming in using IE8 the scripts load ~80% faster because they’re loaded in parallel. In this screenshot showing HTTP requests for Facebook we see parallel script loading, and we also see them loading 6 at-a-time. Both of these IE8 enhancements dramatically speed up pages.
This dove tails nicely with the other items that we have already heard about:
- 6 downloads per host
- data: URIs, which means you embed your rounded corners
I wonder if IE 8 has a total maxconnections limit?
