sorted by: recent | see :
popular
Content Tagged with IE + Browsers
Researchers: 637 million browser users at risk
Web Browsers: Speed Testing the Latest Web Browsers
IE 8 beta 2 coming in August
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.
IE 8 and Cross Document Messaging
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.
IE and Windows XP Service Pack 3… still IE 6
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.
100 Line Ajax Wrapper
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:
-
-
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! :)
Are you sure your unload handler is firing in IE?
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:
-
-
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.
IE 8 Security Updates
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:
- IE Automatic Component Activation Now Available: The "click to activate" behavior, formerly required for ActiveX controls embedded in some webpages, is now permanently removed from Internet Explorer.
- IE April Security is Now Available: The IE Cumulative Security Update for April 2008 is now available via Windows Update.
IE 8 strict mode doesn’t allow for CSS opacity?
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?
Progress Is N+1
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!
IE 8 Connetion Parallelism Issues
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.”
IE 8 and 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?
IE 8 on Acid
The IE team posted that they were passing Acid2 a few months ago, yet people are seeing a broken face when they tested with IE 8 beta.
Phil Nachreiner of IE explained the situation:
Although we said that IE8 Beta 1 passes the ACID2 test, some of you may be seeing results like the image above; we thought we should explain what’s going on. IE8 passes the official ACID2 test hosted on http://www.webstandards.org/files/acid2/test.html. (Note, this seems to be a popular destination at the moment. You may have trouble reaching the site.)There are also a number of copies of this test around the net. One popular copy that I’ve seen of late is http://acid2.acidtests.org/
IE8 fails the copies of ACID2 due to the cross domain security checks IE performs for ActiveX controls. Since IE does not natively handle HTML content in the OBJECT tag, but rather uses IE’s rendering engine as an ActiveX to display this HTML content, the same cross domain security checks also apply.
Given that, let’s take a look at how the acidtests.org copy from above relies on OBJECT fallback to render the eyes. Here’s the snippet of the test for the eyes:
HTML:
IE stops the OBJECT fallback process at the highlighted line above. The team and I involved in this work decided that this is the right thing to do because IE would have to allow navigation to this cross domain content in order to determine if the failed resource is a 404 HTTP error code or any of the other failed resource indicators that are part of the standard. To maintain compatibility and be secure by default we didn’t want to invoke fallback either, as original web authors might not have intended this behavior. We started with the most secure solution and are now looking into whether we can safely loosen this restriction in a future beta.
With all that said let’s also take a look at the official ACID2 page hosted by www.webstandards.org:We see: