Blog
July 17th, 2008
I've got a mini-announcement. Starting this week about half of my time at Mozilla is going to be spent driving the direction of the brand-new Mozilla Firebug team. I'm, understandably, quite excited about this proposition. Like all web developers I've found Firebug to be an invaluable tool for web development.
We have a great team forming - I'm going to be joined by:
We're in a very primordial stage right now - we're meeting at the Firefox Summit at the end of the month and again at the beginning of August for the Firebug Working Group. We'll be setting some major goals for post-Firebug 1.2 development. I highly suspect that we'll be doing some exploratory Firebug extension development as well.
In the meantime we'll be hanging out in the Firebug IRC channel, which can be found here:
Server: irc.mozilla.org
Room: #firebug
We're going to love to hear any suggestions for feature development - I'm sure you've got tons of ideas - and we do as well. I'm quite excited about all of this. Here's to a bright Firebug future!
Tags: firebug, firefox, mozilla
72 Comments on 'Firebuggin''
July 10th, 2008
This week I've been busy working on implementing a test suite for the Selectors API specification. I picked up a new microphone recently so I decided to do a quick walkthrough of the work that I've been doing and how I've been going about it. You can view the the video below:
Implementing a Selectors API Test Suite
You can run the test suite for yourself here (it's still very much in flux - there are various parts that may still be wrong):
http://ejohn.org/apps/selectortest/
Here's a quick break down of a test run that was done earlier:
- Special Firefox 3.1 Build (73.8% - More details)
- Safari 3.1 (49.3% - No Fragment or Namespace support)
- WebKit Nightly (51% - No Fragment or Namespace support)
- Opera Gogi - "ACID3 Build" (76.7% - No Fragment support)
- IE 8 (Can't run - the file is proper XHTML so it tries to download it.)
- Firefox 3, Opera 9.5, IE 7 (0%)
The work that is being done to implement the specification in Firefox can be seen on its associated Bugzilla bug. I'm shooting very hard to make sure that everything is in place so that this makes it in to the upcoming Firefox 3.1 release (the first alpha of which is due out in a couple weeks). The benefits that this will have for both JavaScript libraries and their users will be tremendous.
Tags: w3c, mozilla, firefox, css
16 Comments on 'Implementing a Selectors API Test Suite'
July 2nd, 2008
Last week it came out that, in Firefox (and other Gecko-based browsers) you could dip into the private scope of a function using eval, like so:
// Getting "private" variables
var obj =
(function() {
var a =
21;
return {
// public function must reference 'a'
fn:
function() {a;
}
};
})();
var foo;
eval('foo=a', obj.fn);
console.log(foo); // 21
I think the common response to seeing the above was something like: WUH!?!?
As can be seen in the ensuing discussions.
Perhaps more interestingly is the dig in to try and figure out how on earth this feature made it in to the language to being with. Brendan Eich provides some insight:
3.2 <fur> 1998-04-23 17:30: Initial checkin of JavaScript 1.3, migrated from JSFUN13_BRANCH in /m/ src repository
This eval extension, if memory serves (I was in mozilla.org at the time, not in the JS group at Netscape) originated in conversations with Microsoft's rep during ECMA-262 standardization, trying to reach agreement on a way to eval in other scopes.
At this point, however, it's pretty safe to say that since so few people know about it, and that (hopefully) there are no important sites relying upon its behavior, it can be stricken from the record.
Which it has been.
It's been a crazy ride but you can expect to see this feature gone in Firefox 3.1 (the next release of Firefox, set to debut this year).
Tags: firefox, mozilla, javascript, links
18 Comments on 'eval() Kerfuffle'
June 25th, 2008
Visit: New CSS Features in Firefox 3
David Baron, a Mozilla developer, has a write-up on the new CSS features that are available in Firefox 3. There's a mix of additions - everything from CSS 2.0 and 2.1 features to new additions that are tracking CSS 3.
Some of my favorite additions include:
The CSS 3 Box Specification (in the form of -moz-max-content, -moz-min-content, -moz-fit-content, and -moz-available values to width, min-width, and max-width).
-moz-fit-content actually does let authors do some things that previously weren't possible without tables, such as putting a background on headings that doesn't fill the whole width of the container unless the heading does, but is a single rectangle if the heading breaks to multiple lines (see Demo).
Wrapped whitespace (white-space: pre-wrap). This allows you to have a <pre/> whose contents are wrapped nicely, while still maintaining its rigid structure.
rgba() values. You can now apply opacity directly to background colors (as opposed to having to create a shim div/span and styling that instead). Note that the below text is fully opaque.
body { background: url(stripes-6); }
div { background: rgba(0, 255, 0, 0.5); }
h2 { background: rgba(255, 0, 0, 0.5); }
inline-block and inline-table Such a powerful addition - and one that now brings Firefox in line with most other browsers. It'll allow you to create much-more-complicated layouts that were previously very trying to implement using normal CSS. Demo.
Tags: firefox, mozilla, css, links
10 Comments on 'New CSS in Firefox 3'
June 23rd, 2008
It was fascinating to watch the unveiling of Firefox 3 last week. I'm pleased that, in some small way, my contributions helped to bring this browser out the door.
First 24 hours: 8.3 million downloads, 69 downloads/second, 20 Gb/s Peak Transfer
While I generally focus on issues tangential to JavaScript code, at Mozilla - like testing, performance analysis, specifications, standards, bug hunting, speaking, demos, and blogging - some of my code is live within the browser, and that makes me quite happy.
One of my first tasks at Mozilla was to, with Mark Finkle, develop a JavaScript API for performing common interactions typically desired by extension developers, called: FUEL. This is a pure-JavaScript implementation that sits as a proxy inbetween the developer and the various, traditional, XPCOM-style ways of performing actions.
If you're interested in learning more about FUEL I've collected a number of links and examples:
The Development of FUEL
FUEL was created over the course of a couple months, in early 2007, by Mark Finkle and I. Mark had much-better knowledge of Mozilla's APIs and I had good knowledge of JavaScript and API design - the match worked out nicely. I've written a couple blog posts on FUEL and so has Mark.
You can also see the features and code that went into FUEL 0.1 and FUEL 0.2 in Bugzilla.
FUEL, Today
Today FUEL lives in Firefox 3 (meaning that you can use it to develop Firefox extensions) and is part of the core Mozilla platform (meaning that portions of the API will be available in any Mozilla-based application that is built). For example you can even use a FUEL-like API in Thunderbird (called 'STEEL'). Here are some of the best resources for getting started with FUEL in Firefox 3:
Here are some of my favorite example of FUEL in action. It was very important to me that the most-common actions take no more than a single line of code to perform - with even complex actions keeping nice and trim.
Open, and activate, a new tab pointing to Google.com
Application.browser.open("http://google.com/").active = true;
Close the active browser tab
Application.browser.activeTab.close();
Close all tabs that mention Google
Application.browser.tabs.forEach(function(tab){
if ( tab.url.match(/google/) )
tab.remove();
});
Add a new bookmark pointing to Mozilla
Application.bookmarks.add("Mozilla", "http://mozilla.org/");
Remove all bookmarks pointing to Google.com
Application.bookmarks.all.forEach(function(cur){
if ( cur.url.match(/google.com/) )
cur.remove();
});
FUEL, Future
Development is still going strong on FUEL. There's a Google Summer of Code student working on extending the API and porting it to more parts of the platform (along with backwards support for Firefox 2!). We'll probably end up seeing this in Firefox 3.1 (the next version of Firefox, due out later this year).
If you have any questions concerning how to use FUEL, or to develop Firefox extensions in general, your best bet would probably be to join the #extdev IRC channel on irc.mozilla.org. Lots of knowledgeable people hang out there and will be more-than-capable of answering any questions that you might have.
Once again, I'm terribly excited by the final release of Firefox 3 - here's hoping to many more excellent releases to come!
Tags: extensions, firefox, mozilla, javascript
14 Comments on 'Simple Extensions in Firefox 3'
May 20th, 2008
There's been an interesting security adjustment in Firefox 3 that'll have some, potential, ramifications in some (file://-hosted) web pages. Specifically how local files are referenced and accessed, in parent directories, has changed.
For example, previously you could create an HTML page and have it request a file in a parent directory, like so:
<html>
<head>
<title>Local File
</title>
<script>
var xhr = new XMLHttpRequest();
xhr.open("GET", "../some/file.txt", true);
// ... handle the response ...
xhr.send(null);
</script>
</head>
<body></body>
</html>
However that is no longer possible (just to emphasize: This is no longer possible only on locally downloaded web pages, running in file://...) as an HTML page can no longer access files in parent directories. This includes both ../ relative URLs and file://... absolute URLs.
There's a detailed discussion in the bug ticket concerning this change. Primarily it boils down to the fact that:
Users frequently download HTML pages for a variety of reasons, HTML pages have full access to the hard drive and the ability to do cross-domain communication, this combination leads to an unsuspecting mess where malicious pages can actively try to steal user information.
This change is two-fold: It's possibly frustrating (there's bound to be some HTML page somewhere that uses XMLHttpRequest to local in local information, located above the current directory) and unavoidable (having this security concern left in place would lead to undesired situations, if they haven't already).
Generally speaking I don't think this change will affect many people - but it's just something that you should be aware of, when planning your sites for Firefox 3.
UPDATE: In the original post I interpreted the Bugzilla bug as being that ALL attempts to access parent-directory files were blocked when, in fact, only items bound by the same-origin policy are (like XMLHttpRequest). This should affect significantly few pages but it's good to be aware of.
Tags: javascript, firefox, mozilla, html, security
23 Comments on 'Tightened Local File Security'
April 29th, 2008
Deb Richardson wrote up an interesting piece today describing color profile support in Firefox 3. The result of a color profile is a more-accurate mapping from an original set of colors to better match the intended rendering. Profiles can be provided by the operating system (to provide better color distribution globally) or even locally by individual images.
For example, observe the following image which compares the difference between Firefox 2, Firefox 3 (with color profile support), and an image in Adobe Photoshop:
There is a noticeable difference between the rendering of the image in Firefox 2 compared to both Photoshop and Firefox 3 (in which they are rendered identically). All of this is due to the fact that Firefox 3 and Photoshop use the additional color profile information to get a better mapping of the resulting colors.
There's one tricky point, however: Color profile support is disabled, by default, in Firefox 3. However, it can be quickly enabled by installing the Color Management Add-on or by twiddling some options in about:config.
The reasoning for the feature being disabled was outlined for two particular issues:
- There was a large 10-15% drop in performance when this feature was enabled. The extra time spent on large images began to add up quite quickly. Obviously this will be a point that'll be worked on in upcoming releases - but introducing a regression that large was pretty much unacceptable.
- Plugins (such as Flash, Silverlight, Quicktime, etc.) did not do color profile correction, causing rough mis-renderings to occur. This correction is, unfortunately, left up to the plugins themselves - leaving this out of the realm of the browser itself. It's unclear as to how this will be resolved.
At the very least, however, you can grab the Color Management Add-on with your copy of Firefox 3 and begin to view your pictures with an extra level of color and crispness.
Tags: firefox, colors, mozilla, browser
20 Comments on 'Color Profiles in Firefox 3'
April 29th, 2008
A common concern of most Ajax applications has been around their resulting accessibility. While, arguably, it's possible to design some form of a usable web page without the use of JavaScript it should be possible - with the additional scripting information - to provide a better experience to users. It's at this point that the ARIA specification comes into play. A large set of interaction is defined within it which is able to help web applications communicate directly to a screen reader in an effective manner.
To get a feel for what this interaction looks like, take the example of ARIA Live Regions (more info). With this functionality it would be possible to keep a live-updated list of users and allow the screen reader to keep up-to-date.
Observe the following ARIA-marked-up HTML:
<b>Active Users:
</b>
<p id="users-desc">A list of the currently-connected users.
</p>
<ol aria-live="polite" aria-relevant="additions removals"
aria-describedby="users-desc" id="users">
<li>John
</li>
<li>Mary
</li>
<li>Ted
</li>
<li>Jane
</li>
</ol>
A couple settings are used to make this piece of HTML particularly interactive to the screen reader (the actual JavaScript that will update this list is left out - but needless to say nothing, in particular, is needed beyond simple DOM insertion and removal).
- aria-live="polite" How polite the live area is (as in, how likely is it to butt in to what the user is currently listening to/interacting with). The default is 'polite' - in that it waits until all forms of user interaction have been completed before describing the updates to the user.
- aria-relevant="additions removals" Only notify the user about new node additions and removals. Since we wish to provide the user with a live list of users we can expect them to be both transitioning online and offline - this will give us the appropriate level of updates to make this possible.
- aria-describedby="users-desc" A pointer to the element that describes the contents of the live area. If the user
wishes to know more about what the contents of the field represent this element can be read to them.
What's most important about all of this, though, is that ARIA isn't just a pipe dream of functionality: It's implemented, today, in Firefox 2 and even more-so in the upcoming Firefox 3.
The Google Reader team recently took advantage of this and added full ARIA support to their application. It's safe to say that Google Reader is not a trivial application by any stretch, allowing this to demonstrate the feasibility of ARIA within large-scale web application projects.
In the course of their implementation they built a tool, AxsJAX, which injects ARIA usability enhancements into many pages using a bookmarklet, greasemonkey, or Fire Vox (a Firefox screenreader). They started by seeding a number of Google applications with this drop-in accessibility support (along with a few others, including the XKCD web comic).
I continue to be impressed with what can be accomplished with ARIA - and seeing the work that Google has been putting forth by implementing this functionality in their applications has been incredibly enlightening and encouraging.
Tags: ajax, javascript, accessibility, mozilla, firefox, aria
11 Comments on 'Ajax Accessibility'
·
« Previous entries
