Planet Mozilla

Josh Aas: Gecko 1.9.0 Key Handling Postmortem

Josh Aas — 2008-05-09T21:30:43+00:00

If you’ve participated in or followed Mozilla’s Firefox 3 development over the past month you’re probably aware that we had a bunch of issues with key handling come up at the very end of our development cycle. In the interest of giving others an opportunity to learn from our mistakes and to generally communicate what happened, I’ve agreed to write up a summary of the development team’s postmortem discussion about our recent key issues.

“Key hell” started when I fixed bug 398514, a significant rewrite of our key event flow, and Masayuki Nakano started fixing a major bug concerning key command event mapping on international keyboard layouts (more on Masayuki’s fix later). Prior to my patch we let Mac OS X match keyboard commands to native menu items and then executed associated DOM command nodes based on the operating system matching. The up side of that is that the operating system does all the mapping of key commands to their menu items, the down side is that nothing but the command node associated with the menu item ever sees the event. After my patch we ignored the operating system’s invocation of native menu items in favor of allowing the key event to flow normally through Gecko. This fixed a lot of important bugs, I can’t believe we got away with pigeon-holing key equiv events for so long. The problem is that we were now in charge of mapping key events to their commands. For US English this is pretty simple mapping and it works without special treatment, I didn’t notice any problems because I use US English. When I tested with other keyboard layouts I tested text in text fields - I didn’t test many keyboard commands. My bad #1, but I wasn’t aware of the fact that key commands have certain types of complex mappings under different keyboard layouts and circumstances.

Coincidentally, this problem came up for different reasons on Windows and Linux right before I exposed it on Mac OS X. Masayuki had already started working on a fix because of Windows and Linux. By the time we had sorted through bug reports and figured out what was going on with non-US-English keyboard commands on Mac OS X Masayuki was half way to a fix. This ordeal would have been much worse without that stroke of good luck. Masayuki is a talented guy that understands far more about international keyboard layouts and input than I do, I was pretty happy he was already on the problem.

Masayuki’s patch(es) attempted to solve a very complex problem. The problem has a huge number of edge cases under different keyboard layouts and the process of finding and fixing cases that we hadn’t covered yet dragged out until today. I don’t think any particular engineer is to blame for this, the extended timeline for fixing regressions was the result of late detection and a lack of automated test coverage.

We should have discovered this problem much earlier than we did. I suspect that we finally discovered it as a result of heavy beta usage, especially among international users. User testing is great but it is a perk - not something to be relied upon. We also would have found out about this earlier had I committed my major patch for bug 398514 earlier. We had good reasons for making that change so late, but having good reasons doesn’t shield us from the consequences. At best it just makes the consequences easier to swallow.

The other major factor contributing to this debacle was a lack of automated testing until too late. With a decent test suite we could have found out about most of this much earlier. Even after we found out about the problem it took us too long to get tests in place to aid in avoiding regressions in the fix process. Eventually Roc wrote up a great test system (based on synthesized native events) and that has helped a lot. We’ve since added a bunch more tests to his original set and we’ll be adding many more. If you only take away one thing from all of this writing I hope it is the value of tests - we could have saved a huge amount of time by getting those in place earlier.

There was one other last-minute problem with key handling that got confused with the situation I described above, though it is really a completely separate issue. Mac OS X sends key events into Cocoa apps via confusing and inconsistent paths (performKeyEquivalent: vs. keyDown:, either or both in different orders, plus sometimes we don’t get key up events via keyUp:, sometimes we get key up events but they come in via a second call to performKeyEquivalent:, what a mess Apple!). The circumstances that led to issues with this being a problem at the last minute were basically the same as for the other issues I described.

A big thank-you goes out to Robert O’Callahan, Karl Tomlinson, Matthew Gregan, and Masayuki for working so hard to get this situation under control over the past week. Everyone worked together really well, it was some impressive teamwork.

Songbird: Help Make Songbird Better!

raffel — 2008-05-09T21:10:14+00:00

We’ve been looking for ways to get feedback from active Songbird users because your input helps us make Songbird better. In the next release we’ll be asking users if you’d be willing to take a quick, anonymous survey about the product. The details that follow will only apply to users running 0.6 Final and does not impact nightly users.

We didn’t want this to be a surprise to the community so we wanted to share all the details upfront and be as transparent as possible. To be totally honest, we don’t like asking users to take a survey any more than most people like being asked but we felt like it was critical to the success of the project to gauge the communities feedback to some open questions we have been basing some assumptions upon.

The data we collect will not be shared with 3rd parties. We are simply looking to have more data about what users want in order to help us prioritize implementing the features that you’re asking for. It’s really that simple, cross my heart and hope to die. In the future we might open up a survey on this blog to a larger audience but we wanted to start qualifying some of our assumptions against people who are current, active users of our latest release.

Since we are specifically interested in feedback from Windows, Linux and Mac users who have spent some time running Songbird here’s what it’s going to take to trigger the dialog asking you if you are willing to take the active user survey:

* You will need to be running Songbird 0.6 Final, and
* Have launched the application more than three times, and
* Run the application for at least 30 minutes in total, and
* Satisfied all of these requirements before June 30, 2008

If the above described conditions are satisfied, the next time you launch Songbird you will see a dialog like this, asking you if you’re willing to take the active user survey:

The active user survey will end on July 1st, 2008. If you elect to take the survey a tab in Songbird will open the website hosting the questions (the survey itself will be hosted on SurveyMonkey.com.) If you elect not to take the survey the application will continue to operate as if nothing happened.

Please note: we will only ask users if they are willing to take the active user survey once. If you say no we will not nag you again and we will set a preference in your profile indicating that you didn’t want to take the survey. In the future, assuming you don’t nuke your profile and that we elect to run another survey in the application, we’ll respect that choice and not nag you again. No stats regarding your preference about opting-in or out of the survey will be shared with us, it’s a local setting on your machine and we are not transmitting that data.

Finally, Windows users who uninstall Songbird 0.6 Final will note that going forward there is an option to give us feedback regarding why you uninstalled the application. If you elect to take the uninstaller feedback questionnaire your default browser will launch and open the website hosting the questions (the questions will be hosted on SurveyMonkey.com.)

We want to make clear that we respect your right to choose whether you want to provide us with feedback. Our goal is to simply make Songbird better and we really appreciate hearing from you. Thanks for considering to take the survey and our most sincere apologies to anyone who might take issue with this. We’re open to your feedback including on this subject! Feel free to share your thoughts with us in the comments below or via email, you can reach us at: customer [ a t ] songbirdnest.com. BTW for those wondering Songbird 0.6 will be out in early June!

Mozilla Security: Clarification on Vietnamese Langauage Pack Compromise

Window Snyder — 2008-05-09T18:17:24+00:00

There has been a lot of confusion in the press about the impact of the compromised Vietnamese language pack. Asa put together an excellent blog post walking through some of the confusion and explaining the real impact for users.

Read Asa’s post here: http://blog.mozilla.com/ftr/2008/05/08/vietnamese-language-pack-faq/

David Ascher: inames: any hope?

david — 2008-05-09T17:07:47+00:00

So I have this nice short iname that I registered last year when I was poking around OpenID and the like. That registration is about to expire, and I think I have yet to use it except for testing purposes, in part because there’s no way when being asked for an OpenID to know whether the server supports inames or not. In addition to being just shorter hence cooler, I can’t even remember the benefits of inames over traditional URLs. I guess I’ll let it lapse…

Somebody fix identity. Please?

Robert Kaiser: Dynamic Default Window Size For SeaMonkey

KaiRo — 2008-05-09T17:05:05+00:00

For years, we have read comments about the default browser window size for the Mozilla suite and now SeaMonkey being sucky, as you couldn't even see the the full URL of the default start page. Even if you have a large screen, you end up with something like "http://www.moz" or "http://www.sea" in the visible part of the urlbar, depending on your platform and its UI font settings.
We had improved the situation somewhat in SeaMonkey by making the default window 70ch (avg char width) by 45em (line height) units, so that it's increasing with the default UI font sizes, but it was still awfully small on most current displays.

The reason for not increasing the size more was to still support smaller screens by not making the window going offscreen and be hardly resizeable - and we didn't want to come into that situation.

With our machines for automated testing, we ran into this problem in a different way: The mochitest suite runs its tests in an HTML iframe, with test summary information above it, and this made us end up with mouse events that were automatically generated to happen over elements in the iframe not being successful just because the iframe was not fully visible - the default window was too small to display it as a whole under those test summaries.

This problem caused a certain amount of test failures - at least on Windows. While we found out that increasing the height to 65em should have helped with the tests, such a default window size would get problematic on small screens.

Looking into how Firefox does this, I realized it sets the default window size dynamically, depending on the available screen size. We now implemented this for SeaMonkey as well, though with small improvements over the Firefox solution: While (judging by reading their code, I couldn't test) default Firefox windows probably grow out of the window when the screen is higher than 600 pixels but slimmer than 994 (which can happen e.g. on a rotated 800x600 or 1024x768 screen, but is surely rare), the SeaMonkey code should always make the default window fit into the screen size. On screens with 600px or less in height, we switch to a maximized window, just like Firefox, and on wide screens (over 1440px in our case) we also take only half the width, suggesting side-by-side page view.

If someone happens to have such a strange screen configuration that is higher than 600px but not at least 994px wide, I'd encourage you to test my assumption of Firefox growing out of the screen by default and filing a bug if you can confirm - I'm sure Firefox developers will be happy to fix that edge case.

For everybody else, enjoy upcoming SeaMonkey 2 nightlies and releases making better use of your screen by default when starting up, fixing a long-time-existing problem we heard complaints about every now and then.

Finally, if you're interested in the unit test boxes being visible on the main SeaMonkey tinderbox waterfall page, I'll do that move soon, probably on Monday, as now all available tests on both machines are passing without using any local patches.

David Ascher: Contagious user interface concepts

david — 2008-05-09T16:30:15+00:00

Every now and then, a UI concept is so good that it becomes contagious in fascinating and frustrating ways. I’ve run across two recently.

The first is the iPhone touch screen. A few months ago, when I first got my iPhone, after playing with it for about 30 minutes, I went back to work on my mac, and my fingers automatically expected things like the two-finger zoom to work. I was stunned. Not surprisingly, that is now a feature of the new Macbook Air, and I expect it’ll be in all mac laptops.

The second occurred to me this morning. I was using ssh (a command line tool) to log in to a variety of machines with cryptic addresses, and I knew that I had to start looking for a place to write down those username/hostname combinations. At the same time, I realized that what I really wanted was the awesomebar for my terminal window. The notion that “the computer” should just remember what you’ve done no matter where, because past behavior is the best predictor of future behavior, and that we can implement that quite well with simple mechanisms like keeping a history and doing some math on that history, is a contagious idea. (Note to unix weenies: I know that with the right magic i can get some pseudo-awesomebar within bash. Not good enough! I want bookmarks, tags, weave!)

Naturally, it applies to Thunderbird as well. I routinely go back to “the same” emails. We should find a way to make that as obvious and invisible as Firefox 3 does for web pages.

Eric Shepherd: Firefox 3: Why do I love thee? The third way.

sheppy — 2008-05-09T13:00:53+00:00

I have a dark, dirty little secret. For the first year I worked at Mozilla, I did nearly all of my editing of Mozilla Developer Center documentation using… Safari.

I wasn’t proud of it. In fact, whenever I was visiting coworkers, I would bravely do my work in Firefox.

But it wasn’t easy. Firefox 2 had some really frustrating text layout issues that made heavy editing like what I do on a daily basis nearly impossible. The worst problem was that as I typed, the typing caret would drift, winding up farther and farther out of alignment with where the text insertion point really was. Eventually, editing became impossible just because I had no idea where I was actually typing. It looked a lot like this much of the time:

See how the word “with” is cut off, with only part of the “h” drawn? That’s a result of the insertion point slowly sliding its way to the left as I type. It got worse and worse the more I typed, until finally the edit box was so messed up I couldn’t make heads or tails of it.

With the new Cairo rendering engine used in Firefox 3, all those problems are gone. Text is crisp and clear, and the strange problems with text overlapping or the typing caret being in the wrong place are all fixed.

For a guy that lives and dies in text editing fields, that’s a huge, huge deal.

Giorgio Maone: Misterious Ghost Stories

Giorgio — 2008-05-09T10:50:10+00:00

I would be very interested in learning some technical details of Manuel Caballero’s talk at BlueHat, titled A Resident in My Domain, but so far news are very scarce, fragmented and contradictory.

Its abstract is intriguing:

A Resident in My Domain

Do you believe in ghosts? Imagine an invisible script that silently follows you while you surf, even after changing the URL 1,000 times and you are feeling completely safe. Now imagine that the ghost is able to see everything you do, including what you are surfing and what you are typing (passwords included), and even guess your next move.

No downloading required, no user confirmation, no ActiveX. In other words: no strings attached. We will examine the power of a resident script and the power of a global cross-domain. Also, we will go through the steps of how to find cross-domains and resident scripts.

Then we’ve got two quite reticent posts by Nate McFeters, who was there but pretends he doesn’t remember well enough and/or he can’t disclose such an atomic bomb.

There’s some discussion at TSSCI, but it adds more questions than answers: the article devises similarities with two distinct old and fixed bugs, the nastier affecting IE and the other Firefox; some comments speculate about an IE7 only, possibly patched, vulnerability; but why so much secretiveness if it was already fixed?
Nate, on the other hand, wrote that this is “a horribly serious issue that affects all browsers and is currently not fixed on any of them”.

Direct inquiries in security circles I’m member of did not bring anything less ectoplasmic on the table.

Therefore, all the juice we’ve got so far is a couple of photos authorizing only the following statements:

It is scary.
It has something to do with JavaScript and IFrames.
It definitely works in IE7.

If you can summon anything useful, you’re very welcome!

Mark Banner: Score 1 for MailNews Automated Tests

Standard8 — 2008-05-09T10:30:40+00:00

After the mailnews/ and mail/ source trees reopened yesterday, I checked in a whole bunch of patches that had been queued up during the freeze. Some of them had been in my development tree, some of them hadn’t.

A little while later the SeaMonkey unit test tinderbox was orange. This surprised me, as I was fairly sure I had run all the mailnews tests with the various patches.

It turns out one of the patches (a follow up to bug 424570) had caused a regression where deleting address book cards wouldn’t work properly. This was one of those cases where before we had unit tests I wouldn’t have been surprised if we hadn’t detected the regression for a while.

So as Dan said, score 1 for MailNews automated tests. Although we’ve already seen regressions caught many times for the core tests, its good to see that the MailNews ones are now starting to catch regressions as well.

Paul Kim: Jordan University Mozilla Club Site

Paul Kim — 2008-05-09T05:57:59+00:00

I learned about the Mozilla student club at Jordan University through Issa Mahasneh’s group on Spread Firefox, the online home of our Firefox marketing community.

Hey Issa: this is a really well-done design. Great combination of an overall visual metaphor (a student’s desk), professionally-executed graphic design, and balance overall between your copy and imagery. Thank you for sharing this!

* For those of you who are students or interested in general in helping out with grassroots marketing projects, check out Spread Firefox and The Mozilla Blog to participate or just keep up with our adventures bringing Firefox to the world.

ShareThis

For the Record: Vietnamese Language Pack FAQ

Asa — 2008-05-09T05:39:49+00:00

Yesterday, Mozilla announced that one of the community built add-ons hosted by Mozilla contained remnants from a virus called W32/Xorer.A, also known as W32/Fujacks!htm.

After reading several dozen articles and blog posts covering that announcement, I thought I’d post a short a follow-up here in response to a few of the misunderstandings that I came across in some of those articles and blogs.

The Vietnamese language pack add-on contained a worm or virus
Headlines, by necessity, need to be short and to the point, but with security reporting, over-simplification can actually mis-inform readers.

Despite what many of the headlines suggested, the compromised add-on did not contain a worm or virus. There was a virus on the developer’s computer. That virus inserted a small website-fetching script into the add-on. That script was not capable of replicating or spreading itself like a virus or a worm. It was simply telling Firefox to load unrequested advertisements. Disabling the add-on is an effective remedy for the problem script precisely because it is not a worm or virus.
All or most Firefox users are affected because Firefox ships with support for all languages built in
This is not correct. Some computer programs that work in multiple languages contain all of the translations in a single version. That isn’t the case for Firefox. Mozilla ships a distinct Firefox version for each of the 45 supported languages. Vietnamese is not one of those supported languages yet so Firefox users who want a Vietnamese translation must seek out and install this Vietnamese language pack add-on. Only users who installed that compromised Vietnamese language pack were exposed.
16,667 Vietnamese language pack users were affected
While we don’t know what the exact number of affected users is, it is certainly less than that. The announcement mentioned that there have been 16,667 downloads of this add-on since November of 2007. That’s correct, but not all of those downloads were of the compromised version. The add-on was updated on February 18, 2008 and only those users who downloaded the February update of the add-on on were exposed.
Firefox users should uninstall Firefox and run their AV software to clean up the problem.
Because this isn’t a virus or a trojan, and it’s isolated to the Vietnamese language pack add-on, users do not need to uninstall Firefox or use third-party software to stop it. All they need to do is open the Add-ons Manager from the Tools menu and then select and disable the Vietnamese language pack.
Mozilla systems had a virus or worm on them
The virus was on the machine belonging to the add-on developer. The computers that produce and distribute Firefox were not exposed and were not responsible for the compromised add-on.
Mozilla suspected the add-on author of malice
Absolutely not. At no time did Mozilla suspect this and there is no reason to suspect or believe this.
Add-ons cannot be trusted
We scan all add-ons for viruses when they are uploaded to the Mozilla Add-ons website. This particular add-on contained the remnants of a virus that was still unknown to the anti-virus software performing that scan. As a result of this incident, we’re implementing additional vulnerability scans at regular intervals after an add-on has been uploaded to help mitigate similar problems going forward.

Add-ons provide a lot of value to a lot of Firefox users. We believe in that flexibility and power so we’ve invested heavily in infrastructure to host and support them and the amazing community that’s built them. Security is a key component of that investment and we take it very seriously when security issues come up with add-ons. Fortunately, this issue only affected a relatively small number of users, the impact to those users was not catastrophic, and the remedy was a simple three-click operation.

Going forward, we’ve got a better virus scanning solution in place and we’re looking into other ways to further insure the integrity and safety of all add-ons, not just those hosted by Mozilla.

More Reading:
Mozilla Security Blog » Compromised file in Vietnamese Language Pack for Firefox 2 by Window Snyder

Around the Web:
PC World » Firefox Plug-In Shipped With Malicious Code by Robert McMillan, InternetNews: The Blog » Don’t Run Mozilla Firefox in Hanoi by Sean Michael Kerner, Security Focus » Vietnamese pack infects Firefox users by Robert Lemos, SC Magazine US » Compromised file found in language pack for Firefox by Chuck Miller, Computerworld » Mozilla shipped worm with Firefox add-on by Gregg Keizer, heise Security UK » Firefox add-on contains malware by Mike Barwise, The Register » Firefox language pack provides adware back-door by John Leyden, PCMag - Security Watch » Vietnamese Firefox Distribution Carried Malware by Larry Seltzer, Wired.com - Threat Level » Firefox Infects Vietnamese Users With Trojan Code by Ryan Singel, ZDNet.com - Hardware 2.0 » Mozilla spreads malware rather than security by Adrian Kingsley-Hughes, Mozilla Links » Firefox Vietnamese language pack compromised by Percy Cabello, CyberNet News » Big Oops: Mozilla Releases Compromised Vietnamese Language Pack by Ryan Wagner, BetaNews » Vietnamese Firefox 2 users were given malicious content by Scott M. Fulton, III, Mashable » Mozilla: Would You Like a Virus With That Add-on? by Stan Schroeder, The Inquisitr » Viruses Hit Mozilla, MP3s by JR Raphael, FavBrowser » Firefox Security? Here We Go Again by Vygantas Lipskas, Donna’s SecurityFlash » Compromised file in Vietnamese Language Pack for Firefox 2 by Donna Buenaventura, On Computers Tips » Firefox Infects Vietnamese Users With Trojan Code by Jack Imsdahl , Infosecurity.US » Firefox’s Vietnamese Language Pack Reportedley Infected with Trojan by Marc Handelman, SANS Internet Storm Center » Compromised File In Vietnamese Language Pack For Firefox 2 by Joel Esler, CyberInsecure.com » Adware Back-door In Firefox Language Pack, Dantravels » Annoying Journalism from Robert McMillan, IDG News Service by Daniel Butler, The Good Soldier LMeyerov » Social Software by Leo Meyerovich, Tech-Ex » Firefox Language Pack Ships with Malware by Michael Santo, Spyware Sucks » Alert: Firefox 2 Vietnamese Language Pack infected by malware by Sandi Hardmeier, PortalIT News » Mozilla Warns: Firefox 2 Vietnamese Pack Features Trojan, IT Business Edge - Headline Watch » Mozilla’s Vietnamese Plug-In Infected with Malware by Susan Hall, McAfee Avert Labs Blog » Computer Security Research by Vinoo Thomas, ReadersZone » Firefox Vietnamese Language Pack infected with Trojan horse by Ajay Pathak, OpTempo » Firefox Vietnamese Language Pack Malware Warning by J. Frank Carr, Byzone » Firefox AddOn Comes with Adware by FyreVortex, Steve: Developing on the Edge » Virus in a firefox language plugin: the perils of the community by Steve Loughran

Dan Mosedale: Thunderbird 3.0alpha1 status: branch cut; candidate builds made; trunk re-opened

dmose — 2008-05-09T03:10:32+00:00

A release branch for 3.0alpha1 has been cut, so the mail/ and mailnews/ directories on trunk have been re-opened for checkins. Furthermore, there are now candidate builds at ftp://ftp.mozilla.org/pub/thunderbird/nightly/3.0a1-candidates/build1/ under test. Assuming the stars align, we hope to release alpha 1 early next week......

Mark Finkle: Firefox 3 - Offline App Demo - Part 2

Mark Finkle — 2008-05-09T02:56:54+00:00

Last year (wow, that long ago?) I made a simple demo to show Firefox 3 offline capabilities. A lot has changed between then and now. Firefox 3 offline capabilities changed significantly to align better with WHATWG offline specification. The biggest changes involve dropping support for our own <link rel="offline"> mechanism and supporting WHATWG manifests and application cache. The specification gives some details on how it works. There is an MDC article on using offline resources in Firefox 3.

Since so much has changed, I decided to update the demo application. Here is the overview of the application, updated where needed:

A Simple Demo - Task Helper

The application is a simple task list system. The current functionality includes:

Add tasks - Enter text in field and press ‘Add’
Complete tasks - Mark completed tasks and press ‘Complete’
Remove tasks - Mark tasks and press ‘Remove’
Data is stored as JSON and XHR is used to interact with server (PHP)

Nothing fancy. However, the application is “offline-aware”, meaning:

Application resources (HTML & JS) are listed in the offline cache manifest. This manifest must be served as “text/cache-manifest” and follow the manifest rules.
Before interacting with server, online status is checked. If online, use XHR. If offline, use DOMStorage.
Online/Offline status is monitored using events. When the application switches from offline to online, data is resync’ed with the server.

There is really nothing fancy about the offline stuff either, but putting it all together does make for a neat application. Using the latest Firefox 3 (beta 5 or nightly), you should be able to:

Use the application while online.
Go offline using the “Work Offline” menu. The event log should show that the app went offline.
Continue to use the application while offline.
Restart browser.
Switch to offline (or have no network connection).
Enter URL to app (or use a bookmark).
Start using app with data from last session.
Switch to online. The event log should show that the app is back online and has updated the server with any offline changes.

Try it: Task Helper
Source code: todo-offline.zip

Note: The data is stored in a simple, shared JSON file on the server, managed with a simple PHP file and reset every hour. No fancy databases with multiple session support.

Mark Finkle: A Little XPCOM Magic - JavaScript Callbacks

Mark Finkle — 2008-05-08T22:30:54+00:00

XPCOM is, currently, a core Mozilla technology. Developers use XPCOM for a variety of reasons, many of which result in XPCOM components being accessed from JavaScript. XPCOM uses IDL to describe interfaces. This can make XPCOM components a bit rigid and not feel right in JavaScript. Recent support for optional parameters in IDL has helped a little. Another helpful concept is using JavaScript functions in place of an IDL callback interface. For example:


[scriptable, uuid(...)]
interface StringParserObserver {
  void onWord(string word);
};

[scriptable, uuid(...)]
interface StringParser {
  void parse(string data);
  void addObserver(StringParserObserver observer);
};

In order to use this interface from JavaScript, you would have to implement the StringParserObserver using JavaScript. A nicer approach would be to allow someone to pass in a JavaScript function to use as the callback. The good news is you can! Better news is that it is a one line change to your IDL!

Just add the “function” attribute to the interface and XPCOM will handle the rest.


[scriptable,function, uuid(...)]
interface StringParserObserver {
  void onWord(string word);
};

There is a new MDC article with more details here.

John Resig: Processing.js

John Resig — 2008-05-08T21:50:43+00:00

Demos below!

As a sort-of reverse birthday present I've decided to release one of my largest projects, in recent memory. This is the project that I've been alluding to for quite some time now:

I've ported the Processing visualization language to JavaScript, using the Canvas element.

I've been working on this project, off-and-on now, for the past 7 months - it's been a fun, and quite rewarding, challenge. The full scope of the project can be broken down into two portions:

The Processing Language

The first portion of the project was writing a parser to dynamically convert code written in the Processing language, to JavaScript. This involves a lot of gnarly regular expressions chewing up the code, spitting it out in a format that the browser understands.

It works "fairly well" (in that it's able to handle anything that the processing.org web site throws at it) but I'm sure its total scope is limited (until a proper parser is involved). I felt bad about tackling this using regular expressions until I found out that the original Processing code base did it in the same manner (they now use a real parser, naturally).

The language includes a number of interesting aspects, many of which are covered in the basic demos. Here's a brief selection of language features that are handled:

Types and type casting - Type information is generally discarded, but becomes important in variable declaration and in casting (which is generally handled well).
Classes - The full class system is supported (can be instantiated, etc. just fine).
Method overloading and multiple constructors - Within classes you can have multiple method (or constructor) definitions - with the appropriate methods being called, based upon their signature length.
Inheritance - Even classical-style inheritance is supported.

Note: There's one feature of Processing that's pretty much impossible to support: variable name overloading. In Processing you can have variables and functions that have the same name (e.g. float size = 0; float size(){}). In order to support this there would have to be considerable overhead - and it's generally not a good practice to begin with.

If you're curious as to what the language looks like, here's a basic example of inheritance:

class Spin {
float x, y, speed;
float angle = 0.0;
Spin(float xpos, float ypos, float s) {
x = xpos;
y = ypos;
speed = s;
}
void update() {
angle += speed;
}
}

class SpinArm extends Spin {
SpinArm(float x, float y, float s) {
super(x, y, s);
}
void display() {
strokeWeight(1);
stroke(0);
pushMatrix();
translate(x, y);
angle += speed;
rotate(angle);
line(0, 0, 66, 0);
popMatrix();
}
}

The Processing API

The second portion of the project is the full 2d Processing API. This includes all sorts of different methods:

Shapes drawing
Canvas manipulation
Pixel utilities
Image drawing
Math functions
Keyboard and mouse access
Objects (point, arrays, random number generators)
Color manipulation
Font selection and text drawing
Buffers

Most of these are demonstrated in the basic demos.

There's pretty-good coverage of the Processing API: there's sure to be many gaps, but most of what I can throw at it works.

Download

The full source code is contained within a single file. It comes in at about 5000 lines, compresses down to less than 10kb.

processing.js
SVN: http://ejohn.org/code/processing.js/

How to Use

The API is quite simple - there's a single method "Processing". If you wish to only use the Processing API (not the language) you can interact with it like so:

var p = Processing(CanvasElement);
p.size(100, 100);
p.background(0);
p.fill(255);
p.ellipse(50, 50, 50, 50);

If you wish to have the full power of the language, as well, you would pass in your Processing code as the second argument.

Processing(CanvasElement, "size(100, 100); background(0);" +
"fill(255); ellipse(50, 50, 50, 50);");

That's really all there is to it. Information on the full Processing API can be found on the Processing.org web site.

Important: Browser Support

Before we get into the demos I want to outline what some of my goal was for this project. First, and foremost, I wanted to try and get the best Canvas-based demos out of a browser, as possible. This meant that I had to shoot directly for the latest, and greatest, browsers. I needed good Canvas API support and, importantly, I needed speed.

Because of this, for this first release, I've specifically targeted Firefox 3, the latest WebKit Nightly, and Opera 9.5. In other words: beta browsers.

A large part of the code base is sure to work in "older" browsers (Firefox 2, Safari 3, Opera 9, and IE with excanvas) - but that wasn't my target platform. I wanted something that would be capable of pushing the edge of what a browser is able to render - giving them something to strive for in their upcoming releases.

There were a couple of stumbling blocks that the above browsers hit:

Image loading - Currently, only Firefox 3 and WebKit Nightly handle this reliably.
Pixel processing - Loading pixel data from images, manipulating them, and putting them back on the canvas. Only Firefox 3 can handle this sufficiently.
Font loading and text rendering - The specification for this is still in the works, currently only Firefox 3 has support for this.

Thus, anything outside of the above (images, pixel processing, and text) should work "ok" everywhere.

Demos

NOTE: I highly recommend that you use the latest Firefox 3 beta to view the demos. Most will work in the latest WebKit Nightly and a majority will work in Opera 9.5, but all will work in Firefox 3.

Note again: A lot of these demos will peg your CPU. As I mentioned above, I'm trying to squeeze the most out of the browser, as possible - be ready for it!

What would the release be without a ton of demos? In development I worked in a backwards manner. Instead of building the API up from the ground - I worked from the top, down, implementing enough of the API to get individual demos working. The result of this is two-fold: 1) It made for a very rewarding development process - and guaranteed working demos and 2) It means that there are still portions of the Processing API left unimplemented.

Regardless - enough of the API has been implemented to allow all of the demos, available on processing.org, to work as best as possible.

Here's the full break-down of demos that are available:

I've gone through and cherry-picked a bunch that I really liked - in case you're interested in seeing some really interesting ones. Wherever possible I specify what browsers the demos work in (if none is specified, then it should work in all).

I'm quite curious to see what people construct with this new API. I think it holds a lot of potential and I'm excited to see what comes of it! Enjoy!

Remember: You should be using Firefox 3 or WebKit Nightly (Safari 3.1 is missing some features) - the above demos generally work best in those browsers.

J. Paul Reed: It's all about the Chases

2008-05-08T19:56:39+00:00

Maybe I only notice these things because Gerv has so religiously run the "n00,000 Bugzilla bug"-contests...

Or maybe it was randomly running across Wil's post about all of the web team's commits the other day...

Or maybe... it's just because I'm a dork about these sorts of things...

... buuut I was amused to realize the other day that here at the nest, we're due to hit the 10k mark on both bugs (I just filed bug 9087) and commits (changeset 9200 just went in).

I'm betting we'll probably hit 10k on both before 0.6 ships... although, I find myself wondering who will make it across the milestone first. Even though Bugzilla is behind at this point, I'm betting it'll catch up to commits before we ship.

Anyone bets on when we'll hit 20k?

(I was going to ask about the next-order-of-magnitude milestone, but... a Wilson party is probably a couple years away... at least.)

Bryan Clark: Searching for a new find

Bryan Clark — 2008-05-08T18:49:03+00:00

It’s time to start looking into a new search method for Thunderbird. One of the major changes planned for Thunderbird is a new and improve search, but what does that mean?

What do we have?

First lets look at what we have for a search system. At a very simple level most search systems break down into two pieces, a search interface for filtering and a results interface for listing. Thunderbird does this in a couple places.

Quick Search

The quick search entry is always at the top right of the Thunderbird window and allows people to search over the current view. The results of a quick search fill into the current view, replacing whatever listing was previously shown.

The Quick Search defaults to searching only the Subject or Sender and will only search mail that Thunderbird has downloaded already. Messages that are not listed in the current view (like in another folder) will not be searched unless that folder is selected, otherwise a person needs to use the Advanced Search.

Advanced Search

Hidden under the Edit Menu and Find Sub-Menu is an advanced search dialog that can make use of the remote mail or news protocol to perform a full search instead of just a local search. The Search Messages dialog provides it’s own search interface as well as it’s own results view directly below the search. While the Search Messages dialog provides some more advanced search methods over the quick search it’s hard to find and difficult to use effectively.

The Search Messages dialog allows for complex search queries to be built with multiple search terms composed of a number of different field type selectors. The queries require a lot of input from the user because of the tight structure used to create them. The same search and results interface code is used for creating mail filters.

Edit -> Find -> Search Messages…

Advanced Search Dialog

What do we want?

I was lucky enough to chat with Andrew Gilmartin yesterday and he framed a future goal very well. “We’re not looking to make search an added feature box on the side of Thunderbird“, we’re looking to make search the definitive method for viewing mail.

What does “Search as the definitive viewing method for your mail” mean? That’s a good question and I’m not sure exactly what a good answer is yet. A search would help you find the message you’re looking for, and perhaps a search view never lets you lose that message in the first place. There’s a lot to explore.

Here are two important pieces of a search system and view that need to be examined and somehow exposed in the interface.

Search and Filter

An impediment of the current search system is requiring people to choose a search type (Subject or Sender) before they even enter any text. To help people hunt for the correct item you want to allow for starting their search very broad and then allow them to narrow down that broad search with filters like subject or sender.

The current search system has some speed issues that likely prevented a broad to filter system of searching to be implemented. The mail client Mail.app provides a decent filter bar when searching mail that allows people to see what the current filters are (folder, account) and change them.

Browse and Filter

The SEEK extension is an excellent example of how offering a system of browsing mail by grouped attributes from the start can help people find the item or group of items they were looking for. Instead of starting with a search term you give the person a list of attributes they might use to filter the list of messages.

An inspiring system for a similar searching, browsing, and filtering methods is things, you should try it if you haven’t already.

Getting What we Want

Moving towards a new search based paradigm will take some adventurous steps and it’s important not to disturb current usage while making those steps. Here are a number of changes to look at making.

Merging Search Interfaces

Each of the two current search interfaces provide some needed features and capabilities, however having two separate interfaces for searching is confusing and difficult to understand. We need to combine the ability to do a quick search with the ability to perform a full search into a single interface with an improved results view.

With a single search interface Thunderbird will be searching the local and remote mail (like IMAP) at the same time. However local results will be listing quickly and remote results will likely take a little more time. Both sets of results, local and remote, can be merged into the same search results view by showing local results instantly and filling in remote results as they arrive.

Offline Cached and Indexed Mail

In order to have a fast search system even while offline Thunderbird needs to do a much better job of caching and indexing mail as it encounters it. With new messages instantly cached and indexed they can be made available to search queries, filters, and views immediately.

This is an excellent time to start thinking about the data mining mail in a way that helps searching messages later. It’s also time to think about making the defaults tuned towards offline usage while still allowing people to control online / offline caching.

Auto Complete

With mail data indexed locally and quickly available Thunderbird should be able to provide a slick and fun auto-complete on search terms it knows about. Auto complete when searching for items you’re already aware exists helps with miss-spelling errors and more complete matching. The awesomebar shows how with just a little broken memory of a title or url you can easily find the page you saw once before.

Fetching Results

Our current drive is to investigate some indexing on messages (at least subjects), pull the new auto-complete into Thunderbird, and get a search bar using that fancy auto-complete on mail subjects and hopefully the addition of a couple more fun things. Leave some comments or jump on the newsgroup to participate.

A wire frame of a possible mail search auto-complete

John O'Duinn: We have how many machines…. and whatdy mean, its not enough?

John — 2008-05-08T18:27:09+00:00

While the sheer number of machines in my previous post surprised all of us, its more interesting to note that its not enough. Its simply just not enough. Even today, we’re constantly under the gun, bringing new machines online as fast as possible.

The 30 machines marked idle/waiting-to-mothball will all be recycled and used for blocked projects that need machines.
Justin’s group recently brought another VMware host online, and built out extra disk space so we have space to create 30+ new VMs - 6 new VMs are coming online this week, additional to whats listed in previous blog.
We’re ordering another batch of 80 mac minis, as we’ve already used up the previous batch of 50 minis, after we used the initial batch of 30 minis.

We hope its enough machines for a while.

Never mind the cost of all these machines. Pretend they were all free.

All of these machines need rented colo rack space, network bandwidth, electricity, a/c, humans to install and support them, humans to configure them up and bring them online. In a ripple-on effect, the more builds we produce, the more diskspace and infrastructure we need for ftp, downloads, virus scanning, tinderbox servers, etc.

Thats just to have them come online. Then starts the human time for the constant care and feeding that each of these unique individual machines need. For one or two machines, its easy. When you look at 200 machines, and then an additional 150 or so machines, its a no-brainer that this approach does not scale.

Jane Finette: Tristan, Firefox 3 and the BBC’s dot.life blog

jfinette — 2008-05-08T17:27:56+00:00

Last week Tristan was in London talking at Internet World in London, he keynoted there on “The dangers of the proprietary web - Future of Internet and Open Source”. Whilst in the UK, where it poured incessantly the whole time, Tristan was able to meet blogger legend Rory Cellan-Jones. Rory is the BBC’s technology correspondent and writes for the Beeb’s tech blog dot.life. He interviewed Tristan on open source, the background of Mozilla and of course the word on everyone’s lips - the new Firefox 3.

Read the article here and also see Rory’s video of Tristan’s Firefox 3 demo.

Fab comments as well.

Just Browsing: The Trouble with Google Docs (And How to Fix It)

Matthew Gertner — 2008-05-08T17:08:08+00:00

I’ve been obsessing recently with configuring my home office software environment just so. Since I went all Apple, all the time, I’m able to benefit from a lot of goodies that are built into OS X (notably iTunes). And developing on Mozilla means that I can do pretty much everything from the command line, using XCode as my editor (which gets me zero hacker cred but works just fine). I never touch a spreadsheet if I can help it, and if I don’t have to make another Powerpoint-style presentation ever again I don’t think my psyche will suffer in the slightest. So my computers lack an office productivity suite that would sully my Microsoft-free lifestyle or force me to install that lumbering beast that is NeoOffice.

This delicate karma was shattered the other day when I needed to bang out an invoice for my customer. Rather than succumb to the siren call of office bloatware, I decided to give Google Docs a spin. What could be cooler than a free, lightweight web wordprocessor, I thought. Unfortunately the experience proved to be a deep disappointment.

Some issues were relatively trivial. For example, the clipboard commands don’t seem to work on Mac and kept prompting me to use the operating system’s keyboard shortcuts. Annoying but not showstopping. Much more serious was the table management, which is atrocious. I kept bumping into a bug that prevented me from adding normal text underneath my table; it just wanted to tack on additional rows. Resizing columns is a total nightmare and getting the text in the columns to line up properly went beyond the nightmarish into the realm of sheer horror. When I went to export my document as a PDF, it in no way resembled the “WYSIWYG” of my actual document. I spent what seemed like hours (and might actually have been hours) tweaking and exporting in a soul-sapping orgy of trial-and-error until I got something that vaguely resembled a professional-looking result.

So now I know why Google Docs hasn’t encroached more significantly on Microsoft’s turf: it kind of sucks. Don’t get me wrong, I don’t need or want the zillions of bizarre features that traditional shrink-wrapped vendors insist of pushing on users in order to drive revenue from useless “upgrades”. But something as basic as table management should just work, and the exported output should look like the original document, dammit. Concerns about the dismal state of browser-based editors are not new, of course. Clay Shirky was frothing at the mouth years ago over the lack of auto-save (though modern web apps seem to handle that pretty well), and I’ve whinged at length about various other aspects of the same issue myself.

Luckily, Google has a weapon in its arsenal that is perfectly suited to addressing this problem: Gears. Gears honcho Aaron Boodman blogged recently about Google’s ambitions for the product. Basically, the idea is not to replace existing existing browsers or preempt nascent standards. Instead, it is a platform for providing missing functionality in a cross-browser manner while vendors and standards catch up. So how about it, Google? A really kick ass editing component for Gears would fill a gaping hole in current browser feature sets and give Docs a fightly chance of competing effectively with its desktop-based counterparts.

Eric Shepherd: Firefox 3: Why do I love thee? The second way.

sheppy — 2008-05-08T13:00:08+00:00

I’m a forgetful guy. As I opened up WordPress to write this blog post, during the few seconds it took to type in the post’s title, I forgot what I was going to write about. That’s how forgetful I am.

Now that I’ve remembered, after about 30 seconds of scratching my head, I realized that anecdone would be a good way to start talking about the second way I love Firefox 3.

As a guy that quickly loses his train of thought (usually loudly, and into a river at the bottom of the ravine underneath a missing bridge), anything that interrupts my workflow is a bad thing. Firefox 3 does away with a number of things that used to interrupt me.

One of the big ones is the new way Firefox asks if I’d like to save a password. Instead of popping up an incredibly distracting modal dialog box, an unobtrusive strip appears at the top of the browser offering to save the password:

I can keep on working, and deal with the password issue at my leisure. Usually when I log in, there’s something I need to look at or write up quickly before I forget to deal with it, so this is a huge relief for me.

Another big help for my addled brain is this: I often get (via mail or IRC) links to web pages including content I need to deal with. Sometimes it’s an article I need to edit, sometimes it’s something I need to read. Often it’s just something I need to refer to while I do other work.

And, often, I don’t have time to deal with it right away. So I leave the tab open, waiting for me to be ready to deal with the material.

Sometimes these tabs stay open for weeks.

And eventually, for whatever reason, I’m guaranteed to have to quit Firefox.

Firefox 3 — joy of joys — remembers all my tabs and loads them right back up for me when I start it again. No more having to bookmark every single page I might ever have to find again. I can quit and restart at my slightest whim, safe in the knowledge that I won’t lose some important thing that I need to deal with… someday.

Calendar: [May 8, 2008] Lightning/Sunbird Status Update

2008-05-08T12:04:25+00:00

Only three days after the last status update, it's already time for another as the developers have fixed lots of bugs (19) in the last three days.

The most notable fixes are in the area of iMIP/iTIP (sending and receiving e-mail invites) with the fixes for bug 377761 (better compatibility with earlier Outlook releases) and bug 429938 (support for meeting cancellation).

Here's the list of all the 19 changes within the last three days:

Bug 202360:
Color Coding of Tasks and Events (multiple classification)
Bug 322979:
Views should not scroll the labelling columns along the non-scrolling axis
Bug 368976:
Cannot undefine alarm for an exception
Bug 377761:
Outlook 200x does not recognize iTIP/iMIP invitation because of MIME type issues
Bug 397896:
Sync default snooze between Sunbird and Lightning
Bug 397913:
Add tooltips to the miniday buttons
Bug 401693:
Today pane not updated on Mac OS X after hibernation
Bug 426746:
Consolidate startup code
Bug 427006:
Timezone offset incorrectly calculated for negative half hour timezones
Bug 428715:
Between 23:00 and 00:00, the default event start date is 00:00 of the next day
Bug 429938:
No cancel message is send to attendees if event is deleted
Bug 430254:
Add interfaces to GData for UI code
Bug 430805:
Permit to change the default free/busy attribute policy for all-day events
Bug 431829:
Moving Today Pane button on Task toolbar removes it from Calendar toolbar
Bug 432218:
Remove TB 1.5 specific code in getMailBar() function
Bug 432499:
Duplicate id in calendar.xul
Bug 432703:
Changing month with scroll wheel throws error
Bug 432793:
Get rid of "move" transaction type
Bug 432794:
Allow loading chrome scripts in test cases

Many thanks go to all developers, contributors, localizers, testers, and supporters that made and make this possible.

Mark Banner: Thunderbird Test Day

Standard8 — 2008-05-08T10:55:23+00:00

Today is the first Thunderbird test day using the potential Shredder Alpha 1 builds. Find out more about the test day here.

Having been working on various bits of Thunderbird’s Core MailNews code (and some of the specific code as well) since the Mozilla 1.8 branch was originally cut, it is exciting to be getting close to releasing the first alpha since the last major release. Whilst there is lots more work to do to get us to the final, its the first big step in the right direction.

So, please do come along and help us test the alpha candidates. The more testing we get, the more confidence we’ll have in the candidates (assuming no failures!), and feedback will help us learn where we need to improve for the next alphas, betas and the final.

Eric Shepherd: A complicated day

sheppy — 2008-05-08T08:01:10+00:00

Today (that is to say, Wednesday) didn’t go the way I planned. Right about the time I was planning to go run the errands that I needed to get done, I was overcome by weakness all over and wound up headed to the emergency room for the second time in as many weeks.

It was an interesting experience. I was so shaky and weak when I got there that they rushed me back to a room almost immediately, and got me hooked up to monitors. When they were reasonably sure that I wasn’t about to keel over, things slowed down a lot. Took over two and a half hours for a doctor to see me, and he spent about two minutes with me.

He ordered up some tests — which took over 45 minutes to get started. Then we waited around two more hours for the results, which came up that I was totally fine — which, by then, I was.

The diagnosis: I still need to work on my fluid intake.

Unfortunately, after spending almost six hours at the hospital, it was no longer really feasible to get my errands done — which means they’ll have to be done tomorrow. I expect to do them in the morning, so I may get a late start working tomorrow (er, today, I guess, technically).

Melissa Shapiro: The slow death of the press release

melissa — 2008-05-08T07:26:31+00:00

People often ask me why Mozilla doesn't put out more press releases or why the releases that we do put out are relatively short and news-driven. I then proceed to pull out my PR soapbox and spout off about the changing face of media and the need for PR to adapt beyond methods that are at best unproductive, and at worst detrimental to the entire industry. That's good for drunken debates at PRSA events but not quite palatable for everyone. When I'm talking to non-PR people, I typically illustrate the concept by telling a story about my early days in PR.

In 1999, I was an intern on the Tech, Telecom, and Energy team at a global PR firm's DC office. Part of my job was to fax press releases to editorial teams at newsrooms nationwide. I would spend hours punching in the phone numbers of major newspapers and publications for a fax blast (anyone remember those?). I later heard from reporters that at the other end of the transmission, they had the incoming faxes feeding straight into a garbage can. They would use the discarded press releases as scrap paper.

I love this story for two reasons. One, it explains the immediate failing of the press release; pushing news to people without any context or expressed interest is ineffective. Two, it illustrates the ever-changing face of media and the need for PR to adapt or get sucked into the newsroom garbage can (or its modern equivalent, the editor's spam folder).

Back in October, Chris Anderson of Wired and Long Tail fame, posted a scathing indictment of the PR industry. His complaint? Being blasted with news that he didn't request and wasn't interested in receiving.

I've had it. I get more than 300 emails a day and my problem isn't spam (Cloudmark Desktop solves that nicely), it's PR people. Lazy flacks send press releases to the Editor in Chief of Wired because they can't be bothered to find out who on my staff, if anyone, might actually be interested in what they're pitching.

I am certainly not the first person to assert that the golden age of the lengthy mass-blast press release was coming to a close. Flickr has long been a leader in the movement to move PR beyond the press release. In early 2004, they began blogging their announcements in lieu of a traditional wire release. Tom Foremski wrote a post about this in 2006 but the progress has been slow. Two years later, social news releases are starting to gain traction but they tend to look like deconstructed versions of standard news releases.

Perhaps we are in the Web 1.0 phase of the press release. When corporate content first appeared on the Web, most companies modeled their online presence after offline norms. Businesses took their existing marketing materials and simply put them online. Mainstream media did pretty much the same thing with early online news sites. Today, the Web has progressed far beyond that. Offline ported to online does not equal Web presence. Considering this, how do we advance our understanding of PR?

At Mozilla, when we put out press releases they are often coupled with blog posts and/or FAQs in order to provide context or quick fodder for right click journalists looking for a quote. They offer a voice, a perspective, a point of view. Traditional press releases, by nature of their construct, simply cannot compete with the rich, interactive experience of the Web.

The PR industry needs to revisit the concept of the next generation press release more than once every few years. Media is always changing. PR needs to keep pace or it will go the way of fax blasting: still around but completely out of touch with the modern era.

John O'Duinn: We have how many machines?

John — 2008-05-08T07:20:55+00:00

As best as I can tell, it looks like we have the following machines running on each branch:

02 machines for 1.8.0
+ 29 machines for 1.8
+ 88 machines for 1.9/trunk
+ 33 machines for moz2
====
152 machines in use today
+ 10 ref-images
+ 30 machines idle/waiting-to-mothball
====
192 machines total

1) These numbers do not include any community machines yet. We’re still working on this.
2) The 88machines on 1.9/trunk are made up of 40 builder, 23 unittest and 25 talos machines.
3) Most of those 30 machines marked “idle/waiting-to-mothball” were only discovered during this housekeeping. Some of these now have bugs to track mothballing and being recycled… we’re still working through the list. It was interesting to find out how many people were still using machines that they thought were supported, but which we did not even know existed, or which we thought were long desupported!
4) Its taken weeks to collate this data, and I’m still not certain we’ve identified everything. We need a central list that can be the single-source-of-truth for all these machines. Instead of doing this on various wiki pages, we’re talking with Justin, mrz and Jeremy to see if we can use the same asset tracking db they use when they install machines into the colo. That would work much better for this, but need some customization. Stay tuned…

We’re still gathering more info…to be continued in another blog post.