Planet Dojo

IE8 is now available on Windows XP for 5 more languages

IEBlog - Fri, 06/26/2009 - 21:27

We are pleased to announce the availability of Internet Explorer 8 on Windows XP for 5 additional languages today. These languages were tagged as “Coming Soon” in our blog post early June. Please visit our World wide sites page to download Internet Explorer in your preferred locale/ language.

Languages newly available on Windows XP:

For reference, here’s a table with the full list of IE8 availability:

LANGUAGE<?xml:namespace prefix = o />

Windows Vista

Windows XP

Windows Server 2008

Windows Server 2003

x86

x64

x86

x64 PRO

x86

x64

x86

x64

Arabic

Available

Chinese (Traditional)

Chinese (Simplified)

Chinese (Hong Kong)

Czech

Danish

Dutch

English

Finnish

French

German

Greek

Hebrew

Hungarian

Italian

Japanese

Korean

Norwegian

Polish

Portuguese (Portugal)

Portuguese (Brazil)

Russian

Spanish

Swedish

Turkish

Bulgarian

Croatian

Estonian

Latvian

Lithuanian

Romanian

Serbian (Latin)

Slovenian

Slovak

Thai

Ukrainian

Albanian

Assamese

Basque

Bengali (Bangladesh)

Bengali (India)

Bosnian (Cyrillic)

Bosnian (Latin)

Catalan

Gujarati

Hindi

Indonesian

Kannada

Kazakh

Konkani

Kyrgyz

Macedonian

Malay (Brunei Darussalam)

Malay (Malaysia)

Malayalam

Marathi

Oriya

Punjabi

Serbian (Cyrillic)

Tamil

Telugu

Uzbek (Latin)

Vietnamese

Thanks,
Vishwac Sena Kannan,
International Program Manager | Internet Explorer.

Categories: Web Developement

Declaring Security

IEBlog - Thu, 06/25/2009 - 18:45

Recently, a number of people have asked me what I think about Mozilla’s Content Security Policy draft spec. Back in January, I went on record as being someone who thinks that CSP is a good idea.

CSP is a mechanism for declarative security, whereby a site communicates its intent and leaves it up to the user-agent to determine how to enforce it.

There are a number of benefits to declarative security mechanisms:

Reduced compatibility risks. Because sites must opt-in and declare what, if any, restrictions they want, new security features may be added to the user-agent with decreased compatibility fallout.
Clear intent. By plainly declaring which restrictions are desired, browsers need not try to “guess” the site’s intent. For instance, when explaining that frame-breaking JavaScript cannot be relied upon to prevent ClickJacking, Kymberlee noted:

If you don’t design something to prevent a security vulnerability, odds are that it doesn’t do a very good job of doing it.

Because declarative security features are designed solely to mitigate security threats, browsers may implement the restrictions however they want, and can patch any holes found in the restrictions without unexpectedly breaking unrelated functionality.
Usability. By allowing a site to declare its security policy, browsers can make some security decisions on the user’s behalf.
Auditability. It is straightforward to build tools that scan content for policies and determine if they meet the publishing organization’s expectations.

Internet Explorer has a rich history in this space: HTTPOnly, SECURITY=RESTRICTED frames, X-Content-Type-Options, X-Download-Options, X-Frame-Options are all declarative security mechanisms first implemented in IE, and now supported by other browsers to varying degrees.

The ideas behind the CSP draft are not new, and it is but one of many proposals for declarative security, from BEEP to HTML5 sandboxing. In some respects it overlaps with other mechanisms for restricting script, although if CSP is successful, new directives will likely be created to provide uniform specification of the available policies.

While valuable, declarative security mechanisms are not without their challenges:

Plugins. Unless plugins have been blocked outright, they must be aware of, and enforce, the declared security policies. Because plugins are provided by many different vendors, this requirement may prove challenging in real-world deployments.
Misconfiguration. CSP is only as valuable as the policies configured by the developer or administrator, and a number of major sites have suffered breaches due to misconfiguration of security policy files. Ira Winkler claims [p143] that government studies indicate that 70% of computer intrusions are a result of configuration problems.
New attack surface. The very mechanisms used to implement CSP will be probed by hackers, and comprehensive fuzzing and penetration testing will be required to help mitigate the attack surface added. Furthermore, if a hole is found that enables an attacker to circumvent a given policy within a given user-agent, that user-agent’s reputation may be harmed-- even if other user-agents do not attempt to support that policy.
Debuggability. Web developers already face significant challenges in developing their pages, and introducing new security policies will require that tools be updated to clearly indicate when content has been blocked due to security policies. Sites might inadvertently set overly restrictive policies and failure to catch mistakes via comprehensive testing could lead to a confusing user experience.
Dynamic content. It may prove difficult to author workable policies for some dynamic-content scenarios (e.g. email composition, blog authoring, etc) because the user may herself add content to a given page from origins unknown to the web developer.
Adoption. Perhaps the biggest challenge for CSP and competing proposals is related to the fact that they offer “off-by-default” security. While this is great for compatibility, it’s not-so-great for protecting sites and users, because benefits are only attained after web developers update their sites. To succeed, CSP must balance power/flexibility against simplicity/understandability.

No security technology is a panacea, and for comprehensive protection, I think browsers need to offer both:

Rich security APIs that enable sites to prevent XSS attacks.
Automated protections to shield sites that can’t/won’t update their code immediately / ever.

To combat XSS attacks, IE8 introduced a number of attack-surface-reductions, a few new APIs, as well as the declarative security mechanisms (X-* headers) mentioned above. But we knew that sites wouldn’t immediately adopt these APIs and declarative security features, so we built the XSS Filter, an on-by-default, no-questions-asked, no-code-changes required mechanism which helps mitigate the most common types of XSS attacks in the wild today.

I’m eager to see the progress on CSP, which I believe is a promising approach to helping websites secure themselves against the growing alphabet soup of web threats. You can provide feedback on the CSP draft spec using Mozilla’s Talk page.

-Eric Lawrence

Categories: Web Developement

Updated Firefox 3.5 release candidate available for download

Mozilla Developer News - Thu, 06/25/2009 - 05:13

Please note: the Firefox 3.5 Release Candidate is a public preview release intended for developer testing and community feedback. It includes many new features as well as improvements to performance, web compatibility, and speed. We recommend that you read the release notes and known issues before installing this release candidate.

A new version of the Firefox 3.5 Release Candidate is now available for download, containing fixes based on the feedback obtained from the previous release candidate. This updated milestone is focused on providing a preview of the functionality provided by the new features and changes that will be included in Firefox 3.5. A video highlighting some of these new features is also available. Ongoing planning for Firefox 3.5 can be followed at the Firefox 3.5 Planning Center, as well as in mozilla.dev.planning and on irc.mozilla.org in #shiretoko.

Testers can download Firefox 3.5 Release Candidate builds for Windows, Mac OS X, and Linux in over 70 different languages. Developers should also read the Firefox 3.5 for Developers article on the Mozilla Developer Center.

Users already running a Firefox 3.5 Beta or Release Candidate can obtain an update to this latest Release Candidate version by selecting “Check for Updates…” from the “Help” menu.

Note: Please do not link directly to the download site. Instead we strongly encourage you to link to this Firefox 3.5 Release Candidate milestone announcement so that everyone will know what this milestone is, what they should expect, and who should be downloading to participate in testing at this stage of development.

Categories: Web Developement

Benchmarking Is Hard: Reddit Edition

Alex Russell - Thu, 06/25/2009 - 02:22

In which I partially defend Microsoft and further lament the state of tech “journalism”.

A very short open letter:

Dear interwebs:

Please stop mis-representing the results of benchmarks. Or, at a minimum, please stop blogging the results in snide language that shows your biases. It makes the scientific method sad.

Thank you.

Alex Russell

Today’s example of failure made manifest comes via Reddit’s programming section (easy target, I know), but deserves some special attention thanks to such witty repartee as:

Using slow-motion video? What a great idea. Maybe we can benchmark operating systems like that.

Maybe we can….and maybe we should. It might yield improvements in areas of OS performance that impact user experience. With a methodology that represents end-user perception, you should be able to calculate the impact of different scheduling algorithms on UI responsiveness, something that desktop Linux has struggled with.

The test under mockery may have problems, but they’re not the ones the author assumes. It turns out that watching for visual indications of “doneness” is a better-than-average way to judge overall browser performance (assuming fixed hardware, testing from multiple network topologies, etc.). After all, perceived performance in browsing is all that matters. No one discounts a website’s performance because when you visit they happen to let browsers cache resources that get used across pages or because they use a CDN to improve resource loading parallelism. In the real world, anything you can do to improve the perceived latency of a web site or application is a win.

MSFT’s test methodology (pdf) does a good job in balancing several factors that affect latency for end-users, including resources that are loaded after onload or in sub-documents, potential DNS lookup timing issues, and the effects of network-level parallelism on page loading. Or at least it would in theory. The IE team’s published methodology is silent on points such as how and where DNS caches may be in play and what was done to mitigate them, but the level of overall rigor is quite good.

So what’s wrong with the MSFT test? Not much, except that they didn’t publish their code or make the test rig available for new releases of browsers to be run against. As a result, the data is more likely to be incorrect because it’s stale than to be incorrect due to methodology problems. New browser versions are being released all the time, rendering the conclusions from the Microsoft study already obsolete. Making the tests repeatable by opening up the test rig or filling in the gaps in the methodology would fix that issue while lending the tests the kind of credibility that the Sun Spider and V8 benchmarks now enjoy.

This stands in stark opposition to this latest “benchmark”. Indeed, while the source code was posted, it only deepens my despair. By loading the “real world sites” from a local copy, much of the excellent work being done to improve browser performance at the network level is totally eliminated. Given the complexity of real-world sites and the number of resources loaded by say, Facebook.com, changes that eliminate the effects of the network make the tests highly suspect. While excoriating JavaScript benchmarks as not representing the real world accurately, the test author eliminated perhaps the largest contributor to page loading latency and perceived performance. Ugg.

Instead of testing real-world websites (where network topology and browser networking makes a difference), the author tested local, “dehydrated” versions of websites. The result is that “loading times” weren’t tested, but rather a test of “local resource serving times and site-specific optimizations around the onload event” was run . Testing load times would have accounted for resources loaded after the onload event fired, too. There’s reason to think that neither time to load from local disk nor time for a page to fire the onload handler dominate (or even indicate) real world performance.

I’m grateful that this test showed that Chrome loads and renders things quickly from local disk. I also have no doubt that Chrome loads real websites very quickly, but this test doesn’t speak to that.

It’s frustrating that the Reddits and Slashdots of the world have such poor collective memory and such faulty filtering that they can’t seem to keep themselves from promoting these types of bias re-enforcing stories on a regular basis. Why, oh why, can’t we have better tech journalism?

Categories: Dojo Developers

Online Shrinksafe App Fixed

Alex Russell - Wed, 06/24/2009 - 06:10

I’m not sure how long it was b0rked, but the online ShrinkSafe app is back up and working.

Categories: Dojo Developers

XRegExp 1.0

Flagrant Badassery - Wed, 06/24/2009 - 02:29

After stalling for nearly a year, I've finally released XRegExp 1.0, the next generation of my JavaScript regular expression library. Although it doesn't add support for lookbehind (as I've previously suggested) due to what would amount to significant inherent limitations, it fixes a couple bugs, corrects even more cross-browser regex inconsistencies, and adds a suite of new regular expression functions and methods that make writing regex-intensive JavaScript applications easier than ever. One of these new functions, XRegExp.addToken, fundamentally changes XRegExp's implementation and allows you to easily create your own XRegExp plugins.

Here's XRegExp's abbreviated feature list from the brand new xregexp.com (which includes extensive documentation and code examples):

Adds new regex and replacement text syntax, including comprehensive support for named capture.
Adds two new regex flags: s, to make dot match all characters (aka singleline mode), and x, for free-spacing and comments (aka extended mode).
Provides a suite of 12 functions and methods that make complex regex processing a breeze.
Automagically fixes the most commonly encountered cross-browser inconsistencies in regex behavior and syntax.
Lets you easily create and use plugins that add new syntax and flags to XRegExp's regular expression language.

The full list of changes can be seen in the changelog. Please let me know if you find any bugs or have any suggestions for the library. I'd also love to hear about projects or sites that are using XRegExp (I've got a few listed on the XRegExp homepage now).

Categories: Web Developement

Internet World Day 1, W3C Widgets and some other impressions

Uxebu - Tue, 06/23/2009 - 21:59

Today was the first day of the Internet World here in Munich. It is accompanied by RIA World and Mobile Vision, so you get three conferences at once. Unfortunately their schedules are not synchronized, pretty uncomfortable. This event is a mix of conference and fair. You can find and talk to a lot of (mostly) german companies and get all the infos you need. And on the other hand you can get some information about those three topics in the talks at the conference. And as usual the beer at the after-party is for free, even for those who are only there to see the fair and don’t have to pay, as I understood it. So come for a free beer :-).

Just a major flaw in the organization of this event is this big booklet that you need to look up the schedule, it’s not really handy and I wished a lot of times I had a phone that runs EventNinja ;-). Yes, this is our app. Unfortunately my SonyEriccson has no W3C widget runtime available, but hopefully their Symbian-powered phone that will come out (as I heard today) will have one, though I will probably switch to Android or the Palm Pre anyway.

The topics covered at those three conferences are not as bleeding-edge as we like them to be :-). But this is ok, since it is a more business-oriented conference. Though there are quite some old facts around and the mobile world just moves much faster than some of the talks at this conference do. It was also funny that relatively old facts e.g. about the features and some of the fun apps that exist for the iPhone still seemed to amuse the people.
But probably the worst fact about this conference is that there is no free WLAN, you have to pay 24€ for 8h, and that is the Internet World Congress? Hallo? Sorry, but this is really not state of the art, I hope the discuss&discover will do better there.

Rely on Cloud Service?

I just heard that google analytics was guilty for bringing down pages like bild.de for a day. Because the page relied on google analytics to be loaded fully, but due to the down time of this google service the page never loaded in the user’s browser. Sorry, but in this case the solution is not the SLA or kicking out the JavaScript, just look at the Dojo module dojox.analytics, which Pete Higgins wrote and which does what should be done in this case, load the script after the relevant content was loaded, asynchronously. So please make the developers responsible, not the service provider. If you are relying on this service, make sure that failure is a case you planned for. Don’t use the cloud if you don’t know what the implications are!

W3C widgets

Since Mobile Vision is one of the conferences and we are also active in the mobile space, I need to state that the W3C widgets, as e.g. Vodafone is already pushing them, had been very much ignored here. How much (mobile) vision do you get here?
Read the Introduction to W3C Widgets by PPK to get an overview of what these things are. So let me just summarize the advantages and differences of W3C widgets compared to the usual native apps.

Allows deployment to multiple mobile platforms (and the browser of course too)
Rapid prototyping is much faster and cheaper
Uses the standard technologies HTML, CSS and JavaScript
Therefore a much larger potential developer base

Of course there are new things to consider. You need to learn about the distribution ways (AppStores, etc.), how to deploy and you mostly have to sign your apps. But all those things easily outweigh the pains you need to go through when learning all the native technologies.

Well, maybe we are too spoiled from conferences like Ajax Experience, Ajax in Action and Mobile2.0.

Categories: Companies using Dojo

Working with disabled (the attribute)

weba11y: Becky Gibson - Tue, 06/23/2009 - 20:57

Once again I was bitten by the manner in which the difference browsers report the value of the disabled attribute. I decided to test the different ways of using the disabled attributes and record my results. When writing JavaScript I generally use the object.getAttribute("attributeName") syntax to get an attribute value. However, this will [...]

Categories: Dojo Developers

Appropriately styling the drag handles

DojoCampus - Tue, 06/23/2009 - 17:12

When using drag handles, there is a need to notify the user where the handle is. It is custom that an element that can be dragged notifies it by changing the cursor once the cursor is over the element. Usually, the cursor in use for such notification is the move cursor. So in order [...]

Categories: Dojo Developers, Web Developement

Unobtrusive JavaScript Typing via JSON Schema Interfaces

SitePen - Tue, 06/23/2009 - 17:05

One of the frequently expressed frustrations with JavaScript, especially from users coming from more static languages, is the lack of typing capabilities in JavaScript. Typing provides the ability to define and enforce contracts between interfaces such that interactions can be validated before violated assumptions result in later difficult-to-find bugs. On the other hand, many users that have grown fond of JavaScript have come to enjoy the fast and free style, and the minimalism of simply defining behavior without needing to make extra type definitions. However, these two coding preferences do not need to be mutually exclusive.

The abandoned ES4 effort made a valiant attempt to add typing (without losing dynamism) via gradual typing; however this still demanded the inclusion of intrusive typing annotations—thus adding type constraints to code polluted the otherwise simple direct JavaScript programming style necessitating more complex, difficult-to-follow code. Other efforts include libraries to define types on functions without extending syntax.

It is now possible to unobtrusively define type constraints on properties and methods in JavaScript with portable JSON schema based definitions called JSON schema interfaces (JSI). JSI is a typing system for JavaScript that does not force any new syntax on JavaScript. Schema structures can be used to define the type constraints in a way that works with existing JavaScript classes and objects.

The new typing module can be used both as a standalone bundle (with the JavaScript JSON schema library) which can be downloaded now. It also can be used as a Dojo module, available as dojox.lang.typed. Adding type constraints to JavaScript classes is very simple; the type constraints follow the JSON schema structure, where the class acts as the root of the schema. One can define property constraints in the properties property. The JSI extension to standard JSON schemas also allows method signatures to be defined in the methods property, with the ability to define the types for parameters and return values.

Using Typed Classes

To demonstrate, first we will create a normal JavaScript class using the standard prototype pattern:

Balloon = function(diameter){
  this.diameter = diameter;
};
Balloon.prototype = {
  getVolume: function(){
     return Math.pow(this.diameter, 3) * Math.PI / 6;
  },
  setVolume: function(volume){
     this.diameter = Math.pow(volume * 6 / Math.PI, 1/3);
  }
};

This class should work fine on its own, but if we want to define constraints to ensure that its interface is properly exposed and used as expected, we can declare the class as typed and add type constraints. Using the standalone library, we first define the class as type-able:

Balloon = typed(Balloon);

And now we can define constraints:

Balloon.properties = {
  diameter:{
     type:"number",
     minimum: 0,
     description:"This is the diameter of the balloon"
  }
};

Now we can try out our constraints:

// this will work normally
goodBalloon = new Balloon(2);
// this will throw a TypeError because the diameter must be a number
goodBalloon.diameter = "not a number";
// this will throw a TypeError as it results in an invalid value for the diameter
badBalloon = new Balloon("not a number");
// this will throw a TypeError because the diameter must be at least zero.
goodBalloon.diameter = -10;

This is effectively JSON schema applied to JavaScript objects with live constraints. Rather than just validating the state of the object at some point in time, properties are kept valid throughout the life of the object. Notice also that the property definition we created only constrains a single property; any other properties can be added or removed from the object freely. Schemas are additive in their constraints; an empty schema does not enforce any constraints on an object, and it can take any form.

However, JSI takes us beyond just constraining properties. We can also constrain the calls to methods. To do this, we can create method definitions in a similar way that we create property definitions in a schema.

A method definition has two important attributes: parameters and returns. The parameters attribute takes an array which defines the type for each parameter value to be passed to the method by position. The returns attribute takes a schema/type definition to constrain what values can be returned by the method. We could define types on the methods that the class implements (those defined on the prototype):

Balloon.methods = {
  setVolume:{
    parameters:[
      {
         type:"number",
         minimum: 0,
         description:"The new volume for the balloon."
       }
     ],
     description: "Set the volume (changes the diameter property)"
  },
  getVolume:{
    parameters:[],
    returns:{
       type:"number",
       minimum: 0,
       description:"The volume of the balloon."
     }  
  }
};

Now we can try out the method definitions:

// create a new balloon:
goodBalloon = new Balloon(2);
// will work properly
goodBalloon.setVolume(10);
// this will throw a TypeError
goodBalloon.setVolume("big");

We can also define class inheritance with our schemas, as well as utilize composition for property and method definitions. Suppose we had defined a subclass of Balloon called ColoredBalloon:

function ColoredBalloon(color){
  this.color = color;
}
ColoredBalloon.prototype = new Balloon(0);
ColoredBalloon = typed(ColoredBalloon);

We can define the inheritance structure in our schema when we define the schema for the subclass:

ColoredBalloon["extends"] = Balloon;

We can use composition for our property definitions. If we have another class called Color:

function Color(red, green, blue){
   ...
}

We could define a color property for our ColoredBalloon class that takes Color instances:

ColoredBalloon.properties = {
  color: Color
};

Now we can try our color property:

balloon = new ColoredBalloon(new Color(33,44,55));
// assign a color, this should work
balloon.color = new Color(255, 0, 0);
// this will fail, since the value is not an instance of Color (instanceof check is used)
balloon.color = "red";
// this will fail, since we inherit the property definitions from Balloon
balloon.diameter = "small";

We can also use existing classes in method definitions as well. For example, a method definition for a java-bean style setter for color would look like:

ColoredBalloon.methods = {
  setColor: {
    parameters:[Color]
  }
};

And all the method definitions are inherited from Balloon (as well as the method implementations through standard JavaScript prototype inheritance).

Using the Typing Module in Dojo

This typing capability is available in the dojox.lang.typed module, and can be used just like the standalone “typed” function. In addition, this module integrates with Dojo’s class constructing convenience function, dojo.declare.

One feature that makes the dojox.lang.typed module convenient is that we don’t need to reassign the return value of typed to the class variable; we can simply do:

dojo.require("dojox.lang.typed");
dojox.lang.typed(dojo.declare("acme.Balloon", null, {
  setVolume: function(volume){
  ... method implementations
}));
acme.Balloon.properties = {
  ... property definitions  
};

Furthermore, we can automate the typing of all our classes by setting the Dojo configuration variable dojo.config.typeCheckAllClasses to true before loading dojox.lang.typed. Then all classes that are declared (after dojox.lang.typed is loaded) through dojo.declare will be typed.

Development/Production Distinction

The typing module is intended to be used for development, easing the construction of classes that need to work together by verifying invariant assumptions. It is highly recommended that type checking be removed for production code. Type checking adds extra bytes (to download the schemas) and has a performance hit (to perform all the type checks), which should be avoided for production. Fortunately, the unobtrusive design makes this very doable. The actual class implementations are unaffected by typing definitions, and as long as the application runs without any type errors, the application should behave exactly the same without type definitions as it does with them. With this design, type definitions can be stored separately from implementations and easily omitted for production code.

In Dojo, ensuring that typing information is omitted can easily be done with the build process. There are a couple of ways of doing this. First we can utilize the build’s excludeStart() function to remove typing information. Therefore we could define our Balloon class:

//>>excludeStart("typed", true);
dojo.config.typeCheckAllClasses = true;
dojo.require("dojox.lang.typed");
//>>excludeEnd("typed");
 
dojo.declare("acme.Balloon", null, {
  setVolume: function(volume){
  ... method implementations
});
 
//>>excludeStart("typed", true);
acme.Balloon.properties = {
  ... property definitions  
};
//>>excludeEnd("typed");

The build process will then strip out all the schema information.

While using excludeStart() is a simple way to exclude type information, it can be a little ugly. Alternately, we could have our schemas stored in separate modules, and then use build profiles to omit the typing modules. This can contribute to better implementation/interface separation.

acme/Balloon.js:
 
dojo.provide("acme.Balloon");
dojo.require("acme.Balloon-schema");
 
dojo.declare("acme.Balloon", null, {
  setVolume: function(volume){
  ... method implementations
});

acme/Balloon-schema.js:
 
dojo.provide("acme.Balloon-schema");
dojo.config.typeCheckAllClasses = true;
dojo.require("dojox.lang.typed");
acme.Balloon.properties = {
  ... property definitions  
};

Now in the build profile, we can include the schema modules as layerDependencies to completely exclude them from the build:

dependencies = {
	layers: [
		{
			name: "../acme/Balloon.js",
			layerDependencies : [
				"../acme/Balloon-schema.js"
			],
			dependencies: [
				"acme.Balloon"
			]
		},
...

Limitations and Potential

Type checking on property changes can not be performed in IE because this feature relies on JavaScript getters and setters. However (as noted before), this is a development-time tool, and full cross-browser support is not necessary to reap the benefits of type checking. Checking for invalid type assumptions—and utilizing typing information for integration of components between different developers—can be achieved during development on a subset of all browsers. Type checked applications will still work on IE; there just won’t be type checks performed on property changes. For production, when full-cross browser support is needed, it is recommended that type checks be eliminated anyway.

The JavaScript-based type checker is also limited in that it can’t intercept delete operations on properties. When a delete takes place, the setter is not fired, and the type checker is not able to reject the action (in the case of required properties). The type checker also cannot control the addition of new properties that have been declared (in the property definitions or prototype).

JSI-based type checking does not have any mechanism for defining types of local variables. This is intentional. Local variables rarely benefit from type information. Integration of components from different sources can define their interaction solely through public interfaces (which are typeable with JSI), and local type inference mechanisms can usually provide sufficient information about local variable types for IDEs and code analysis.

A more complete JSI-based type checking system can be seen in Persevere. Persevere implements JSI for type checking in the server-side JavaScript environment, and is able to reject delete and new property actions that do not conform to the schema. Typing in JavaScript has been a controversial idea due to the obtrusive nature of traditional typing annotations, but JSI allows gradual type constraints to be applied in a way that does not interfere with JavaScript’s simple syntax and object model.

This typing scheme has also been proposed to the ECMAScript working group. As noted before, the typing system proposed for edition 4 required extensive new syntax and relied significantly on namespaces, which have been rejected. A schema-based typing system is perhaps the most reasonable alternative for adding typing capabilities to ECMAScript, and provides significant benefits over the more static type systems that quash the interactive, dynamic nature of JavaScript. With the more gradual approach that is being taken to evolve the language, this typing system provides the perfect mechanism for preserving the familiar syntax and meta-programming abilities that exemplify JavaScript.

Portability and Metadata Retrieval

JSON schema interfaces are completely language-agnostic. This means that interfaces can be defined that apply to implementations in different languages. This can be particular useful for defining contracts in RPC-style situations. In fact, the SMD format, which is used extensively by Dojo for defining remote services, is essentially a remote service-oriented form of JSI.

One of the challenges with traditional class systems is finding a way to reify type information. This is a non-issue with JSI, since the type system is based completely on a runtime data structure that is readily available and already understood.

Typing in JavaScript

While there has been a lot of controversy over typing, only the most extreme would not be willing to concede that in certain situations, typing can be a valuable asset for defining contracts between components. JSI allows for more robust evolution of an application, faster detection of invariant violations that lead to hard-to-find bugs, and better information for integration of components and type-based tooling. Furthermore, leveraging JSON schema gives developers a very rich set of options for constraining values, much more than most type systems.

JSI gives us a standardized data structure for defining types—allowing for more robust large-scale application development, a better pathway for JavaScript tool evolution, clean implementation/interface separation, and an integrated, intuitive class/typing system. And it’s available in both the Dojo Toolkit and Persevere today!

Categories: Companies using Dojo

about:mozilla – Firefox 3.5, add-ons contest, screencasts, hacks, multi-process, collections, art, security, and a whole lot more…

Mozilla Developer News - Tue, 06/23/2009 - 15:48

In this issue…

Firefox 3.5 Release Candidate!
Extend Firefox 3.5 contest
Help Firefox users transition to 3.5
More Firefox 3.5 hacks and demos
Multi-process Firefox, Phase I demo
SUMO 1.1 – screencasts are here!
Localizing the Getting Started page
Open video and the price of freedom
Mozilla Add-ons: a week of collections
Infectious Designs + Mozilla Firefox
Embedding the error console in Fennec
Shutting down XSS with Content Security Policy
Madrid Mozilla Technologies Course
Lifehacker’s Top 10 Firefox 3.5 features
Upcoming events
Developer calendar
About about:mozilla

Firefox 3.5 Release Candidate!

The Firefox 3.5 Release Candidate is now available for download and testing. We need feedback on several things in this milestone, including all 70+ localizations, new privacy tools, open audio and video, performance and stability improvements, geolocation features, native JSON support, web worker threads, downloadable fonts, CSS media queries, and a whole host of other changes and new features. Developers should read the Firefox 3.5 for Developers article, and everyone should read through the release notes before installing this release candidate.

Extend Firefox 3.5 contest

Extend Firefox is a worldwide developer contest that will be giving out prizes for the best new Firefox Add-ons developed for Firefox 3.5. Last year’s contest (for Firefox 3) received over 100 add-on submissions, and with Firefox 3.5 raising the bar in terms of features, we expect this year’s competition to be intense. Top prizes include MacBook Pro laptops, professional development tools, software and books. For all the details, head over to the Mozilla Add-ons blog and read the full contest announcement.

Help Firefox users transition to 3.5

The Firefox Support (SUMO) team is looking for help! When Firefox 3.5 launches they’re hoping to provide friendly, prompt and personal support to new Firefox 3.5 users through the knowledge base, forums, and live chat service. If you’re an experienced Firefox user, you can help the team by joining the dedicated SUMO community for the first week or two after the final Firefox 3.5 release and volunteering some of your time and expertise to help new users. If you would like to help, there’s more information about what you can do and how to get started over at the Firefox Support Blog.

More Firefox 3.5 hacks and demos

The Firefox Hacks team has continued to post feature articles and demos for some of the new Firefox 3.5 features at the Hacks weblog. Recent topics include: DOM traversal in Firefox 3.5, Using HTML5 video with fallbacks to other formats, Color correction for images in Firefox 3.5, an update on open video codecs and quality, and geolocation with open street maps. All of these demos and more can be found at hacks.mozilla.org.

Multi-process Firefox, Phase I demo

Benjamin Smedberg recently posted about the motivation for splitting Firefox into multiple processes, and now Chris Jones has posted a video (Ogg format, viewable with Firefox 3.5) that demonstrates what the team has accomplished so far. The demo is of the nearly-Phase I-complete browser, and represents a lot of hard work done by the team. See Chris’ blog post for more information.

SUMO 1.1 – screencasts are here!

Chris Ilias writes, “Last week, the fixes for SUMO 1.1 were applied to support.mozilla.com. The big news: SUMO now supports screencasts! Firefox 3.0.x users will be able to view screencasts in Flash format, but we also support the open video format called Ogg/Theora. Firefox 3.5 users will be able to view Ogg/Theora videos without the need for a plugin. What makes screencasts on SUMO especially great is that the SUMO knowledge base is a wiki. Adding a screencast to an article can be done by anyone!” The SUMO team has put together a tutorial about how to add screencasts, including a list of software you can use to create them. Other details are available on Chris’ post.

Localizing the Getting Started page

Seth Bindernagel has written an interesting article in which he talks about the power of localized Getting Started pages, and why he believes they are a critical step in helping users optimize their experience on the Web. The example he uses is the Danish version of the Getting Started page, where the team experimented with featuring the Danish dictionary add-on. “The experiment resulted in a bit of a surprise. The link became the most popular click-through on the page!” Read the rest of Seth’s article on his weblog.

Open video and the price of freedom

Robert O’Callahan writes, “With the imminent release of Firefox 3.5 and the big step forward for unencumbered video and audio that this represents, there’s been a lot of discussion about the merits of the free Ogg codecs vs the flagship encumbered codecs. The real question that matters is this: at comparable bit rates, in real-world situations, do normal people perceive a significant quality advantage for H.264 over Theora? Because if they don’t, theoretical technical advantages are worthless.” Some tests have been run and, “in these tests, it seems pretty clear that there is no real advantage for H.264, or even that Theora is doing better.” Robert’s full post is available on his weblog.

Mozilla Add-ons: a week of collections

The Add-ons team launched the new collections feature on addons.mozilla.org (AMO) over a week ago, and the response has been amazing. Justin Scott writes, “Above the Fold has details on press coverage, and we’re happy to see so many bloggers and news sites creating their own collections. Reading the articles, it was very exciting to see that people really understood collections and their potential.” During the first week, add-on users created more than 11,000 collections, comprising 140,000 instances of 3500 different add-ons. Over 245,000 add-on downloads were served from collection view pages, not including downloads served from other pages accessed through collections. In addition, the Add-on Collector has been downloaded 46,000 times.

Infectious Designs + Mozilla Firefox

Jay Patel has been heading up a new Community Art Project to inspire creative contributors to join us in making the internet better for everyone. “Today we unveil some amazing designs by 5 Infectious artists that we asked to help kick off the project. We challenged them to create art inspired by Firefox and the values that drive the Mozilla project. The result? Original art pieces that reflect the innovation, openness, opportunity and idealism that Mozilla represents.” The designs are available as iPhone skins, car decals, desktop wallpaper, and iPhone wallpaper through Infectious.com, as T-shirts at the Mozilla Community Store, and as Personas for your Firefox browser. To read more about this collection and the Community Art Project, read Jay’s post.

Embedding the error console in Fennec

One thing many developers don’t realize is that any Mozilla-based application automatically supports displaying and using the JavaScript Error Console, you simply need to launch the application using the -jsconsole command line flag. Making this work on a mobile device, however, is a bit trickier. Mark Finkle writes, “Trying to debug problems in Fennec while running on a mobile device can be a pain. To make it easier to view errors, we added the Error Console as a browser panel in Fennec. It’s hidden by default — you need to use about:config to display it.” Read the rest of Mark’s post (which includes screenshots of the Fennec Error Console) at his weblog.

Shutting down XSS with Content Security Policy

For several years, Cross-Site Scripting (XSS) attacks have plagued many of the web’s most popular sites and victimized their users. At Mozilla, a team has been working on a new technology called Content Security Policy (CSP), designed to shut these attacks down. Brandon Sterne has written an article that gives some of the background of the project and provides an update of the progress so far.

Madrid Mozilla Technologies Course

The Madrid Mozilla Technologies Course is a three-month blended learning course organized by the Mozilla Foundation, Mozilla Europe and the Universidad Rey Juan Carlos (Madrid Spain). The course starts July 1st 2009 and will finish October 15th. Most of the course is on-line and can be followed by students using the web, mailing lists, wikis, IRC, etc. Students who follow the course with success will obtain a degree from the Universidad Rey Juan Carlos and a diploma from the Mozilla Foundation/Mozilla Europe. For more information, see the course website. Note that registration closes on June 30th.

Lifehacker’s Top 10 Firefox 3.5 features

With the release of Firefox 3.5 right around the corner, Lifehacker has put together its list of “Top 10 Firefox 3.5 Features“. These include: open video, the geolocation API, TraceMonkey JavaScript engine, Color profile support, Private browsing mode, Smarter session restore, Keyword AwesomeBar filters, tear-off tabs, Forget this site, and Undo closed window. If you’re champing at the bit to get a look at these, you can download the newly released Firefox 3.5 Release Candidate now (and help test!)

Upcoming events

The Mozilla community is organizing an increasing number of events and meetups all the time, and we include a list of these here every week. If you have events you would like listed, send them along to: about-mozilla*at*mozilla.com.

* Wed, Jun 24 – Mountain View, CA – Testing Mozilla web properties
* Thu, Jun 25 – Online – Support Firefox Day
* Thu, Jun 25 – Mountain View, CA – Mozilla Labs Meetup
* Fri, Jun 26 – Online – Fennec web compatibility testing
* Sun, Jun 28 – Fastest Firefox videos deadline!
* Fri, Jul 10 – Online – Firefox 3.5 Security Testday
* Sept 14-21 – Everywhere! – Mozilla Service Week

Developer calendar

For an up-to-date list of the coming week’s Mozilla project meetings and events, please see the Mozilla Community Calendar wiki page. Notes from previous meetings are linked to through the Calendar as well.

About about:mozilla

about:mozilla is by, for and about the Mozilla community, focusing on major news items related to all aspects of the Mozilla Project. The newsletter is written by Deb Richardson and is published every Tuesday morning. If you have any news or announcements you would like to have included in our next issue, please send them to: about-mozilla[at]mozilla.com.

If you would like to get this newsletter by email, just head on over to the about:mozilla newsletter subscription form. Fresh news, every Tuesday, right to your inbox.

Categories: Web Developement

Thunderbird 2.0.0.22 security and stability release now available

Mozilla Developer News - Mon, 06/22/2009 - 22:13

As part of Mozilla Corporation’s ongoing stability and security update process, Thunderbird 2.0.0.22 is now available for Windows, Mac, and Linux as a free download from www.getthunderbird.com.

Due to the security fixes, we strongly recommend that all Thunderbird users upgrade to this latest release.

If you already have Thunderbird 2.0.0.x, you will receive an automated update notification within 24 to 48 hours. This update can also be applied manually by selecting “Check for Updates…” from the Help menu.

For a list of changes and more information, please review the Thunderbird 2.0.0.22 Release Notes.

Please note: If you’re still using Thunderbird 1.5.0.x, this version is no longer supported and contains known security vulnerabilities. Please upgrade to Thunderbird 2 by downloading Thunderbird 2.0.0.22 from www.getthunderbird.com.

Categories: Web Developement

Mobile2.0 wrap up

Uxebu - Mon, 06/22/2009 - 13:43

At first we have to thank the organizers, it was a great event. Especially the developer day (~100 people) was so loaded with energy, ideas and enthusiasm - wow that was huge! It took place in Barcelona Activa a business incubator, obviously well known throughout Barcelona, the Taxi driver knew right away where to go. The offices in there looked like you wanted to work there, the style of the house was so interesting that I even walked the entire floor once, because everything was so open and felt constructive. If you want to move your business to Barcelona try it out. And this was of course the perfect place for the mobile developer day, a young and constantly exploring group of people, pushing the limits and full of energy to move the mobile web forward. The parties afterwards had been as inspiring and great for getting to know people as they had been fun.

The conference day was just as interesting and though it was also a pretty cosy atmosphere (I would say about 250 people) one felt the difference to the day before, it was more on the business level but always mixed with the understanding for the young mobile industry it’s technical hurdles and the rough edges it still has, it was perfect too. Having tapas under the spanish sun was just as perfect as the content and the people there. The range of topics, no matter if in a panel or solo had been amazing and I am sure that everyone heard something interesting. For all the slides, and hopefully some videos watch the mobile2.0 site, pics are as usual on flickr.

The next mobile2.0 will probably be in San Francisco around October. See you there …

Categories: Companies using Dojo

Developer Sprint This Weekend - Free T-Shirts For All Participants!

LucidDesktop - Mon, 06/22/2009 - 10:00

Since we've been dormant for the past few months, we've decided to hold a Developer Sprint this weekend, June 26-28. We'll be fixing up bugs for 1.0. By Monday, we'll have 1.0-RC2 ready to be released. We're inviting all community members to help us out by fixing bugs, and making sure everything is working flawlessly.

We will be giving out free Dojo t-shirts to anyone who provides an acceptable fix for any outstanding 1.0 bug or ticket. Below, you can see some people wearing the shirt at a local Dojo meetup. Just make sure you've filled out a CLA before friday, otherwise we can't accept your contribution. There aren't any skill or experience requirements, if you know PHP or Javascript/Dojo, then you can help us out.

We'll be setting up camp on the IRC channel, and in the forums. The information for the IRC channel can be found on the Community page. If you have any questions, or need help tackling a bug, just ask in either of those places and someone will help you out.

By Monday, we want to have RC2 finished. That way, we can release 1.0 a week later, provided we don't get any huge bug reports.

We'll be looking forward to meeting you all this weekend. I hope we have a good time, and get lots of work done!

Categories: Companies using Dojo

Twitter Weekly Updates for 2009-06-21

weba11y: Becky Gibson - Sun, 06/21/2009 - 10:00

can u believe that pressing shift+enter works differently in IE 8 if my Local intranet options are set to auto detect local intranet ntwrk? # just finished presenting to 7th graders at local school - trying to interest them in engineering. Had them build bridges out of paper. Fun! # some days fighting to maintain keyboard [...]

Categories: Dojo Developers

Firefox 3.5 release candidate now available for download

Mozilla Developer News - Sat, 06/20/2009 - 00:19

The Firefox 3.5 Release Candidate is now available for download. This milestone is focused on providing a preview of the functionality provided by the new features and changes that will be included in Firefox 3.5. A video highlighting some of these new features is also available. Ongoing planning for Firefox 3.5 can be followed at the Firefox 3.5 Planning Center, as well as in mozilla.dev.planning and on irc.mozilla.org in #shiretoko.

New features and changes in Firefox 3.5 include:

This beta is now available in more than 70 languages – get your local version.
Improved tools for controlling your private data, including a Private Browsing Mode.
Support for the HTML5 <video> and <audio> elements including native support for Ogg Theora encoded video and Vorbis encoded audio.
Better performance and stability with the new TraceMonkey JavaScript engine.
The ability to provide Location Aware Browsing using web standards for geolocation.
Support for native JSON, and web worker threads.
Improvements to the Gecko layout engine, including speculative parsing for faster content rendering.
Support for new web technologies such as: downloadable fonts, CSS media queries, new transformations and properties, JavaScript query selectors, HTML5 local storage and offline application storage, <canvas> text, ICC profiles, and SVG transforms.

Categories: Web Developement

How we used user research data to help design Compatibility View

IEBlog - Fri, 06/19/2009 - 21:00

There have already been a few posts on Compatibility View in Internet Explorer 8 (here, here, here, here, here, and here), but none have gone into detail about the user research data we used to help design this feature. We collected data on Compatibility View throughout the IE8 beta releases and have made multiple decisions about its design based on our data from lab studies, field studies, instrumentation, and community feedback. What I’d like to do is go through some common questions we’ve received about the user experience of Compatibility View, and explain how user data has influenced our decisions. Hopefully, this will give you some insight into our design process and how we use data to make feature design decisions.

Current design

So that we’re on the same page, let’s do a quick review. The current design places the Compatibility View button at the end of the Address Bar, next to the Refresh button in the default layout, on sites that do not include the compatibility meta tag or HTTP header. The button has a “page” icon on it. The first two times a user is on a page with the button visible and refreshes the page, a notification balloon will pop pointing to Compatibility View.

Now that we’ve reviewed the design, let’s look at some of our top questions.

Why put the icon next to the Refresh button?

One of our top concerns with Compatibility View has always been its discoverability. If users can’t find this feature, they could have a severely compromised experience. When we first tested Compatibility View in our user research labs, it was a button on the Command Bar named “Emulate IE7.”

To test it, we created a task in which participants were asked to use a site that we knew would be unusable before switching to Compatibility View. When they arrived at the site and found it unusable, we asked them, “What would you do if you came to a site that looked like this?” The most common response by far was to click the Refresh button. After probing deeper into why people would try to “fix” a page in this way, most responses focused on a specific incident in the past where the participant had seen a page that was “off” somehow and refreshing the page had fixed the issue. Another common response was to look for something in the Tools menu.

Side note: We use the term “fix” a page in this article a lot because that is how our participants referred to what they were doing. We know the technical accurateness of this term is debatable in a lot of cases but we’re sticking with how our participants thought about the scenarios.

Almost no one thought to use the “Emulate IE7” button, even though they had seen an explanation of it earlier in the session. The main problem was that the word “Emulate” had little to nothing to do with “fixing” sites to our participants. It was a technical description of the feature instead of describing what the user was looking for in these situations. Also, we knew that the problem wasn’t that it didn’t stand out enough. I mean, it was a BIG button that was totally new in the Command Bar. Our problem wasn’t that it didn’t catch user’s eyes, it was that it didn’t fit into user’s mental models.

Based on this data, we knew that the majority of users will likely look to the Refresh button when they encounter a page that needs to be “fixed.” To take advantage of this natural tendency, we place the Compatibility View button next to the Refresh button – next to the most likely place a user will look when a page looks “off.” Additionally, to catch the small percentage of users who we expected to look in the Tools menu, we added a link there as well.

Why use that icon?

We knew that having a button with a name as long as “Emulate IE7” was not going to work being placed next to the Refresh button. It would take up too much space and we already knew that the idea of emulating IE7 in IE8 was strange for most users. We brainstormed and developed a series of potential icons that could work for Compatibility View. One challenge we faced was that communicating what Compatibility View does with only an icon is quite difficult. We tried various iterations such as showing blocks misaligned, representing areas of the page that could be out of alignment. These versions were too abstract to communicate the general idea and often it’s not a case of elements being misaligned (e.g., menus might have the wrong background color). We decided on the “page” icon because this correlated best with how participants were describing the pages that were not rendering correctly (e.g., “broken”, “screwed up”).

In refining the final design, we worked to make it fit as part of our family of icons in the address bar, including stop, refresh and go. We tried options that had different colors and textures for the page but found the page white design was most recognizable as a “web page”. We used the same colors, line weights and gradients present in the other icons to “ground” the icon to the overall address bar design.

When we tested the icon in the lab, we found that the majority of participants understood that the icon had something to do with the page with a problem they were looking at. Seeing the icon led most people to read the tooltip that explains the feature. After reading the tooltip, we saw many positive reactions to the icon and that it made sense given what the feature does.

Some reviewers felt that showing this icon on pages that were potentially fine would confuse users and make them think that the page was broken somehow, but we saw no indication of that in our studies. Participants did not even look toward the Compatibility View button unless they were in situations where it could potentially help them, which was one of our design goals.

Will people understand what it’s for?

We expect most users to understand Compatibility View and when to use it. Of our lab participants who read the Compatibility View tooltip, the notification balloon, or tried the feature, all have understood the feature’s purpose. Most importantly, everyone who understood the the feature, continued to use it on the sites they encountered that had issues. This was true for our lab participants and also for our field research participants.

Why have balloon notifications?

After a few rounds of testing in the lab, and getting feedback from participants in our field research, we still saw some participants didn’t notice the Compatibility View button, even after they hit Refresh on a page with layout issues. Quite naturally, they got into an automatic pattern of quickly clicking Refresh and then putting their eyes right back to the page content to see if it fixed their problem. We had an important decision to make--do we add some kind of notification that lets the user know about Compatibility View when it could help them? The upside is that more people who would benefit from Compatibility View will find it. The downside is that we are adding another notification to the system.

We tested a build with the notification balloons in the lab and in our field research and found that displaying a balloon did in fact help more people discover Compatibility View. We didn’t take the decision lightly but felt the added awareness was worth the added notification.

Why have two balloon notifications?

Originally the balloon notification only showed once when a user refreshed a page displaying the Compatibility View icon for the first time. As I mentioned above, even showing this once was a strongly-debated decision. But, there were many concerns that once was not enough so we tested the possibility of showing the notification up to three times (after the first three times someone refreshed a page displaying the Compatibility View icon).

In the lab, we showed participants from one to three different sites with layout or content problems. At each site we asked them what they would do if they came to a site like this. Most clicked Refresh as we expected. What we found was that of people who saw the notifications, about two thirds reacted to the first notification and the other third reacted to the second notification. Showing the second notification caught the attention of a group of people who were very focused on the content of the page at the first site but were more likely to notice things outside of their normal pattern at the second site.

There was also a group who saw all three notifications and dismissed or ignored them all. We believe these users would not pay attention to the notification no matter how many times we showed it. This lead us to not show the notification three times “to be safe” because we had no evidence that showing the notification more than two times will catch any additional users and there is a real cost to over communicating with users (e.g., data in the recent e7 blog post about Action Center).

Conclusion

I hope this gives you some insight into how we as an engineering team use user research data to make some of our design decisions. As you can see, a lot of time, research, and deliberation can go into a feature (and this was just a summary, I didn’t even get into our instrumentation data). We always want to base important decisions on the best data possible and that includes data from the lab, field, instrumentation, and community feedback. If you’d like to find out more about user research at Microsoft, please check out our user research website.

Jess Holbrook
User Experience Researcher

Ben Truelove
User Experience Designer

Categories: Web Developement

Dojo Tips and Tricks

Dojo: The Definitive Guide - Fri, 06/19/2009 - 15:00

Many months ago, I wrote an article for InsideRIA that provided a topical look at some of the more useful things that Dojo provides you entitled Dojo Tips and Tricks. I’d actually forgotten that I even wrote the article so it was a surprise when a colleague wrote me earlier this morning and mentioned it.

It’s a bit more diverse than some drive-by-tutorials in that it digs into DojoX just a little bit and mentions the build system, so even if you’ve been using some of the core tools for a while now, you may still learn a few things from a quick read.

In between the time when the article was finished and now, Dojo has since updated to version 1.3 so you’ll unfortunately see a few CDN URLs that point to version 1.2; however, upgrading the URLs shouldn’t break anything. The latest and greatest is usually a great place to start, so I always encourage folks to stay up to date.

If you’re coming to OSCON this summer, be sure to drop by my 3 hour tutorial for a closer look at many of the great tools that Dojo provides.

Categories: Companies using Dojo, Dojo Developers

Compatibility View and "Smart Defaults"

IEBlog - Thu, 06/18/2009 - 01:39

I’ve mentioned in several previous posts how Internet Explorer 8 displays pages in its most standards compliant mode by default – a configuration that emphasizes interoperability. This creates some challenges with regards to compatibility with existing web content.

Some of today’s web pages expect the older, less interoperable behavior from IE and, as a result, don’t necessarily work as expected in IE8’s standards-by-default mode. To address this, we built features like Compatibility View and the ‘EmulateIE7’ X-UA-Compatible tag – features that users and web developers can enable to make the browser more compatible with existing content. This post is about some situations where IE uses smart defaults to provide users with a more compatible out-of-box experience.

Many sites found on corporate intranets (read: the local network, like http://myPortalSite) are Internet Explorer 7 capable today and expect “IE” to act like IE7. In order to preserve compatibility with these line-of-business websites and applications, IE8 defaults to Compatibility View when displaying content in the ‘local intranet’ zone. An exception to this is ‘Localhost’ and the loopback address (e.g. 127.0.0.1 + IPv6 equivalent). These addresses display in IE8 Standards Mode by default in order to meet the needs of web developers and designers who often test pages meant for Internet consumption (where IE8 Standards is the default) on local web servers.

Users can override the ‘local intranet’ setting by un-checking ‘Display intranet sites in Compatibility View’ at Tools -> Compatibility View Settings.

IT Admins can configure this setting via Group Policy. IT Admins can also configure and maintain a list of sites, both intranet and extranet, that are best viewed in Compatibility View. Using that policy in conjunction with the ‘local intranet’ policy configured to “off”, e.g. IE8 Standards on the intranet, enables organizations to gradually transition infrastructure pieces from IE7 Standards to IE8 Standards.

Another place where IE uses smart defaults is WebOC layout modes. There are many Windows applications both past and present that use the WebBrowser control, aka Trident. CorelDraw Graphics Suite, Encarta, Microsoft Office, and Nero are just a few examples. As you might expect, updating software that the user has installed on their machine is complex (e.g. developer has to write an updating system, user has to opt-in, user has to get and install the update, etc…). This can be particularly hard for “boxed” software, which often times is even more costly to update than a “live” web application due to the software distribution method - CDs / DVDs on store shelves vs web download. Like web applications, these Windows applications may assume a particular behavior set from Internet Explorer. In order to maintain compatibility, applications using the IE8 WebOC display pages in Compatibility View by default. Applications can enable IE8 Standards Mode by setting the following registry value:

[(HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE)\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
"MyApplication.exe" = dword 8000 (Hex: 0x1F40)

Finally, there are cases around “hard asserts” that cause IE to switch into Compatibility View. For those not familiar with the concept, Wikipedia does a good job covering the basics -

An assertion may be used to verify that an assumption made by the programmer during the implementation of the program remains valid when the program is executed.

…

A major advantage of this technique is that when an error does occur it is detected immediately and directly, rather than later through its often obscure side-effects. Since an assertion failure usually reports the code location, one can often pin-point the error without further debugging.

When we built the brand-new layout engine included in IE8, we used a standard practice of instrumenting common code paths with assertion logic. This instrumentation was invaluable during IE8 development as it served to highlight areas of faulty logic or invalid assumptions made during the implementation of the new layout engine. As an example, the original implementation of some sizing algorithms assumed ‘consumed height’, an internal construct tracking the actual height taken up by an object, could not be negative. This assumption turned out to be false as one can reach the condition through certain top margin values. An assertion that bounded consumed height’s acceptable values allowed us to identify and correct the error.

For the most part, we’ve removed assertions from our retail code. That said, there are particular code paths within the new layout engine where, should an error occur, the layout process can’t gracefully recover and we’ve kept assertions around these paths. In the IE8 Beta builds, encountering one of these layout “hard asserts” caused IE to display a blank page - the thought process being that it was better to show the user nothing at all than allow interaction with a corrupt or otherwise obviously incorrectly displayed page. We refined this experience further in the released version of IE8 by recovering layout “hard asserts” using Compatibility View. In other words, we believe that showing a page the way IE7 would have offers a better user experience than showing no content at all.

A new InetCPL setting at Tools -> Internet Options -> Advanced -> Browsing enables / disables auto-recovery.

On error, the entire domain recovers into Compatibility View, not just the page or sub-section of the site. This mirrors the current experience when users press the Compatibility View button and prevents a case where the user has repetitious “blank pages” while browsing a site (imagine a case where an ad banner present on all of a site’s pages triggers the assertion). A new balloon tip message indicates that the page has been switched to Compatibility View and why.

Compatibility View triggered by automatic recovery persists only for the life of the IE session - a behavior that mirrors the current experience when toggling Compatibility View while in InPrivate mode but contrasts with toggling Compatibility View in a normal browsing session (where Compatibility View information for a domain persists across browser restarts). In other words, each subsequent visit to the site (in a new session) will result in a return to IE8 Standards behavior.

When a domain has been auto-recovered, the Compatibility View button shows as pressed (as opposed to hidden or not pressed). Pressing the Compatibility View button on a recovered domain forces a page reload into IE8 mode. The catch here is that toggling in and out of Compatibility View on content that triggers an assertion can cause a recovery loop: site content triggers auto-recovery to Compatibility View, user presses Compatibility View button which takes the page back to IE8 Standards Mode, site content when put through the IE8 layout engine again triggers auto-recovery to Compatibility View…

Auto-recovered domains are shown in the user’s Compatibility View list (Tools -> Compatibility View Settings) in parenthesis.

The parenthesis denotes non-permanence. These “temporary” domains can be removed, though doing an ‘add’ operation for an auto-recovered domain in the list replaces the auto-recovered domain with a “persistent” entry (e.g. one without parenthesis).

The presence of an IE8 X-UA-Compatible tag / HTTP header (e.g. ‘IE=8’ or ‘IE=EmulateIE8’ + a Standards DOCTYPE) forces a page to stay in IE8 mode regardless of the auto-recovery setting value on the client (users will see a blank page in the event of a layout ‘hard assert’). Developers can debug blank page issues by forcing the page into an IE8 document mode via the Developer Toolbar, which will also prevent auto-recovery.

We worked hard to fix known causes of unrecoverable errors in our layout engine before we shipped. For issues that do crop up “in the wild”, IE generates error reporting via Windows Error Reporting (WER). That way, we can get a call stack of the failure and, ultimately, repro, triage, and fix assertions just as we do reported crashes and hangs.

Recap

IE8’s standards-by-default configuration supports developers and designers as they create the next wave of web pages, applications, and experiences. At the same time, we recognize the near term consequence of this decision, namely challenges around compatibility with existing content designed to work with older versions of IE. The behaviors described here enable both interoperability and compatibility, benefitting both developers and end-users.

We’re interested to hear your compatibility feedback. Please drop us a line in the comments section to let us know your experience with IE8 and the content and apps you visit / use.

Scott Dickens
Program Manager

Categories: Web Developement

Firefox 3.5 beta users will receive update to early release candidate

Mozilla Developer News - Wed, 06/17/2009 - 08:11

Please note: beta and release candidate versions of Firefox 3.5 are intended for developer testing and community feedback. If this makes you nervous, we recommend that you wait for the official Firefox 3.5 release, which is coming soon and will be available at www.getfirefox.com

Our 800,000+ Firefox 3.5 beta users will be receiving an update to the first Firefox 3.5 release candidate (3.5rc1build2) in order to continue to help us with daily testing and public feedback. This update contains bug fixes which will be included in the final release of Firefox 3.5, expected later this month. While Mozilla has not yet completed the quality assurance testing required before an official product release, this update is considered stable for daily browsing use and we appreciate your assistance in helping us test and evaluate this version of the release candidate.

If you’re running a beta or preview version of Firefox 3.5, you should be receiving the update automatically within the next 24 hours. To get the update immediately, select “Check for Updates…” in the “Help” menu.

This version is not yet being made available for direct download. If you’re not yet a Firefox 3.5 Beta tester, we recommend that you wait for the upcoming Firefox 3.5 Release Candidate, which should be released on our website within the next week. If you’d like to become a beta tester for Firefox 3.5 and subsequent releases, please feel free to install the latest available beta and then manually “Check for Updates…” in the “Help” menu.

(Developers should also read the Firefox 3.5 for Developers article on the Mozilla Developer Center.)

Note: We strongly encourage bloggers and media to link to this Firefox 3.5 Beta User update announcement so that everyone will know what this update is, what they should expect, and who should be downloading to participate in testing at this stage of development.

Categories: Web Developement

Search

Planet Dojo