March 27th, 2007
Firefox 3.0a3 has just been released, including a number of changes and new features. A list of some of the major new features can be found on the Mozilla site.
However, there are a number of changes and additions that are particularly relevant to JavaScript developers, in particular, that I would like to take the opportunity to highlight.
(This reminds me, if you don't yet subscribe to The Burning Edge, I highly recommend it; it does weekly recaps of the changes that have gone into Firefox, highlighting important features or bug fixes.)
These two properties have long been a part of Internet Explorer and are now making their way into Firefox. This is to complement the clientHeight and clientWidth properties that already exist.
What these properties provide can be best described through a diagram; luckily, the Mozilla Developers Wiki already has some nice ones, so I'm just going to repost them here:
clientLeft
clientTop
While they're not terribly exciting properties to have, it's good to finally have a full set to work with.
This one might seem rather innocuous, at first, but is a huge win in the Cross-Site Scripting (XSS) war. More often, than not, the true reward for performing some form of XSS is snagging valuable session information from a user's cookies. This relies on the fact that client-side JavaScript is able to access all of the cookies set and sent by the server. However, this is no longer the case. An HttpOnly flag, proposed and implemented by Microsoft in Internet Explorer 6, is now available in Firefox 3.0. A server, when setting a new cookie, can include the HttpOnly flag and know that the JavaScript won't have access to it. Of course, this isn't completely effective until all browsers have this property implemented, but it's certainly a step in the right direction.
Example:
Set-Cookie: sessionid=1234567; domain=mozilla.org; HttpOnly
This is an interesting feature that doesn't, yet, have a specification-home (although, some suspect that it'll be adopted by the WHATWG). It provides the ability, for the user, to specify individual resources for special caching, should the browser move into offline mode.
In my personal tests, I was able to get it such that an XML file, specified exclusively as an "Offline Resource", was able to be retrieved, using an XMLHttpRequest, even while being disconnected from the Internet. You can view a demo here (Make sure that you're running, at least Firefox 3.0a3.) The relevant code, from the test page, is as follows:
...
<head>
<link rel="offline-resource" href="test.xml"/>
<title>Offline Resource Test
</title>
<script>
window.onload = function(){
var button = document.getElementById("button");
button.onclick = function(){
var xhr = new XMLHttpRequest();
xhr.open( "GET", "test.xml", true );
xhr.onreadystatechange = function(){
if ( xhr.readyState == 4 ) {
alert( xhr.responseXML
.documentElement.firstChild.textContent );
}
};
xhr.send( null );
};
};
</script>
</head>
...
The important line being:
<link rel="offline-resource" href="test.xml"/>
which allows you to make the browser pre-cache the test.xml file, for later use. This can be done with a number of resource files (CSS, Images, etc.) and is not just limited to pieces of data; which makes it immensely useful. Mark Finkle has some more details
on his blog.
This feature has trickled down to us from the upcoming ECMAScript 4 (JavaScript 2) specification. More information about /y can be found there. In a nutshell: It allows you to start a regular expression leaving off where the last match, of the last expression, ended. In Perl, this is similar to placing a \G at the beginning of your regular expression.
JavaScript: Remove the first instance of 'dog' after the first instance of 'cat'.
var str = "mouse dog mouse cat dog";
str.match(/cat/);
str = str.replace(/ dog/y, "");
>> str == "mouse dog mouse cat"
Perl:
my $str =
"mouse dog mouse cat dog";
$str =~ /cat/;
$str =~
s/\G dog//;
>> str eq
"mouse dog mouse cat"
A minor, but useful and important, feature addition to the built-in Firefox DOM Inspector. This new feature is perfect for performing additional testing on live pages, to see their effect. A quick demonstration of how it works:
There's a new menu option allowing you to insert a node in relation to the selected node:
Once selected, you can then insert an element (with namespace) or a text node:
Giving you a nice new result:
How to try all of this at home!
Mozilla provides full builds of the latest bleeding-edge installs. You can find them linked to the individual Burning Edge blog posts, or at the following URL:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Tags: webdev, development, javascript, programming, web
12 Comments on 'JavaScript Updates in Firefox 3.0a3'
January 22nd, 2007
This past week I attended Mashup Camp here in Boston - and was frequently asked what tools I used in development. I was quick to mention Firebug (I mean, I was giving a presentation on it, after all) - but I then thought about the other tools that I use in development and decided to expand on my list.
Firebug - I know that this has been said a thousand times, but let this be number 1001 - Firebug is a fantastic web development tool. In addition to all the features that everyone knows about, I've been using it extensively for a number of tasks:
- Optimizing the speed of large JavaScript codebases using the profile tool.
- Finding the source of slow page loads using the Net tool.
- Hunting down weird CSS results by looking at the resulting styles in the CSS tab.
- Giving presentations on JavaScript/jQuery.
I plan on writing about each of those much more. The end result is a Firefox extension that's worth its virtual weight in gold.
Packer - The ultimate JavaScript compression tool. The next best thing to using GZip compression. I use this extensively in jQuery, so I know most of its ins-and-outs. Depending on the file, I frequently get files compressed down to 25-30% of their original size.
Rhino - I love Rhino. It's essentially a collection of Java code that compiles JavaScript into Java. We use this all over the place to build jQuery. It's great because we can take JavaScript code, like Packer, and run it on any server that has Java - all in the background, and all without ever opening a browser. Additionally, we get the benefit of only ever having to code in one programming language for the entire project.
Selenium IDE - This is the newest weapon in my arsenal. It's a Firefox Extension version of the popular Selenium test suite. It is glorious. You hit the record button, click around your web site, hit stop - then play back the results. Save the script and use it again later to do some automated testing. I've used this on a couple sites now - it's great for testing dynamic web applications. (Just add in some sort of a "reset the database" callback to your code, and you can run all the tests on your server, remotely.)
I plan on writing and demoing all of these tools some more within the upcoming weeks - they're immensely useful, and I couldn't live without them.
Tags: mashupcamp, web, development, tools, programming, javascript
7 Comments on 'JavaScript Development Tools'
January 9th, 2007
If you're ever spent time trying to grok Firefox Extension development (especially if you're coming from a pure web development background). You'll find that there's a lot that you have to learn to get up to speed. To name a few: XPCOM, RDF, XUL, and XBL in addition to a huge number of custom APIs for the different aspects of Firefox (Bookmarks, File I/O, Adding Buttons, Menus).
My first major project at Mozilla is to work with Mark Finkle and develop a JavaScript Library for use by Extension developers. If you're very new to extension development, then this will help you out, completely. We extrapolate out all the complex concepts into one, simple, package. The best part is that this whole thing is going to be available in the whole Mozilla platform (Firefox, Thunderbird, Seamonkey, XULRunner); and in multiple versions (for example FF 1.5-3.0).
We use very little of the actual underlying terminology and naming conventions present in the existing code base (this is bound to irk most established developers), and instead have adopted much of the terminology already present in JavaScript/DOM development. You can see evidence of this in our early API planning for versions 0.1 (Plan) and 0.2 (Plan).
In a nutshell, for 0.1, here's what we're tackling: Preferences, Events, Observers, Extensions, Toolbars, and Buttons; and the kind of improvement that you can expect:
Accessing a Boolean Preference
// 'Old' XPCOM way
var prefValue =
false;
try {
prefValue = gPrefService.
getBoolPref(this.
domain);
} catch (e
) {
}
// 'New' FUEL way
var prefValue = Preferences.get(this.domain, false);
Watching for a change in a preference (obvserver).
// "Old" XPCOM way
gPrefService
.
QueryInterface(Components.
interfaces.
nsIPrefBranch2)
.
addObserver(this.
promptDomain,
this,
false);
// "New" FUEL way
Preferences.addEvent( this.promptDomain, this );
Setting a unicode preference.
// "Old" XPCOM way
try {
var str = Components.
classes["@mozilla.org/supports-string;1"]
.
createInstance(Components.
interfaces.
nsISupportsString);
str.
data = aURL;
gPrefService.setComplexValue("browser.startup.homepage",
Components.interfaces.nsISupportsString, str);
} catch (ex) {
dump("Failed to set the home page.\n"+ex+"\n");
}
// "New" FUEL way
Preferences.set("browser.startup.homepage", aURL);
We're really excited about where this is going, and we'd love some feedback. Feel free to comment on the wiki, find us on irc, or drop us an email. Here's Mark's take on the project. I'm really excited to be working with him and the whole developer relations team.
Tags: mozilla, firefox, javascript, programming, development, library
7 Comments on 'FUELing the Firefox'
