Jeff Walden: SpiderMonkey JSON change: trailing commas no longer accepted

Historically, SpiderMonkey’s JSON implementation has accepted input containing trailing commas:

JSON.parse("[1, 2, 3, ]");
JSON.parse("{ 1: 2, }");

We did so because the JSON RFC permitted implementations to accept extensions, and trailing commas are nice for humans to be able to use. The down side is that accepting extra syntax like this makes interoperability harder: implementations which don’t implement the same extension, for reasons every bit as valid as those of implementations allowing the extension, are disadvantaged. ES5 weighed these concerns and chose to precisely specify permissible JSON syntax to put everyone on the same page: trailing commas are not permitted. Therefore, the examples above should throw a SyntaxError per ES5.

SpiderMonkey has now been changed to conform to ES5 on this point: trailing commas are syntax errors. If you still need to accept trailing commas, you should use a custom implementation that accepts them — but best would be for you to adjust the processes that produce JSON strings including trailing commas to not include them. (If you are an extension or are in privileged code, for the moment you can use nsIJSON.legacyDecode to continue to accept trailing commas. However, note that we have added it only to accommodate legacy code in the process of being updated to no longer generate faulty input, and it will be removed sometime in the future.)

You can experiment with a version of Firefox with this change by downloading a TraceMonkey branch nightly; this change should also make its way into mozilla-central nightlies shortly, if you’d rather stick to trunk builds. (Don’t forget to use the profile manager if you want to keep the settings you use with your primary Firefox installation pristine.)

Jeff Walden: New ES5 strict mode support: now with poison pills!

tl;dr

Don’t try to use the arguments or caller properties of functions created in strict mode code. Don’t try to use the callee or caller properties of arguments objects corresponding to invocations of functions in strict mode code. Don’t try to use the caller property of a function if it might be called from strict mode code. You are in for an unpleasant surprise (a thrown TypeError) if you do.

function strict() { "use strict"; return arguments; }
function outer() { "use strict"; return inner(); }
function inner() { return inner.caller; }

strict.caller;    // !!! BAD IDEA
strict.arguments; // !!! BAD IDEA
strict().caller;  // !!! BAD IDEA
strict().callee;  // !!! BAD IDEA
outer();          // !!! BAD IDEA

Really, it’s best not to access the caller of a function, the current function (except by naming it), or the arguments for a given function (except via arguments or by use of the named parameter) at all.

ES5

ES5 introduces the curious concept of strict mode. Strict mode, whose name and concept derive from the similar feature in Perl, is a new feature in ES5 whose purpose is to deliberately reduce the things you can do in JavaScript. Instead of a feature, it’s really more the absence of several features, within the scope of the strict-annotated code: with, particularly intrusive forms of eval, silent failure of writes to non-writable properties, silent failure of deletions of non-configurable properties, implicit creation of global-object properties, and so on. The goal of these removals is to simplify both the reasoning necessary to understand such code and the implementation of it in JavaScript engines: to sand away some rough edges in the language.

Magical stack-introspective properties of functions and arguments

Consider this code, and note the expected behavior (expected per the web, but not as part of ES3):

function getSelf() { return arguments.callee; }
assertEq(getSelf(), getSelf); // arguments.callee is the enclosing function

function outer()
{
  function inner() { return arguments.callee.caller; } // inner.caller === outer
  return inner();
}
assertEq(outer(), outer); // fun.caller === nearest function in stack that called fun, or null

function args2()
{
  return args2.arguments;
}
assertEq(args2(17)[0], 17); // fun.arguments === arguments object for nearest call to fun in stack, or null

Real-world JavaScript implementations take many shortcuts for top performance. These shortcuts are not (supposed to be) observable, except by timing the relevant functionality. Two common optimizations are function inlining and avoiding creating an arguments object. The above “features” play havoc with both of these optimizations (as well as others, one of which will be the subject of a forthcoming post).

Inlining a function should conceptually be equivalent to splatting the function’s contents in that location in the calling function and doing some α-renaming to ensure no names in the splatted body conflict with the surrounding code. The ability to access the calling function defeats this: there’s no function being invoked any more, so what does it even mean to ask for the function’s caller? (Don’t simply say you’d hard-code the surrounding function: how do you know which property lookups in the inlined code will occur upon precisely the function being called, looking for precisely the caller property?) It is also possible to access a function’s arguments through fun.arguments. While the “proper” behavior here is more obvious, implementing it would be a large hassle: either the arguments would have to be created when the function was inlined (in the general case where you can’t be sure the function will never be used this way), or you’d have to inline code in such a way as to be able to “work backward” to the argument values.

Speaking of arguments, in offering access to the corresponding function via arguments.callee it has the same problems as fun.caller. It also presents one further problem: in (some, mostly old) engines, arguments.caller provides access to the variables declared within that function when it was most recently called. (If you’re thinking security/integrity/optimization hazard, well, you now know why engines no longer support it.)

In sum these features are bad for optimization. Further, since they’re a form of dynamic scoping, they’re basically bad style in many other languages already.

Per ES5, SpiderMonkey no longer supports this stack-inspecting magic when it interacts with strict mode

As of the most recent Firefox nightly, SpiderMonkey now rejects code like that given above when it occurs in strict mode (more or less). (The properties in question are now generally implemented through a so-called “poison pill” mechanism, an immutable accessor property which throws a TypeError when retrieved or set.) The specific scenarios which we reject are as follows.

First, attempts to access the caller or arguments (except by directly naming the object) of a strict mode function throw a TypeError, because these properties are poison pills:

function strict()
{
  "use strict";
  strict.caller;    // !!! TypeError
  strict.arguments; // !!! TypeError
  return arguments; // direct name: perfectly cromulent
}
strict();

Second, attempts to access the enclosing function or caller variables via the arguments of a strict mode function throw a TypeError. These properties too are poison pills:

function strict()
{
  "use strict";
  arguments.callee; // !!! TypeError
  arguments.caller; // !!! TypeError
}
strict();

Third (and most trickily, because non-strict code is affected), attempts to access a function’s caller when that caller is in strict mode will throw a TypeError. This isn’t a poison pill, because if the "use strict" directive weren’t there it would still “work”:

function outer()
{
  "use strict";
  return inner();
}
function inner()
{
  return inner.caller; // !!! TypeError
}
outer();

But if there’s no strict mode in sight, nothing will throw exceptions, and what worked before will still work:

function fun()
{
  assertEq(fun.caller, null); // global scope
  assertEq(fun.arguments, arguments);
  assertEq(arguments.callee, fun);
  arguments.caller; // won't throw, won't do anything special
  return arguments;
}
fun();

Conclusion

With these changes, which are required by ES5, stack inspection is slowly going the way of the dodo. Don’t use it or rely on it! Even if you never use strict mode, beware the third change, for it still might affect you if you provide methods for other code to call. (But don’t expect to be able to avoid strict mode forever: I expect all JavaScript libraries will adopt strict mode in short order, given its benefits.)

(For those curious about new Error().stack, we’re still considering what to do about it. Regrettably, we may need to kill it for information-privacy reasons too, or at least censor it to something less useful. Nothing’s certain yet; stay tuned for further announcements should we make changes.)

You can experiment with a version of Firefox with these changes by downloading a TraceMonkey branch nightly; these changes should also make their way into mozilla-central nightlies shortly, if you’d rather stick to trunk builds. (Don’t forget to use the profile manager if you want to keep the settings you use with your primary Firefox installation pristine.)

Nick Nguyen: Five years in California

The two of us at Ridge Winery just after arriving.

As a young child in Ohio, I had this Midwestern notion of California, one shaped by countless episodes of CHiPs and Knight Rider.  To me, California was palm trees, fast cars, and beaches.  As I grew older, I started to dream of Silicon Valley, the place that Zorin tried to destroy in A View to a Kill, and where 20525 Mariani Avenue was located.  As I embraced my inner nerd and made technology my career, I always thought that California was too expensive, too elitist, and too far away for me to ever call it my home.

This past week marks five years in this great state, and I can hardly believe it’s been that long.  5 years is a long time- longer than high school, college, and enough for an infant to learn how to read.  I’ve lived in California longer than anywhere except for Ohio, and it’s been an amazing ride so far.

In the summer of 2005, I was a business analyst at Ford, exploring my interest in the automotive industry by jumping in head-first.  I had just had a conversation with a very senior product guy telling me what I needed to hear- that chances were slim that I would ever get a shot in the product planning org, because I hadn’t joined straight out of college, nor did I have the right degree from the right school.

It was a difficult conversation, but a catalyst for what was to come.  I got in touch with my good friend Don at Yahoo!, who, in a stroke of wild luck, was working in the same group as one of my best friends from high school, Stephen.  I had no product management experience but I did have two things- empathy for people unlike myself, and an intense curiosity about just about anything worth learning about.  Neither of those talents were particularly obvious from my resume, but enthusiastic endorsements from both Stephen and Don secured me my gig at Yahoo!, working for Don as a PM for Search Shortcuts.

I built cool stuff at Yahoo! Search- those little shortcuts that appeared at the top of the results when you typed something like “Twilight” into a browser and got a list of showtimes in your area, making millions of people every day at least two percent happier.  Yahoo! was also an amazing place to work back then- full of energy, hope, and the piss and vinegar to think they could take on Google in the search game.  The end of that story is all but written now, but I’m proud of what we were able to accomplish with such a small team- Yahoo! was much larger than Google in those days, but we had far fewer people on search than Google did.

At Yahoo!, I also worked on Answers and del.icio.us.  On Answers, I saw a huge and vibrant community get destroyed by an even bigger deluge of new users.  On del.icio.us, I learned from Joshua that social software is best when it has some personal utility, because self-interest is a powerful incentive to use any product. I had the privilege of launching the del.icio.us Firefox extension with a small but dedicated team of engineers,  who spent as much time as I did talking to our community of users and making the best possible thing that we knew how to make.

We did screw up occasionally, but any complaints were drowned by a chorus of understanding- because we learned that being up front with users and reacting quickly to their complaints is a great way to build goodwill.  I have fond memories of begging Shaver to review our add-on, not knowing of his greatness then and now.  I also got to meet Chris Beard, Alex Faaborg, and Dan Mills back in 2007 when they were talking about building some sort of sync feature into Firefox 3, which eventually became Firefox Sync.

I left Yahoo! in May of 2008, and at Raptr, a social network for gamers, I was a cheerleader, a project manager, a waterboy, a metrics guy, and a crappy front end developer at varying times during those months, but by the end we had target personas, specs for every major feature, and we ended up releasing on time(ish) in September.  It was a great experience, but it was an exhausting one, where I learned a lot in exchange for my 7 day work week and frequent forays into the early AM in the office.

These were exciting times, and I wasn’t looking to go anywhere- until Mozilla called.  I remember vividly that call I got from Bret when he asked me if I wanted to interview for the add-ons gig.  I wasn’t looking for a job, but this was a job that I felt I was uniquely qualified to do, with a company that valued what I valued, and with smart and inspirational people to boot!  The interviews were a bit wild- from the first interview with Chris Beard, where I felt like I understood about 20% of what was said, to the slightly awkward conversations with Mike Morgan and Fligtar, both some of my favorite people today.

Mozilla’s been everything I could have hoped for and more- and the mission of preserving the Internet as a source of innovation and opportunity for everyone is one that makes it easy to come to work each day.  It’s hard to believe that I’ve only known some of my very best friends for less than two years, but the people at Mozilla are all ferociously special- the sorts of people who are generous with their time and knowledge, young enough to not know what’s impossible, and great enough to be fun to spend lots of time around.

Personal stuff happened too! Bridget and I married on September 1, 2006,  right before my 30th birthday- at the San Francisco City Hall.  We had no actual wedding, just immediate family on hand, and we had a marvelous weekend of dining and exploring San Francisco with our families.  The best $80 we will ever spend, and in 2007, we bought our amazingly original and retromodern 50-year-old Eichler home in San Jose.  We’ve been fixing it up these past few years, with Bridget handling the heavy duty stuff like redoing walls and building garden boxes, while I do the electrical work and plumbing.  Bridget is a person who seems to be able to do anything she puts her mind to, whether it’s restoring a 120 year old letterpress, training and doing a triathlon, or scoring a gig at flickr just because she loves the product.

These have been a great five years- I’ve made lifelong friends, and I’ve been involved in things that I wouldn’t have believed possible before I moved here.  I can’t wait to see what the next five years will bring.

Mozilla IT: Mozilla Scheduled Downtime – 09/09/2010, 5pm PDT (0000 UTC)

We will have a scheduled maintenance window tonight from 5:00pm to 7:00pm PDT. The following changes will take place:

• 5:00pm PDT (0000 UTC) We will be upgrading all the components of Socorro, and we expect this to take up to two hours, less if all goes well.  Web app upgrades (crash-stats.mozilla.com) are minor so user facing downtime should be only a few minutes towards the end of the window. Duration: 2 hours.

Please let me know if you have any reason why we should not proceed with this planned maintenance. As always, we aim to keep downtime to as little as possible, but unexpected complications can arise causing longer downtime periods than expected. All systems should be operational by the end of the maintenance window.

Feel free to comment directly if you see issues past the planned downtime.

Meeting Notes from the Mozilla community: Mobile Meeting Minutes: 2010-09-08

Meeting Notes from the Mozilla community: Firefox/Gecko Delivery Meeting Minutes: 2010-09-08

David Mandelin: Jägermonkey: it’s in ur browser!!!

At the beginning of this year, the Mozilla JavaScript team started a new project, code-named JägerMonkey, with a simple goal: make us fast.

Our previous major engine upgrade, TraceMonkey, gave Firefox 3.5 a big speed boost. But while the technology inside TraceMonkey makes it faster than any other engine on certain programs (then and now), it doesn’t help other programs as much. And the web has grown more complex, with more and more JavaScript-intensive demos, apps, and games. And the competition has been getting a lot tougher, with engines that could run fast on bigger and prettier web apps. We knew we needed another major upgrade for Firefox 4.0, to make us fast all around.

So, we went off for 8 months of studying the classic research, reverse engineering the competition, measuring, experimenting, designing, prototyping, analyzing performance, scrutinizing assembly code, redesigning, coding, and lots and lots of debugging. David Anderson and I intend to blog more about the techniques and technologies we used in our copious free time in the weeks between now and release.

As part of the project, we revamped the JavaScript engine’s fundamental value type, touching about 20,000 lines of code, which I compared to a vascular system transplant in an earlier post. We imported a couple of basic components, the assembler and the regular expression compiler, from WebKit’s JavaScriptCore. We created a new cross-platform whole-method JIT compiler in about 23,000 lines of code. It supports x86, x86-64, and ARM in an almost entirely shared compiler code base, the only JS engine that does so (to our knowledge). And it all works together with the existing TraceMonkey trace JIT compiler.

You can try the new JavaScript engine now in our Firefox JS Engine Preview Builds. If you try them, you should see:

• Big improvements in benchmark scores. Those aren’t the main goal–but they are a really convenient target for us to aim at.
• Things just feel faster, especially big JavaScript-heavy things like Gmail and Facebook. That’s subjective, so as an engineer I feel a bit funny touting it, but that’s what early users are saying, anyway. :-]
• Cool demos and games work great now. You can play a good game of Super Mario Bros in JavaScript now. Or play some Gameboy. Or try a fluid simulator.

Keep in mind that these are only preview builds, and we are not done yet, which means:

• We should be a little bit faster yet by the time Firefox 4 is released. In particular, we’re still working on making function calls faster, which should speed up pretty much every non-tiny JavaScript program.
• If you come across something where our speed is not up to scratch, let us know! (For that matter, if you come across something that Jägermonkey works great on, we’d feel good hearing about that too!) We still have time to fix performance issues or add a key optimization or two. Filing a bug is the most convenient way for us (and this link should save you from any need to dig through Bugzilla). But the important thing for us is to find out, so always feel free to just send us an email.

For me, one of the most satisfying parts of this project has been working together as a team. You can just feel it when a team really comes together, each person knowing what their teammates are up to and naturally supporting and depending on each other. Both the Jägermonkey team and the larger JavaScript team really came together this year–it’s been great.

Another cool thing is that we dared to give key pieces of the project to our interns this summer, and they all came through!

The rest of the JavaScript team made our project possible: they kept the lights on in the rest of the JS world, and put together some critical components Jägermonkey needs to work correctly. We got some nice help integrating with the rest of the browser from mrbkap and peterv. The community helped us out, especially with testing, finding performance problems, and, most of all, cheerleading and moral support. I’d especially like to acknowledge the people outside the core JM team who contributed code: platform engineer Brian Hackett, who created many excellent optimizations; Julian Seward, who needs no introduction, and did us a big favor in porting over WebKit’s assembler; Bill McCloskey, who just started but already wrote a JM patch and is optimizing integration with the tracer; and contributor Jan de Mooij, who wrote several optimization patches.

Finally, here’s the Jägermonkey team: from left to right, Andrew Drake, Alan Pierce, Sean Stangl, David Anderson, Luke Wagner, Chris Leary, and Dave Mandelin.

David Anderson: Land Ho, Fast JavaScript!

Firefox just got a whole lot faster.

I’m excited to announce that Mozilla’s new JavaScript engine, JägerMonkey, is now available for testing!

What is JägerMonkey?

JägerMonkey is our new optimizing JIT compiler for JavaScript. It sits underneath our existing JIT, TraceMonkey, which appeared in Firefox 3.5. If you recall from previous posts, TraceMonkey’s job is to optimize loops to very fast machine code. However, not all code has loops, and not all loops can be trace compiled.

JägerMonkey is a general-purpose compiler which converts entire methods to machine code. The goal is to get great baseline performance. When it detects a loop that can be traced, it automatically engages the trace compiler, which makes it even faster. Yes, that’s right: there’s a turbo button inside.

This hybrid approach is designed to use well-established optimization techniques that work everywhere, and combine them with our existing hyper-optimizing engine that handles smaller subsets of code.

Results.

If you’ve been obessing over Are We Fast Yet? like me, you’ve seen the numbers dive. If you download a build you can play demos like JSNES at a full, glorious 60FPS. Want to try it out? Click here to get preview builds of Firefox 4 with our new JavaScript engine.

Disclaimer: It’s a preview – we’re still ironing out the rare kinks. Please report bugs or tell us if something’s wrong (or slow!)

Benchmarks.

We’ve been using the SunSpider 0.9.1 and V8-v5 benchmarks to gauge our general progress. SunSpider is a full 2X faster over Firefox 3.6!

Our improvement on the V8-v5 benchmark is even more dramatic – 4X!

Ongoing Work.

The rockin’ doesn’t stop here. Right now we’re polishing off the final pieces to get into the next Firefox 4.0 Beta. At the same time, here are some of the immediate performance works-in-progress:

1. Function Calls. As discussed previously, this is one of our last big areas of optimization. The first of four major pieces, caching call sequences, was completed this week. The second big chunk, which Luke Wagner has slated for this week, will make arguments and stack frames faster. Brian Hackett, Chris Leary, and Bill McCloskey have more stack frame optimizations as part of the third wave.
2. Tracer Integration. Deciding when to use the turbo button is pretty hard, but Bill and Dave have been researching it thoroughly. Right now we’re just scratching the surface, and we will have much better heuristics by the end of the month.
3. Web Optimizations. Community member Jan de Mooij is continually finding demos and real-world tools and improving performance “gotchas” in our engine, like making common arithmetic patterns faster.

Conclusions.

Firefox 4 is seeing dramatic wins over 3.6 and the web is feeling faster. You can try it out now using a JS Engine Preview, or wait for Firefox 4 Beta 6.

Please stay tuned as we approach JägerMonkey end-game for Firefox 4. Dave Mandelin and I will be blogging, and for smaller things, tweeting (his here) progress & technical updates.

Luis Villa: reading recommendation on American political multilingualism?

I’m trying to find a book on the political history of multilingualism in the US; in other words, of why/when it started becoming acceptable (and in some cases required) for government works, electoral ballots, etc., to be written and printed in multiple languages. This is related to some of the talk about mozilla-as-social-movement that a variety of Mozilla folks have been talking and blogging about lately; I’m curious if some of the rationales and arguments used by supporters of multilingualism would be applicable to software. Anyone have any pointers? Thanks!

Mozilla Security: X-Frame-Options

One of the security enhancements included with Firefox 3.6.9 is support for the x-frame-options header. This optional header can be included within the HTTP response to instruct the client’s browser on whether the returned content is allowed to be framed by other pages.

A website can choose to include the x-frame-options header to protect against malicious framing of web content by third parties. For example a malicious site might frame a website from another domain and surround the framed site with advertisements. Alternatively, a malicious site could use a CSS layer attack called ClickJacking to trick users into performing unintended actions within the framed website that is obscured by overlaid CSS layers.

The x-frame-options header supports the following values:
SAMEORIGIN – allows only sites from the same domain to frame the page
DENY – prevents any site from framing the page

Additional Reading:
Mozilla Developer Network article
Microsoft Developer Network article
OWASP Clickjacking Article

Michael Coates
Web Security

Alon Zakai: iX script I wrote a small script for investigating xpconnect objects at runtime, iX (investigate Xpconnect).

If you paste that code in a JavaScript file, and run iX(something), it will dump all the info it can find about the object: all regular JavaScript properties, as well as all valid interfaces that you can QueryInterface and GetInferface on that object, and also the node hierarchy. And it tries not to crash when doing so.

(There is probably already something to do this that I am not aware of.)

David Humphrey: How much does a song cost?

Lukas and I were talking about a great video today, The Money Tree, in which a tree is carefully adorned with 100 one-dollar bills, each one containing a short note exemplifying the obvious serendipity of coming upon such a sight.  It’s a wonderful video, and the music is great too.

It caused me to share a similar idea I’ve had related to music on the web.  One of the situations I run into a lot as I make various audio demos for the web is that I constantly have to find freely-licensed music.  There is some great stuff out there–the track we used in our most recent demo is a good example–but you have to know where to look.  Also, these wells are often shallow, and you have to constantly be on the lookout for more of them in order to get enough of what you need.  Then there are artists (Moby is one example) who have made it possible to use their stuff for free demos.  But it’s not easy to find all this stuff, despite how great search is supposed to be these days.

So what about this.  What if you bought a song, and then released it to the web for free?  I don’t mean “bought the right to download it from iTunes and uploaded to a p2p site.”  No, I’m talking about buying the song outright.  Buying exclusive rights to it, and dumping it into the public domain. Crazy, right?

Well, what does a song cost?  Let’s forget about Top 40 music for a minute, since I don’t want that even if it were possible to afford it.  I’m thinking more of the kind of music people want for demos and videos and soundtracks.  $10K?  $100K?  The RIAA seems to think $750K is a reasonable amount for a song.  A cool $1 million?

The economics of this don’t look good until you stop and realize that as you read this, millions of people are paying $0.99 for songs on iTunes, paying for the right to download them into their personal collection.  Now, what if instead of doing it that way, a bunch of fans got together and pooled their $0.99s, add them together until it comes to some insane amount that satisfies The Industry.  They exchange this huge sack of money for the right to walk away with this song they love, and then share it by putting it into the public domain.  Everyone wins.

It’s possible to buy one-of-a-kind paintings, statues, and the like, and to then donate them to museums where the public can go and enjoy them.  Is it possible to buy a song?  ’cause if it is, there are a lot of us already basically doing this.  We just need a way to do this transaction.

about:mozilla: Firefox 4, Web Console, add-ons, Drumbeat, Firefox Home, Africa, Fennec, and more…

In this issue…

• Latest Firefox 4 beta update
• Introducing the Web Console
• Add-on compatibility for Firefox 4
• Rock Your Firefox
• Hardware acceleration coming to Firefox
• Mozilla Drumbeat: What’s next?
• Localizing Firefox Home
• Want to hack on Firefox 4?
• Firefox 4 AT Vendor Alert
• Mozilla in Africa
• Fennec 2: changes for add-ons
• Software releases
• Upcoming events
• Developer calendar
• About about:mozilla

Latest Firefox 4 beta update
“The latest update to Firefox 4 Beta brings super fast graphics and incredible new audio capabilities to the Web. Firefox 4 Beta now leverages hardware acceleration to improve graphics performance for Windows users and also allows, for the first time, the visualization of audio data within the browser.” Read more about this latest beta update at the Mozilla Blog, and download the beta today!

Introducing the Web Console
Mozilla’s DevTools team has been working on a new Web Console feature for Firefox 4. Kevin Dangoor recently posted about the Web Console, talking about what it is, how you can see it now, and what it provides to web developers — including logging, network details, the console object and a Read Eval Print Loop (REPL) for JavaScript. Read more, including what’s next for the Web Console and how to get involved, in Kevin’s post.

Add-on compatibility for Firefox 4
Jorge Villalobos has posted an update for add-on developers about ensuring add-ons are compatible with Firefox 4. His post includes links to three key resources, including a Firefox 4 Compatibility discussion, and covers new UI features, development and packaging notes, and more. Read all about it at the Mozilla Add-ons blog.

Rock Your Firefox
Rock Your Firefox is a place for Firefox users to discover cool new add-ons and learn what add-ons are all about. Elise Allan has been spearheading this project recently, posting about add-ons such as Read It Later, WeatherBug, AutoCopy, and FoxClocks as well as research like the BlogHer browser survey results. It’s a great resource for learning about new add-ons — check out the blog or follow @rockyourfirefox on Twitter.

Hardware acceleration coming to Firefox
The most recent Firefox 4 beta includes hardware acceleration for Windows Vista and Windows 7 users, through a rendering system called Direct2D. “Direct2D is part of the DirectX package which is shipped with Windows. It allows us to access the hardware with a simple 2D graphics drawing API for all Mozilla drawing code, allowing hardware acceleration for a very large number of scenarios.” While Direct2D is not available on other platforms, the Graphics team is hard at work on alternative approaches. Read more at Bas Schouten’s weblog.

Mozilla Drumbeat: What’s next?
The Drumbeat team is looking for your help and feedback! “We’re eight months into Drumbeat. We’ve built a bit of a brand. People are interested. They want to get involved. More importantly: new people have shown up. Educators. Filmmakers. Artists. Not Mozilla natives. These new people are doing interesting things. And their peers are noticing. It’s a good start. We have some momentum. There is potential. Which begs the question: now what?” Mark Surman is looking for your ideas about where Drumbeat should go next, and what they should focus on. Head over to Mark’s blog to read more, and check out the etherpad where his post (and more) is being discussed.

Localizing Firefox Home
Seth Bindernagel, who heads up our localization efforts, recently wrote about what was involved with localizing the new Firefox Home iPhone application. “It turns out that localization on the Apple iPhone platform has some pieces that are very easy to understand and manage, and other pieces that are unique, complex, and do not align well with a global open source project like Mozilla.”

Want to hack on Firefox 4?
The Firefox team has a great opportunity for anyone who has always wanted to work on Firefox but didn’t know how to get started. “If you have an urge to help out you can look through this list of things we want to get done on the add-ons manager before release, pick one and go nuts. These are all things that shouldn’t require very much experience working on the add-ons manager or even Firefox in general, though of course some are easier than others. We have some great information about how to get started and also a great community who can help out if you get stuck. If you’ve ever had a hankering to get involved this would be a great time to dive in.”

Firefox 4 AT Vendor Alert
David Bolter has posted an alert for accessibility technology vendors and developers. As of the most recent Firefox Beta update, “child windows associated with browser tabs have been removed thereby breaking the expectations of most windows screen readers. Regretfully, the timing of this change and the substantial impact it has on AT caught the Mozilla accessibility team by surprise. Unfortunately this change is a critical step in our browser’s technical roadmap. The good news is that this issue was quickly discovered during our recent beta cycle and now we can work together on a fix!”

Mozilla in Africa
William Quiviger, one of Mozilla’s tireless community leads, visited Africa to represent Mozilla at Maker Faire Africa 2010 and to lead several Mozilla workshops in and out of the city. “My aim was to engage with local web enthusiasts and developers, to get a better understanding of how we can best push the Mozilla Project forward in Kenya and in Africa in general.” William has written an extensive and fascinating report about his trip, the events he took part in, and about many of the incredible Mozillians he met along the way. Read more and check out the photos over on his blog.

Fennec 2: changes for add-ons
The most recent alpha release of Firefox for Android and Maemo (aka Fennec) includes some major changes and new features for add-on authors. The Fennec add-on documentation has been updated to include everything you need to know to start updating your Fennec add-ons or creating new ones.

Software releases
* Firefox 4 beta update
* Firefox 3.5.12 and 3.6.9
* Thunderbird 3.1.3 and 3.0.7
* Firebug 1.7a1
* Chromebug 1.7a1
* SeaMonkey 2.0.7

Upcoming events
* Sep 25-26, Berlin, JSConf.eu 2010
* Oct 1-2, New York, Open Video Conference
* Oct 28-29, Toronto, FSOSS
* Nov 3-5, Barcelona, Drumbeat Festival 2010
* Nov 5-7, Gothenburg, FSCONS

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, announcements, events, or software releases 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.

Henrik Moltke: BioCurious: a hackerspace for bio.

Strangely this syncs really well with a conversation I had with Paul Vanouse in Linz this weekend. We need more amateur biotech. We need more open bio data. Bio and open (web). Totally supported on Kickstarter.

Henrik Moltke: A FAT Linz moment + Eyewriter/GML presentation from FutureEverything

F.A.T members Evan and James shortly after receiving the Golden Nica.

Here’s a great presentation by Evan Roth, which tells the story of Eyewriter and how the free hardware / technology and GML stuff connects with this brilliant project. It’s well worth spending twenty minutes on.  Oh, and if you haven’t already, go support Eyewriter / Tony Quan on Kickstarter!

More News