Canon EOS 40D, Canon 17-40mm ƒ4, tripod
I know it’s early, but sometimes you have to seize the day (carpe diem!)
On Flickr there’s also a partial desaturated version of the same photo.
Technorati Tags: fotografia, firefox, wallpaper
Canon EOS 40D, Canon 17-40mm ƒ4, tripod
I know it’s early, but sometimes you have to seize the day (carpe diem!)
On Flickr there’s also a partial desaturated version of the same photo.
Technorati Tags: fotografia, firefox, wallpaper
←
→
I put together a demo of incrementing numbers in URLs by scrolling.
Hopefully it's not considered a bug that I can use rangeOffset for a text node "inside" a textbox ;) Trying to access rangeParent throws a security exception.
This could be used by an extension like URL Flipper as a shortcut for changing specific numbers in URLs.
Bit of a weird week – very busy, but not a lot of coding.
Related posts:
This week brings a boost in visibility of results, not just for startup, but for all the performance testing we’re doing on all branches and platforms. As I mentioned last week, I was working on an automated method of generating the cross-branch startup results. Luckily Johnath and Chris Atlee had done the hard work when making the performance dashboard. It has a JSON file that contains a roll-up of the previous 7 days performance data, which is updated every 5 minutes with new Talos results. Using that as the datasource, I wrote a script summarizes the results for each test+branch+OS combination across all the boxes that returned results, as well as stable branch and previous week differences. The final product gives a snapshot view of how each branch compares to the stable branch.
This is useful for a few different reasons. First, we (and the press and our users and our managers and everyone really) are able to know at-a-glance how any branch compares to the stable release branch. An example of another use is that before the JS team does a Tracemonkey merge, they can quickly see if any major performance effects can be expected.
The table shows red or green for any differences that are outside of a 2% threshold, to take test noise into account. This is quite liberal, as I’ve already calculated the numbers to take into account whether the difference is within the standard deviation. Reducing the noise in the tests would be a big help – perhaps some researcher will take up Roc’s challenge. A second point of trust is my math
I’m not a statistician, so please view source and let me know where I’ve miscalculated.
An example of the full report is here. I’m going to file a bug and work with release-engineering to get it pushed out to the graph server, where the dashboard lives. The data from this week’s startup table is copied below (though sans the color-coding of the real thing. Actually, now WordPress keeps stripping out my styles, so you get an ugly table this week).
| Firefox3.5 | Firefox3.6 | Firefox | TraceMonkey | |
| Leopard | median: 1469
deviation: 110 mean: 1481 from last week: 2% |
median: 1115 deviation: 59 mean: 1096 from last week: 3% from 3.5: 26% |
median: 1036 deviation: 48 mean: 1006 from last week: 1% from 3.5: 32% |
median: 1014 deviation: 38 mean: 1000 from last week: 0% from 3.5: 32% |
| Linux | median: 625 deviation: 7 mean: 626 from last week: 0% |
median: 632 deviation: 7 mean: 633 from last week: 0% from 3.5: -1% |
median: 619 deviation: 10 mean: 623 from last week: 1% |
median: 628 deviation: 7 mean: 628 from last week: 0% |
| Vista | median: 538 deviation: 8 mean: 540 from last week: 0% |
median: 533 deviation: 13 mean: 537 from last week: 1% from 3.5: 1% |
median: 503 deviation: 23 mean: 509 from last week: 0% from 3.5: 6% |
median: 511 deviation: 41 mean: 531 from last week: 11% from 3.5: 2% |
| XP | median: 461 deviation: 6 mean: 461 from last week: 0% |
median: 464 deviation: 6 mean: 464 from last week: 1% from 3.5: -1% |
median: 448 deviation: 7 mean: 448 from last week: 0% from 3.5: 3% |
median: 530 deviation: 38 mean: 501 from last week: 10% from 3.5: -9% |
This week’s activity:
Projects in a holding pattern:
As usual, more details and links are available on the project wiki, and we’re available to answer questions in #startup on irc.mozilla.org.

Nearly 3 month after we have released Mozmill 1.2 we are close to our next release of Mozmill. Lots of bugs have been fixed and even a couple of new features were implemented. A nearly complete list you can find on Bugzilla.
Everyone who is using Mozmill regularly is welcome to help us in testing the beta version. As long as no big issues will come up the release of Mozmill 1.3 will happen next week.
If you want to test the extension please download it from Github.
Users of the pyPI packages only have to run “easy_install -U mozmill” to get the latest packages for Mozmill, JSBridge, and Mozrunner.
Thanks in advance.
gietfirebug.com has Firebug 1.5b3. This is 1.5b2 with a couple of fixes. It passes all tests on Firefox 3.6b2 and does not crash in Firefox 3.7 nightly. Two tests fail in Firefox 3.7. One is a change in an error message; the other is some mystery message we need to ask mozilla platform folks about.
jjb
Last week I was in Canada to present at FSOSS with David Humphrey on awesome Mozilla Tools: Dehydra, DXR, Pork, etc. I think we managed to convey the message regarding what a sad affair that current developer development tools are.
General-Purpose Dehydra Scripts
Dehydra grew out of Mozilla’s constant need to figure out what is going on in the source code. As a result most of our scripts are very Mozilla API-specific. This makes harder for people outside of Mozilla to learn Dehydra. There is no library of Dehydra code that one can just plugin to start analyzing their codebase. Instead one has to sit down, figure out what Dehydra is capable of and then see if any of the problems facing the developer can be solved this way. If anyone wants to contribute such a library, let me know.
In the meantime, more general-purpose analyses are surfacing.
Shadowed Members
My favourite script so far is the member-shadowing checker. I ran into a member-shadowing warning that is unique to Sun’s C++ compiler. It was triggered by some code that I just landed on the tree. I fixed the warning, but within a few days a coworker ran into a bug caused by that member shadowing(due to having an unlucky revision of the code). The following example shows how simple it was to implement the warning in GCC/Dehydra.
<iframe height="300" src="http://people.mozilla.com/~tglek/shadow.html" width="95%"></iframe>
See bug 522776 for the complete story on adding the member shadowing check to Mozilla.
Printf
Another general purpose analysis was done outside of Mozilla by Philip Taylor for his game. His script checks wide printf format strings (which are overlooked by gcc).
Independently, Benjamin wrote a printf checker for Mozilla printf-like code, see bug 493996.
Custom Sections in Object Files
We have long speculated about how nice it would be if Dehydra could emit info into object files that could then be yanked out of the resulting binary (by say, valgrind). bug 523435 will soon make that a reality.
WebGL introduces two interesting concepts that I think have application outside of WebGL, the CanvasArrayBuffer and CanvasArray. This is all subject to change, of course, though this is what the current Gecko (and others') implementation looks like. In particular, the Canvas prefix in the names might change soon.
It became clear that pure JS arrays are not a useful way of shoveling around lots of 3D data; their very flexibility makes them impractical for performance-critical uses. In particular, WebGL often wants to deal with arrays of a specific type -- an array of integers, an array of floats, etc. Even more complicated is the need to manage multiple types within a single memory region; for performance, it's often preferable to allocate one chunk of video memory, and place coordinates, colors, and other types in there, replacing them as necessary.
There are two portions to the solution: the CanvasArrayBuffer and a set of typed CanvasArray views. A CanvasArrayBuffer represents chunk of data. It can be allocated with a size in bytes, but it can't be accessed in any way. To actually manipulate the data inside a CanvasArrayBuffer, a CanvasArray has to be created that references it. An example:
var buf = new CanvasArrayBuffer(3*4); var floats = new CanvasFloatArray(buf); floats[0] = 12.3; floats[1] = 23.4; floats[2] = 34.5;
The above chunk of code allocates a 12-byte CanvasArrayBuffer, and then creates a float-typed view onto the buffer which can then be manipulated (almost) like a normal array. Of course, the above is cumbersome to write, so there are shorthands that will allocate a CanvasArrayBuffer, and optionally fill it with data from a JS array:
var f1 = new CanvasFloatArray(3); var f2 = new CanvasFloatArray([12.3, 23.4, 34.5]);
The size of each CanvasArrayBuffer is fixed; there is currently no way to change its size once allocated.
Multiple CanvasArrays can reference the same CanvasArrayBuffer. For example:
var buf = new CanvasArrayBuffer(12*3*4+12*4); var points = new CanvasFloatArray(buf, 0, 12*3); var colors = new CanvasUnsignedByteArray(buf, 12*3*4, 12*4);
This creates a buffer of 192 bytes, which is enough room for 12 3-coordinate float points followed by 12 RGBA colors, with each component represented as an unsigned byte. The arguments to the CanvasArray constructors are the offset from the start of the buffer (in bytes), and the length (in elements). The offset must always be a multiple of the element size (to preserve alignment), and the buffer must obviously be large enough for the given offset and length. If length is not given, the length is assumed to be "from offset until the end of the array buffer"; that value must be a multiple of the element size. If offset is not given, it's assumed to be zero.
For extra complex use cases, CanvasArrays can reference overlapping regions of a CanvasArrayBuffer:
var buf = new CanvasArrayBuffer(192); // same value from above var points = new CanvasFloatArray(buf); var colors = new CanvasUnsignedByteArray(buf); points[0] = 12.3; points[1] = 23.4; points[2] = 34.5; colors[12] = 0xff; colors[13] = 0xaa; colors[14] = 0x00; colors[15] = 0x00;
In the buffer, this writes 3 float values followed by 4 byte values. You'll note that this use is significantly more complex, and requires the user to keep track of the current position in terms of whatever element they're modifying (thus setting array elements 12, 13, 14, and 15 for the color).
If an attempt is made to store data in a CanvasArray that doesn't fit within the right type, a C-style cast is performed. If the data is an entirely wrong type (e.g. trying to store a string or an object), Gecko currently throws an exception, but this might become a silent 0 or similar in the future.
Where does this fit in WebGL? Any API function that needs an array of data takes a CanvasArrayBuffer. This avoids placing costly JS array type conversion in a potential critical performance path, and simplifies a number of aspects of the API. So, VBOs, texture data (if not loaded from a DOM image element or from a CanvasImageData object), index array, etc. all use CanvasArrayBuffers/CanvasArrays for pulling data in and out. CanvasArrays also help manage memory usage -- an array of byte color data now takes up exactly as much memory as needed, instead of getting expanded out to 4 bytes. Also, critically, floating point data can be stored as 32-bit single-precision floats instead of 64-bit doubles, taking up half as much space when the underlying graphics system can't support 64-bit values.
This API is overall lacking in developer niceties, since the focus was on providing the necessary functionality. Higher level wrappers can be written in JS to simplify usage. In addition, by keeping it as bare-bones as it is, it allows for fast implementation on native hardware via the JITs in all the current-generation JS engines. The web currently fudges around the problem of binary data by passing it around either in strings (because JS strings are UCS2, therefore all 8-bit elements are valid, but with a performance and memeory cost), or often encoding as base64 (again going back to strings). I can see this type of dense/native type access being useful for both the File and WebSockets APIs as a way to exchange and deal with binary data.
Summary:
Here’s how it looks compared to the year so far:

Detailed breakdown is :

Here’s how the math works out:

The types of build, unittest and performance jobs triggered by each individual push are best described here.

If you live in Austin and want to know how to build Firefox Add-ons, the next meeting of Refresh Austin is going to have Mark Phillip giving a talk on building add-ons for Firefox and Fennec. Mark is responsible for the RUWT? Sports Toolbar.
You can RSVP on Facebook.
I’ll be there.
During the lead up to the Firefox 3.5 release, there was a request to have older machines running unit tests. Our solution for the 3.5 release was to burn Ted cycles. This is unfortunate because Ted could have otherwise done much more useful things. For the Firefox 3.6 release, we automated this testing. The reason for running these tests is that our JavaScript interpreter spits out native machine code . The problem is that there are still machines capable of running Firefox but do not have all of the latest instruction sets(MMX, 3DNow, SSE2, SSE3, ad infinitum). Specifically, there was a concern over the inclusion of the SSE2 instructions when running on non-SSE2 capable hardware. This is especially important for those people who are still running an older machine exclusively for browsing. It is very important that we don’t unknowingly introduce a requirement for SSE2. We also need to test our claimed compatibility with older Macintosh machines based on the PowerPC core. To fix this situation, I have created the geriatric master. This master is in charge of our fleet of aging fleet of Pentium 3s and PowerPC G4s. It reports to the GeriatricMasters tinderbox. I currently am monitoring the Mozilla 1.9.2 and Mozilla Central nightly builds.
We are running some old machines saved from the Landings to Castro move. The P3s are around a decade old and the G4 Mac Mini and Dual G4 PowerMacs are about 4-5 years old. We also aren’t running matched hardware which is going to make detective work on failures difficult. I have found some machines to replace our mixture of P3s that do not even have SSE. They are based on the AMD Geode LX800 processor. These machines are what the OLPC XO have as a cpu. Because they are based on an ancient CPU core (Cyrix 5×86, technically a 486), they even lack SSE. That makes them the perfect for our testing. The model that I am looking at is the MSI Fuzzy. I don’t really understand their naming, but this machine would fit our needs perfectly. It has a fast (for the category) processor and slots for 1gb of ram. Most importantly, it allows us to have as many identical machines as we need. The Mac Mini is easier to standardize on because it was fairly popular at the time and there are only one or two minor variations of the PowerPC Mini.
Before we go rushing out and buying a bunch of new machines for this testing, we need to know how long there will be demand for this kind of testing. I would estimate that it would cost about $500 per Geode machine, and that we might be able to get nightly coverage on two to three branches on linux and windows with four machines.
Also of note is that because we are running on such old hardware, we are getting JavaScript timeouts. I don’t really know how to manually set the preference that ignores these timeout warnings, but it is causing a lot of the jobs to be killed off because they aren’t responsive. I’d love to know if you know how I can disable this in an easy to automate way. I was thinking that I could launch and kill Firefox to create a profile, modify the profile’s preference file then launch it again for the real tests. I don’t know which preference file I would need to do this on though.

This is where I’d like to ask people who are working on the JavaScript JIT to let me know how long we need to do this testing and whether this current coverage (mozilla192 and mozilla-central) is enough. A comment on this post, bug 463262 or ping me on #build (jhford).
As a side note, this configuration makes it possible for us to run unit tests on second tier support machines and operating systems. If there is any community interest, I can look making it possible for anyone to connect their machine to this buildbot master if they have an obscure machine with spare cycles. This would require you to be able to dedicate the box for this testing, us to already produce builds that run on that architecture.
If anyone wants, I can get some photos of the machines on Monday.
Last year, Mozilla participated in the first ever Add-on-Con conference for add-on developers and enthusiasts, and it was a huge success. When we were told there would be another Add-on-Con this year, we were excited to get involved again.
This year, Add-on-Con will be on December 11 at the same location, the Computer History Museum in Mountain View, California. A number of Mozilla folks will be in attendance and leading sessions, including:
We’ll also be participating in the closing keynote panel, Future of the Browser. Expect more details on these sessions in the near future, as the schedule gets finalized.
Registration is now open, so if you’re interested in browser add-ons, whether from the technical or business side, it’s a great place to learn about what’s coming, what’s already being done, and networking with browser vendors and other add-on developers.
Building an add-on for Fennec (mobile Firefox) can be a bit tedious. We release desktop versions of Fennec that allow developers to test and play with their add-ons without the need for a mobile device. However, there are a few things that the desktop versions of Fennec do not expose: Performance characteristics of running on a mobile device; and the affect of small screens and high DPI.
I have blogged before about the potential performance issues and we have created some documents to help developers watch out for problems. I’ve blogged about mobile screen sizes before – about how you can use CSS to handle different sizes and orientations. This time I wanted to make the point about images sizes and the effect of DPI on fixed sized images.
On the desktop version of Firefox, 16px images are used for many of the UI elements. The trend in mobile device screens is big screens and high DPI. The DPI on desktop monitors has been below 100 for many years. Recently, we are finding monitors and laptops with higher DPIs. However, mobile devices can have displays with above 200 DPI, some even hit 300 DPI. Even the crappy iPhone display has 160 DPI. Using a 16px image on a 200 DPI (or greater) display will look tiny. It also has usability problems if the image is part of a touchable element. Fennec tries to keep touchable UI elements at ~ 6mm.
With the DPI issue in mind, add-on developers should really never use 16px images unless you are sure Fennec is running on a low DPI device. The Fennec UI uses 32px images for all favicons, list images and button images on high resolution screens. You can use the same CSS media queries I blogged about to control the images used in your UI:
/* high-res screens */
@media all and (min-device-width: 401px) {
#myimage {
list-style-image: url(chrome://myaddon/skin/images/cool-image-32.png);
}
}
/* low-res screens */
@media all and (max-device-width: 400px) {
#myimage {
list-style-image: url(chrome://myaddon/skin/images/cool-image-16.png);
}
}
You should not hard-code image URLs in XUL. This is considered bad practice:
<image src="chrome://myaddon/skin/images/cool-image-16.png"/>
Also note that the Fennec CSS is designed to stretch some element images to 32px. If you use 16px images for things like favicons or search providers, the result will be a pixelated mess.
Back in the mists of time I wrote some code to make nightly testers’ lives easier by giving them a simple preference to flip if they wanted to be able to install and use incompatible extensions. It’s been more than three years since then and the use of this preference has grown beyond its original use. It is now something recommended to regular users everywhere from forums to comments in news articles as a way to use their extensions in the new major Firefox releases.
Don’t get me wrong, letting users upgrade sooner than they otherwise might is a good thing, but the preference is a dangerous beast. It is pretty simple for a user to set the preference and then forget about it leaving them able to install incompatible extensions that break their Firefox without realising it. This costs Mozilla time as well since we get quite a number of bug and crash reports to look at that turn out to be caused by extensions that are dutifully marked incompatible with the user’s Firefox.
We’ve been mulling over ways to change this for a while but now we’ve actually gone and done something about it. We still want nightly testers and early adopters to be able to use incompatible extensions if they need to but we also want to make the preference not be a one shot deal that lasts till the end of time. The plan we’ve come up with is to change the preference’s name with the Firefox version, so for Firefox 3.6 (and all security releases) the preference will be extensions.checkCompatibility.3.6. When switching to a future 3.7 testers and users will have to set a new pref extensions.checkCompatibility.3.7 to say they still accept the risks of running with incompatible stuff.
Nightly users will have to make the changes slightly more often since the preference will also track whether the version is one of the development alphas or betas, so for the 3.6 betas the preference would be extensions.checkCompatibility.3.6b, for the current trunk extensions.checkCompatibility.3.7a. These are just normal preferences of course, if you frequently switch between different Firefox versions you can just set both necessary preferences. The change should land on the trunk in the next day or so and then the 3.6 builds a day or so after that.
There is just one oddity, if you’re testing nightlies and you update to a build with the change then you likely won’t notice any of your extensions disabling themselves, that won’t happen till either you toggle the pref or you switch to a build with a different Firefox version number in it.
It has been almost 2 months since my last post and I have been heads down on bringing a new framework to life.
I discussed the 4 pieces involved in bringing automation to a new platform, and now we have what is shaping up to be a great approach for resolving the infrastructure and harness development.
What we have is a device specific agent which is written in a native language (C/C++) and does a small number of things (launch process, collect output, copy files to and from, query status such as processes, memory, cpu, disk, and lastly identify the device and os). This tool needs to act as a telnet server allowing us to telnet to it and execute a series of commands. Brad Lassey has developed such a tool for WinMo/CE which works partially on Win32 as well. I spent a couple days testing this interface and hammering out a python library to interact with a remote device. Now scripting file copy and process launching is easy. Clint has also used this tool to get mochitest and xpcshell running on Windows CE based devices!
That takes care of most of our infrastructure, now we need to get this stuff working on our test harnesses. My first task (only cleaned up one atm) is talos (see attached patch). This required massive changes to the Talos codebase, but no changes functionally for desktop based talos.
I found that in adding support to Talos for a remote device (as well as initial work for xpcshell and mochitest) that once we develop a DeviceAgent for a given platform there will be almost no additional work required to start running tests! I might be out of a job!!!
Next week I am going to work with Aki to get talos up and running (trial runs…don’t expect true miracles) on winmo and reporting to a staging graph server. Following that, we will start cleaning up our other harness code and getting mochitest, xpcshell, and reftests underway.
Stay tuned for progress updates and more details about a much needed updating to the way automation is run!

The results from the Mozilla Creative Collective’s “Firefox Goes Mobile” design challenge are in, and I’m happy to announce that the winner is “Pocketfox”, by Yaroslaff Chekunov. As the official emblem of the upcoming mobile version of Firefox, we’ll be using this image as an avatar on social networking sites, on mozilla.com, on t-shirts and more. It makes a great addition to our portfolio of Firefox imagery!
Yaroslaff, who is based in Krasnodar, Russia, cites as his design inspiration, “the Firefox itself, your approach to the web-site execution, and of course my wife who always brings up new ideas.” Be sure to check out his other Mozilla work as well as his general portfolio.
The four runners-up in the challenge were Mauro Henrique de Bulhões Fidelix’s “Hot Navigation”, Emmanuel John Y. Villar’s “One Mask One Family One World”, Joyce Schellekens’ “Firefox All Around the World” and Eric Yeoung’s “MobiFox”. Interestingly, these designers all hail from different countries (Brazil, the Philippines, the Netherlands and Indonesia), which speaks to the incredible diversity of our community. Many thanks to them, and to everyone else who participated, for sharing their time and talents with Mozilla.
We’ve also launched a new challenge at the Creative Collective: “Five Years of Firefox”. Help us celebrate Firefox’s 5th birthday by creating designs based on this milestone. The possibilities are practically endless, but should generally focus on recognizing what a great accomplishment this is for the Mozilla community and what it’s meant for the hundreds of millions of people who use Firefox. The winner will be featured on this blog, turned into desktop wallpaper and t-shirts, and more.
The submission period for “Five Years of Firefox” ends on December 9th, but don’t wait to get started. Visit the design challenge page for more details, and we can’t wait to see what you come up with!
In a previous posting, I introduced the concept of inherited folder properties in the Mozilla mailnews products (Thunderbird and SeaMonkey). In the months since, I have incorporated these into my extensions quite significantly, so here I would like to show the UI I am currently using for this, and also discuss some of the issues that I face.
(All references to extensions in this posting refer to the 1.0.0 versions, which as of this writing have not been posted to AMO yet. But they should be available in a few weeks.)
Briefly, inherited properties are a property that can be defined globally, at the server, or at the folder, and its characteristics will be propagated to child objects. This make it easy to specify precisely how the property is applied.
As an example, I have recently implemented a feature “Index in Global Database” in GlodaQuilla which can be used to selectively suppress certain accounts or folders from being accessed by the global database indexer. In the account manager, where indexing can be disabled for an entire account, the UI looks like this:

Each inherited property has default values which are typically set by the base code. In the case of the gloda database indexer, everything but newgroups are indexed by default. Initially each inherited property is set to just use the standard default processing, but if I clear the “default” checkbox, then I can turn off gloda indexing for this account.
If I do that, then go to a first-level folder in the account, I see the following under folder properties:

At the folder level, because I disabled global indexing on the account, it is now shown as disabled on the folder. I could clear the inherit box and selectively enable it on just this folder and its children if I wanted.
This particular UI merges naturally with the existing methods of setting properties in mailnews, but I’m not sure it is optimum for an inherited property. The inherited nature could be more clearly shown, and a particular feature more quickly configured, if I showed a tree of accounts and folders, with checkboxes next to each account to enable or inherit the feature. Maybe in a future version.
Here are some of the implementations of inherited properties that exist in my extensions:
Ideally, the inherited property would be the one and only way to manage a program feature. But for existing features, the existing mechanisms remain, which can lead to possible confusion. For example, with JunQuilla’s “Analyze Junk” property, there is existing UI to enable junk processing at the account level. Here the inherited property will always override the default mechanism (but that is mostly because I implemented it in core that way, and I have a little influence on how junk processing is handled in core.) For GlodaQuilla’s “Index in Global Database” the behaviour is different. Existing UI will only allow this to be enabled or disabled globally, and the inherited property does not override this. The inherited property code uses the default server preference as a global enable/disable for a property, so if gloda used that same mechanism instead of an independent preference, this issue would go away. I guess I could say the same thing about junk processing as well.
For FiltaQuilla’s “Apply Filters to Folder”, there is a subtle issue in the inherited nature. I did not implement in core the ability of the inherited property to override the existing default as applied to the Inbox, so incoming filters always run on the inbox. That creates 2 ui issues. First, although I show at the account level the “Apply Filters” option, it does not actually suppress application to the inbox as one would expect. Second, I currently do not show a folder property for “Apply Filters to Folder” for the IMAP inbox since it would not make sense there, so that also means there is no way to enable processing of filters for the children of the inbox. Maybe I should call this feature instead “Apply Filters to non-Inbox Folders” to solve this, or change the core code so that the feature also applied to the Inbox.
Looking ahead to a world where a number of extensions might try to define bayes filter traits, in code I recommended that properties used to manage junk processing use an RDF-inspired globally unique identifier. Then I followed my own advice and defined the identifier that controls junk processing on a folder as: “dobayes.mailnews@mozilla.org#junk” Unfortunately, the existing account manager code does not allow periods in property names, which means I could not use the account manager to manage this. I’ve filed bug 525024 on this issue, and perhaps that can be incorporated after TB 3.0 / SM 2.0.
I’ve heard others comment that often they want to set a property on a particular class of folders, say on all Trash folders, or all Sent folders. I’ve considered implementing another level in the inherited properties feature, that would be a folder type. So you would then set a property that would be inherited by any folder of a particular type, and its children – and of course also overridden by the local folder property.
All of the inherited properties could also be enabled globally using the “mail.server.default.<property>” preference, but I did not give any UI for that in my extensions. I thought that would be too confusing for the user to show those preferences, which would be very similar to existing mechanisms. This is not an issue for properties that use the preference system for server-level issues, but none of the existing server-level preferences are also inherited properties. Perhaps we could move that direction in the future.
One of our goals over the past few months was to get the knowledge base average CSAT score up to 85%.
CSAT is short for Customer Satisfaction, and the way we measure it is with the “Please rate your experience with solving your problem on support.mozilla.com from 1 (very unsatisfied) to 5 (very satisfied).” poll that appears on each article. This is the primary metric that we use to measure the success of the Knowledge Base.
One of the ways we tackled it was to take some of the larger articles that cover generic subjects like bookmarks or cookies, and split the content up into individual articles addressing specific questions seen in the list of top searches.
Recently, “cookies” became our top search term, so we decided to split up that article first.
Over the month before we split up the Cookies article, it had a CSAT score of 4.36 (87.2%).
Our top cookie related search terms cover 3 tasks:
We created an article for each of those tasks. As a result, each article was shorter and to the point. The average CSAT score of all three articles plus the original since the split is 4.5675 (91.35%).
If we take the original article out of the equation, the CSAT score rises to 4.71 (94.2%).
This action was one out of many that we’ve taken, which has risen the average score, and we’re not done yet. The Bookmarks article has been split, and we’re looking into the need to split up the Pop-up blocker article and maybe Tabbed browsing.
The lesson here is to let the search terms dictate how we spread out our documentation, so the article to question ratio is 1:1.
A list of top 15 search terms can be found in the SUMO Weekly Metrics, and if anyone wants to see a full list of our top search terms, just post in the Contributors forum, and any SUMO team member will be happy to provide the information for you.
Jetpack is a Mozilla Labs project which makes it possible for anyone who knows standard web skills (HTML, Javascript, CSS) to make Firefox add-ons.
We are happy to announce that we have a winner for the Jetpack 0.5 contest. Given the fantastic group of entrants, with Jetpacks that did everything from Twitter readers to a one-click text translators, it was hard to pick a winner.
Alexander Miltsev of Moscow created a prototype for allowing Jetpacks to process large amounts of data on your computer’s graphical co-processor. Alex’s work is both creative and unusual. It digs deep into what a potential future for Jetpack can be—allowing for high-performance computing that is accessible to casual developers.
In Alex’s words: “Large data processing is occurring everywhere today. Graphical co-processors are on computers everywhere [and are used in] computational science models, searching tasks, algorithms, statistics, and audio and video processing.” By giving webpages and add-ons easy access to the raw processing power available on most computers, the range of abilities that the web can have greatly increases.
Alex’s work is an alpha-prototype that shows the feasibility of the project and it requires a custom build of Firefox to use — it’s not easy to demo. However, the code sample below shows how the technology works. In this example, we are transposing a matrix at lightening speed:
jetpack.statusBar.append({ html: "Transpose!", onReady: function(widget){ $(widget).click(function(){ var myStorage = jetpack.cuda-storage; var matrix = new Array(); var size = 32; for(var i=0; i<size*size; ++i) array[i] = i; var transposedMatrix = myStorage.transpose(size, matrix); transposedMatrix.forEach(function (v) { console.log( v ); }) });
});
You can get more information about Alex's Jetpack on his website. For winning the Jetpack 0.5 competition, Alex is getting a brand new ASUS Eee PC netbook!
Check back in a couple days for the next Jetpack contest.
Elijah Grey wrote the GTranslatifier Jetpack, which lets you translate web pages and selections of text at the click of a button. He also wrote the Edit Page Jetpack, which lets you temporarily live-edit the contents of any page.
Francesco Strappini wrote a cute Jetpack called 3lyfic, which creates short links via http://3.ly and then lets you share them across your social networking site.
Panagiotis Astithas wrote the Jetstatus Jetpack, which not only gives you notifications of Twitter updates, but also lets your quickly read over past tweets in a slidebar.
— Aza Raskin on behalf of from the Jetpack Team
Everytime someone does a checkin, we do a whole bunch of builds, unittests and performance runs. Sure. But did you know we run about 40 hours worth on desktops, with an additional 25 hours on mobile?
Chris AtLee put together a complete list here, listing out what jobs are run. Its much easier to read then anything I’ve tried in the past, and well worth a quick read.
Its hard to grasp the scale of all this by looking at Tinderbox waterfall, but mstange’s TinderBoxPushLog does a *great* job of showing what happens with every checkin. After you read Chris’s blogpost, all those cryptic code on the right hand side of TinderBoxPushLog will make much more sense!
For those of you waiting for the official release of Bugzilla API 0.2: it's still blocked on getting some small support patches on to bugzilla-stage-tip.mozilla.org or bugzilla.mozilla.org. Despite my begging and pleading, it's looking like this won't happen until the upgrade to Bugzilla 3.4, which keeps getting postponed :-(
For the 0.8 branch, Cédric Corazza (l10n lead) has decided to publish localized builds instead of just proposing cross-platform langpacks. Not as easy as it seemed… but the new “Download” page is ready.
The main goal was to make it simpler for KompoZer users to get a localized app. As a developer, I prefer to ship only one build per platform and one cross-platform language pack per supported locale; but obviously, most users prefer to download a localized build… like they do for Firefox, Thunderbird or SeaMonkey.
Cédric has spent more time than expected on these localized builds — partly because the lead dev forgot to mention a new localized string in the latest revision (ahem). After some work and a lot of tests, we’re now pretty confident that these localized builds work fine, so we’ve removed the “Localizations” page and included all langpacks in the main “Download” page.
The other main trouble when dealing with localized builds is that a lot of files have to be uploaded for each release. The old SourceForge File Release System was a complete blocker: we had to upload all files in a common directory on SF.net, then use their web interface to add each file one by one to the KompoZer project. Fortunately, the new SF File Release System is more straight-forward: each project now has its own “releases” directory, and it’s possible to rearrange files within this directory with simple shell commands, on SSH — errr, at least, when the “releases” directory is mounted, which isn’t always the case.
For the upcoming beta2 release, we should be able to release all localized builds at the same time. Hopefully.
KompoZer 0.7.10 is available in 21 languages; but so far, we have only 10 locales for KompoZer 0.8b1.
Besides, three new locales are almost ready: Finnish, Slovenian and Turkish (≥ 96%) still require a little work to be ready for KompoZer 0.8.
Translators, we need your help! Localizing KompoZer doesn’t require particular technical skills, and wouldn’t require much time for the locales listed above. You can have a look at the KompoZer l10n page to get more information, and of course, you can ping us on the #kompozer chan to get some help.
The new “Download” page now shows KompoZer 0.8b1 by default, but there’s a KompoZer 0.7.10 section at the top of the page — mostly for Windows users. We’ve kept the big, orange “Download” button for Windows users, and added a bold warning for Linux and Mac users: while KompoZer 0.7.10 works fine on Windows, there are known problems on recent Mac OS X and GNU/Linux systems.
The main “KompoZer 0.8” section now displays a locale/platform download table, as well as a big “Download” button that should point to the appropriate version — according to the user-agent. This button is visible for all supported platforms (Windows, Mac, Linux) and defaults to the English version when no localized version matches the user-agent locale.
On the home page, the main “Download” button points to:
I hope this will significantly reduce the number of mails and bug reports I get from Linux users complaining that KompoZer 0.7.10 crashes with their latest distro.
We intend to replace the “Download” buttons by localizable ones as soon as possible: at the very minimum, we’d like these buttons to state clearly which version (platform/locale) they refer to.
The next step will be to localize the whole website, at least for the most active communities. We’ve already begun to work on this, and this should be done before the final 0.8 release.
Of course, this will be an opportunity to revamp the website and re-organize the content. Note that the HTML structure will remain unchanged — we want this website to be usable as an example for beginning web authors and we’ll stick to this simple HTML structure:
<body> <div id="header"> … </div> <div id="menu1"> … </div> <div id="menu2"> … </div> <div id="content"> … </div> <div id="footer"> … </div> </body>
So if you’d like to propose a new stylesheet for kompozer.net, feel free to submit your work: it will still work with the new, localized website.
The source code for the Mozilla Add-ons project tries to follow the PEAR Coding Standards. One of these standards is to use 4 spaces per level of indentation, and no tabs.
Over time, unfortunately, some files start to contain a significant amount of mixed-up indentation (both from badly set-up IDEs and third-party contributions that came with tab indentation but went un-noticed). That’s both tedious and error-prone to fix by hand.
A similar problem poses trailing whitespace. While it’s just annoying in general, especially in HTML template files, it also increases page size unnecessarily by leading to more bytes transmitted on the wire, with no benefit to neither the users nor the developers.
Luckily, there are two quick fixes for these problems in both the editor vim and my IDE of choice, Komodo:
To remove tabs and replace them with spaces…
:%s/\t/ /g (those are four spaces) — or, as oremj points out in the comments, you could just to :retab .And to wipe out trailing whitespace…
:%s/\s\+$//g which the regex-savvy among you have quickly decyphered as: “in the entire document, replace all one or more whitespace characters that are followed by a line ending with the empty string”.Happy cleaning!
Armen just blogged about this, and as it’s constantly mentioned around l10n, I wanted to add a bit more detail to l10n-merge.
l10n-merge is originally an idea by our Japanese localizer dynamis. The current implementation used in the builds is by me, integrated as an option to compare-locales. There are spin-offs of that algorithm in the silme library, too.
l10n-merge attempts to solve one reason for “yellow screens of death”, i.e., XML parsing errors triggered by incomplete localizations. This is really crucial as localizations don’t just pop up by swinging magic wands, they’re incremental work, and a huge chunk of that. So in order to test your work, you need to see the strings you have in, say, Firefox, without having the other 4000 strings done yet. Other l10n-infrastructures handle this by falling back to the original language at runtime (gettext), but doing that at runtime of course has perf impact, and size. l10n-merge does the same thing at compile (repackaging) time.
Design goals for l10n-merge were:
Thus, in order to not mess with the source repos, l10n-merge doesn’t modify the sources inline, but creates copies of the files it touches in a separate dir. Commonly, we’re using ‘merged‘ in the build dir. Now, creating a full copy of everything would be tons of file io, so l10n-merge only creates copies for those files which actually need to get entities added to existing localized content. This plays together with code in JarMaker.py which is able to pick up locale chrome content from several source dirs.
A Firefox localization contains some 450 files, and say for the current 9 B1-to-B2 missing strings in two files, it would copy over those two files from l10n, and add the missing entities to the end. Then JarMaker is called with the right options, and for those two files, will pick them up from merged, the rest of the localization is gotten from l10n. For missing files, it actually looks into the en-US sources, too, so we don’t have to do anything for those. To give an example, for chrome/browser/foo in the browser ‘module’, it searches:
.../merged/browser/chrome/fool10n/ab-CD/browser/chrome/foomozilla/browser/locales/en-US/chrome/fooNow it’s time to list some pitfalls that come with l10n-merge:
Here in Slovenia we like to party like any good nation, so what better excuse than the birthday of our beloved Firefox. After all we were 2nd or 3rd to reach 50% Firefox market share, but are still licking our wounds after being pipped at the post by an Indonesia that came from nowhere. Not ones to hold a grudge, we have vowed to become the first country to reach 100% market share.
That might require some pretty heavy political lobbying and/or bribery, so in the meantime we’ll start off by having a party. Read all about it over on mozilla.si and RSVP at the Facebook event page. If you can’t speak Slovene (don’t worry, you are not alone) or have an aversion to Facebook, here is the short version:
The famous Firefox wine will be served. There will be cake. There will be blood. We are working on the music. Mozillians and party-lovers everywhere, you are invited.
If you have been using the Weave sync add-on these past few months, you have seen a lot of changes. All of these have been leading up to us getting ready to release a version 1.0.
Next week, we expect to be able to release the first beta of the Weave sync add-on. To help you prepare for this release, we wanted to share some details on what to expect:
* When you install the 1.0 beta sync add-on, all of your firefox and fennec instances will do a fresh upload of all your data. For the majority of our users, this should happen in a transparent manner. However, if you are using the Weave servers primarily as a back-up and do not have your data anywhere else, you should ensure you have at least one local copy before upgrading to 1.0 beta.
* If you are using the sync add-on on multiple computers, you will need to upgrade to the 1.0 version on all of them to get sync functionality working correctly.
* If you have been using the auto-login features, you may have noticed them missing already starting with the 0.8 version. The weave sync 1.0 beta add-on will only have synchronization related functionality. The auto login feature is *not* dead. It is simply being moved into its own add-on. We hope to be able to release an early pre-alpha version soon (in a week or so). We fully intend to develop it rapidly and have a bunch of new ideas/features lined up. See the wiki page for more details.
* The 1.0 beta sync add-on includes the incremental sync behavior. This helps in two ways:
1. Your data will be synchronized in chunks to improve performance. Among other things, it ensures that you can continue to use firefox normally even when you are syncing hundreds of bookmarks in the background. That said, if you have a lot of data, it could take some time for all of it to be synchronized. Do not panic if you do not see all of your data immediately. Depending on the type of computer you have and the amount of data you have, this could take anywhere from a few minutes to a few hours.
2. Your data will be synchronized based on “Interestingness”. “Interestingness” is related to how the AwesomeBar works in Firefox where pages that you frequently and recently visit show up higher in the location bar results. Weave basically stores that “frecency” value with the encrypted history data on the server, so Weave clients can ask the server for the most interesting items first. For other data like bookmarks, frecency is combined with where the bookmark is shown, so items visible in the Bookmarks Toolbar are ranked as “more important.”
* Finally, if you are hosting your own weave server, you’ll need to add an apache alias line for the 1.0 URL – your old server will still handle the same API.
The weave team will be watching our servers and the forums very closely during and after the release to ensure everything happens smoothly. We are really excited about getting to this major milestone and look forward to building an awesome product for you.
As always, let us know if you have any questions/comments on the forums.
– Ragavan Srinivasan, on behalf of the Weave team
As part of Mozilla’s ongoing stability and security update process, Firefox 3.5.5 is now available for Windows, Mac, and Linux as a free download from http://firefox.com/.
We strongly recommend that all Firefox users upgrade to this latest release. If you already have Firefox 3.5, you will receive an automated update notification within 24 to 48 hours. This update can also be applied manually by selecting “Check for Updates…” from the Help menu.
For a list of changes and more information, please review the Firefox 3.5.5 Release Notes.
Note: All Firefox 3.0.x users are encouraged to upgrade to Firefox 3.5.5 by downloading it from http://firefox.com/ or by selecting “Check for Updates…” from the Help menu.
I just uploaded Bugzilla Helper 0.2.0. This improves on the last release by making making the submission of comments an asynchronous operation. It also uses the activity manager in Thunderbird to track the process of the submission, and retry it if an error occurs.
There are still some apparent issues with the REST API that the add-on is using, and I’ll likely include some workaround in upcoming versions. 0.2.0 is available on addons.mozilla.org and is a recommended upgrade. Current users will have to update since sandboxed add-ons do not automatically update.
I’ve been down and out with FSOSS followed by flu, so haven’t blogged this yet. But I wanted to add my voice to the others who have already written about Mozilla’s new Jetpack for Learning Design Challenge. As Frank Hecker writes,
We invite you to help turn the open Web into a rich learning environment and explore new possibilities for using Firefox add-ons to support learning online, by participating in the Jetpack for Learning Design Challenge sponsored by the Mozilla Foundation with support from the John D. and Catherine T. MacArthur Foundation as part of its digital media and learning initiative.
We’re looking for designers, educators and software developers who want to turn their innovative ideas about learning online into working prototypes in the form of Firefox add-ons. We’ll help you refine your designs and teach you how to create Firefox add-ons using Jetpack and other Mozilla technologies. Participants creating the best prototypes will be invited to the Jetpack for Learning Design Camp and the SXSW Interactive conference in March 2010.
One of the more interesting things that’s happened with Mozilla in the time I’ve been involved is that it has gotten easier and easier for people to work with technologies like Firefox extensions. Things like Jetpack open the door even wider to welcome students, new developers, web developers, designers, etc. Combine this with an educational context and mentorship model in which to learn how to do this, and you’ve got a winning recipe.
There’s still time to make submissions (you can do that here), and I’d encourage students and educators to get involved. The Mozilla project is a great place to be a student, and this is just one more reason why.

Last week I shared our goal to “Light the World with Firefox” for the 5th anniversary of Firefox. By popular demand I’m including some more information and inspiration to help you get started.
Mobile: Get the Firefox logo on your phone by visiting the “Light the world with Firefox” mobile page on your phone and take a picture. (URL: http://bit.ly/fx5mobile) Get a shot in front of a local landmark. Or, organize a bunch of friends at a Firefox party for a group picture.
Mash-Up: We’re looking for the most interesting ways you can combine Firefox and light…without setting anything on fire! 350.org had a recent campaign with a great example of light painting. Check out some other examples here.
Shadow & Light Play: We’ve created stencils that will help you project the Firefox logo on a wall. Use the stencils to create a cut out of the Firefox logo on black or very thick paper. Tape colored film over the cutout for fun effect.
Please share any light-related Firefox artwork (posters, wallpapers, stencils and more) you create with the world by submitting them to our latest Mozilla Creative Collective Challenge. At the same, please upload all videos and pictures of your handy work on Flickr with the tag “Firefox5″. We’ll feature submissions on a special site launching on November 9th and the most creative actions will be rewarded with some cool Firefox swag.
Have a great idea? Share below by commenting!

We’re gearing up for some heavy CouchDB usage in a new automation system and it has fallen upon me to do some performance benchmarking.
The most important thing for us to figure out was whether or not the CentOS virtual machine we’re currently running CouchDB on is going to be enough even in the short term. Until today we’ve been running 0.9 and have encountered performance problems.
Our main bottleneck is, and has always been, view generation and update performance. We tend to have medium to large size documents (jobs are relatively small but results from test runs can be incredibly large).
View generation of large documents has typically been our biggest issue which we have previously mitigated by refreshing all views after any large write but that isn’t going to work for the amount of results that we plan on pouring in to the new system.
Last weekend I wrote a Python view server for CouchDB. couchdb-python includes a view server but in the past I’ve heard complaints about performance (although none recently). In addition, the view server in couchdb-python only supports map and reduce, which is only about 1/5 of the current view server spec which includes handlers for update, show, list, filter, and validate which provide the groundwork for CouchDB as an application platform. As of Sunday my view server passes all of the current CouchDB spec and initial performance tests showed it faster than the JavaScript view server.
Below are the performance graphs for CouchDB trunk running on a CentOS virtual machine. I’m using Python 2.6 with the default stdlib json library. The spidermonkey core is 1.7 (I don’t know what the status of using 1.8 with CouchDB is but as we’ll see below, this won’t improve performance too much for these tests).
These graphs show view generation time for a given number of documents in a new database. The design doc I used had two views, one does emit(doc['type'],doc), the other emit(doc['_id'], 1).
The graphs support zooming, mouseover and all kinds of flot goodness
JavaScript is the yellow line. Python is the Blue line.
<script language="javascript" src="http://www.mikealrogers.com/js/flot/jquery.js" type="text/javascript"></script> <script language="javascript" src="http://www.mikealrogers.com/js/flot/jquery.flot.js" type="text/javascript"></script> <script language="javascript" src="http://www.mikealrogers.com/js/flot/jquery.flot.navigate.js" type="text/javascript"></script> <style> #placeholder .button { position: absolute; cursor: pointer; } .message { padding-left: 50px; font-size: smaller; } </style>
This is a test of moderately sized documents, what we normally expect the size of a job or build description. Each document is identical and fairly simple with a size of ~1,588 bytes.
These documents were incredibly large, they were taken from a full fennec mochitest run. Each document is identical and while large it consists mostly of small sized JSON objects inside a much larger JSON object coming in at ~139,096 bytes.
<script id="source" language="javascript" type="text/javascript"> $(function () { var perf = {"medium_count_3000": {"python": 0.012593, "js": 0.019630000000000002}, "medium_count_9000": {"python": 0.012441000000000001, "js": 0.016513}, "large_gen_100": {"python": 4.8752870000000001, "js": 12.055866999999999}, "medium_gen_1000": {"python": 1.188747, "js": 1.8925399999999999}, "large_gen_10": {"python": 0.42780600000000002, "js": 1.540985}, "medium_count_100": {"python": 0.011244000000000001, "js": 0.013335}, "medium_count_1000": {"python": 0.010567, "js": 0.020129999999999999}, "medium_count_10": {"python": 0.011192000000000001, "js": 0.015753}, "large_count_100": {"python": 0.011394, "js": 0.022543000000000001}, "large_count_10": {"python": 0.0092929999999999992, "js": 0.013655}, "medium_gen_100": {"python": 0.132188, "js": 0.20717099999999999}, "large_gen_300": {"python": 14.486787, "js": 52.309240000000003}, "medium_count_6000": {"python": 0.011205, "js": 0.020074000000000002}, "large_count_300": {"python": 0.045109999999999997, "js": 0.060045000000000001}, "medium_gen_6000": {"python": 6.398968, "js": 11.531126}, "medium_gen_10": {"python": 0.53901500000000002, "js": 0.22401099999999999}, "medium_count_10000": {"python": 0.013492000000000001, "js": 0.020256}, "medium_gen_3000": {"python": 2.8234699999999999, "js": 5.5480289999999997}, "medium_gen_9000": {"python": 9.3583010000000009, "js": 16.559753000000001}, "medium_gen_10000": {"python": 10.365868000000001, "js": 17.842866000000001}}; function sumf(f, t, m) { var res = 0; for (var i = 1; i < m; ++i) { res += f(i * i * t) / (i * i); } return res; } var python_medium = [ [100,perf['medium_gen_100']['python']], [1000,perf['medium_gen_1000']['python']], [3000,perf['medium_gen_3000']['python']], [6000,perf['medium_gen_6000']['python']], [9000,perf['medium_gen_9000']['python']], [10000,perf['medium_gen_10000']['python']], ]; var js_medium = [ [100,perf['medium_gen_100']['js']], [1000,perf['medium_gen_1000']['js']], [3000,perf['medium_gen_3000']['js']], [6000,perf['medium_gen_6000']['js']], [9000,perf['medium_gen_9000']['js']], [10000,perf['medium_gen_10000']['js']], ]; var python_large = [ [10,perf['large_gen_10']['python']], [100,perf['large_gen_100']['python']], [300,perf['large_gen_300']['python']], ]; var js_large = [ [10,perf['large_gen_10']['js']], [100,perf['large_gen_100']['js']], [300,perf['large_gen_300']['js']], ]; var placeholder = $("#placeholder"); var data = [ { data: js_medium, color:"yellow"}, { data: python_medium, color:"blue"}, ] var options = { series: { lines: { show: true }, shadowSize: 0, points: { show: true } }, xaxis: { zoomRange: [0.1, 10000], panRange: [-1, 10001], ticks: [0,[100,"100Docs"],[1000,"1000Docs"], [3000,"3000Docs"],[6000,"6000Docs"],[9000,"9000Docs"], [10000,"10000Docs"], ], }, yaxis: { zoomRange: [0.1, 19], panRange: [-1, 20], ticks: [[0,'.'],[1,"1s"],[3,"3s"],[5,"5s"], [6,"6s"],[9,"9s"],[10,"10s"],[12,"12s"],[18,"18s"] ], min: -1, max: 19 }, zoom: { interactive: true }, pan: { interactive: true }, grid: { hoverable: true, clickable: true }, } var plot = $.plot(placeholder, data, options); placeholder.bind('plotzoom', function (event, plot) { var axes = plot.getAxes(); $("#message-text").html("Zooming to x: " + axes.xaxis.min.toFixed(2) + " – " + axes.xaxis.max.toFixed(2) + " and y: " + axes.yaxis.min.toFixed(2) + " – " + axes.yaxis.max.toFixed(2)); }); function showTooltip(x, y, contents) { $('I had also intended to chart the reduce performance with a simple sum operation but all the results were sub-second regardless of the amount of documents I threw at it with Python being only a little faster than JavaScript.
The nearly identical reduce time tells me that the actual code processing time inside the view functions are hardly different which means that the large difference in performance during view generation is most likely due to JSON serialization time. This also explains why larger documents cause an even greater difference in performance between Python and JavaScript.
The Python view server is already as optimized as I can imagine for processing time inside the views. Since CouchDB doesn’t provide a way for the view server to support it’s own concurrency we’ve basically hit the wall here on what Python can provide. If we increased the complexity of the view functions I think that Python would start to show better than Spidermonkey 1.7, but 1.8 with traceing enabled would likely bridge that gap, possibly even showing JavaScript faster than Python.
The big problem is JSON serialization. We can make Python faster by compiling simplejson with C speedups. But using the C based JSON parser in newer versions of Spidermonkey requires some other changes to CouchDB since there are differences in the encoding of undefined.
At the end of the day though, this all looks great. CouchDB trunk (pre-0.11) is going to run fast enough for what we need right now even on a virtual machine and if we start to see view generation bottlenecks on views that aren’t hit as often and have to update a large number of documents we can just move those views to Python and the performance should be back down to sub-second.
We just released the latest version of Test Pilot, and a new study is coming soon!
One of the problems with the Test Pilot extension so far has been that we’ve needed to release a new version of the extension every time we wanted to add a new experiment or survey, or even in order to fix a minor bug. And every time we released a new version, users had to download it, then restart Firefox; an annoyance that we’d rather not force on people. This new release of the Test Pilot extension, version 0.3, has been rewritten from the ground up to avoid this problem.
Many pilots have asked what is the next study, and here it comes: A Week in the Life of a Browser!
For this study, which we will be launching at the beginning of December, we would like to explore what a browser does to facilitate its user using the Web through a year. We will periodically collect your usage information about the browser for a week and run the same study again every 60 days. The main goal is to explore if the browser has been used differently over time, which may help us design a better product that works adaptively.
For more detail about this release, please read the original blog post!
getfirebug.com has Firebug 1.5b2. It fails two tests on FF 3.6, one extra newline you can’t see in the UI anyway and one of the the network breakpoint tests that we are looking into. We could not test on Firefox 3.7 because of Bug 522590. Ok, not a perfect story for b2, but we have lot of fixes we want to get out, we want to start localization work for 1.5, and it hss been almost 2 weeks since b1.
We’ll dedicate this release to Mike Radcliffe for checking a large number of old bug reports and getting most of the closed as users report that the bug has been fixed in the meantime. Thanks Mike!
jjb
Discussion Items
Project Updates
It's Wednesday, and with that, time for another post in the ongoing series of SeaMonkey 2 contributor intereviews! This time, we'll continue with a guy who's known on IRC as InvisibleSmiley:
Who are you?
I'm Jens Hatlak, German/Austrian, single, located in Frankfurt, Germany, and still on the better side of 30. :-) I've been working as a PHP web developer for a large logistics company since I left university (computer science, TU Darmstadt) in 2007.
I chose my nickname, InvisibleSmiley, because I think it's funny to tell people that's what they missed when someone made a statement with hidden irony. ;-)
I like to play the piano, although I'm not especially good at it. I'm a good swimmer, though, a science fiction fan, and a grammar guru (avoiding the more popular alternative term here for hopefully obvious reasons).
How did you become a SeaMonkey contributor?
I started using Mozilla when it was still in the Milestone phase (around 2000), so I was a beta tester almost from the beginning, but only watching the game back then.
In 2001 I made my first Bugzilla comment and filed an enhancement bug (still open!). I also started university that year where I joined a group of system administrators responsible for the computers of the computer science department (some thousand students). After some time I took over the responsibility of not only the web server but also parts of the software installation, including Mozilla (later also Firefox, Thunderbird, and SeaMonkey), all on Sparc/Solaris. During that time I learned how to compile software from source under difficult conditions and how to write patches. However I was still not actively contributing code. Even when I worked on MozPETs <http:></http:> I sticked to what I knew (compiling <http:>) instead of diving into extension development and trying to understand the basic principles like XUL.
I kept using SeaMonkey when Mozilla decided to drop the suite, staying on the bleeding edge (nightly builds). When MozillaNews went on hiatus (and with it its Bonsai Watch bug tracker) I started to track SeaMonkey-affecting bugs myself, just out of interest. At some point in time I decided to push the results to a place where I (and others) could find and search them: The SeaMonkey Trunk Tracker <http:> was born. I learned how to build SeaMonkey on Windows and updated my public build instructions, but other than that I just watched development progress.
My active participation in SeaMonkey development started only last year, in October 2008 (funnily by posting a patch one minute after another developer submitted almost exactly the same), when the code had already moved to Mercurial. I was surprised by the fact that simple changes and corrections were much easier to accomplish than I had thought, so I continued to contribute small patches. The rest is history <https:>. :-)
What notable contribution did you make to SeaMonkey 2.0?
I must have touched almost all parts of the UI by now... Let's see.
This may look like much (and it's certainly not few) but it's nothing compared to what people like Neil contributed in the same period of time: just think of all the reviews he made! Respect.
Beyond that I looked into making some popular extensions compatible with SeaMonkey 2, i.e. ones that need more than just a version bump. So far I have been successful with Nostalgy, Flat Bookmark Editing, Download Statusbar, and Firebug <https:> (yes, that's right!). I hope the latter can be fixed at the source, the others should appear at the xSidebar <http:></http:> site sooner or later.
How can users give something back to you?
I don't know, maybe a bar of good chocolate? :-)
Seriously, my personal needs aside I'd like to see more people getting involved in the project. If you are maintaining an add-on (extension or theme), now would be a fine time to make it SeaMonkey 2.0 compatible. But coding is only part of it, so if you feel like you should give something back, you could help with marketing, quality assurance (e.g. organizing bug days), design (especially icons!), featured articles (e.g. blog posts with screen shots or videos) or even usability considerations. Helping other people in fora and newsgroups is also appreciated, of course. :-)
Oh, and if people would stop mistaking "it's" for "its" that would be nice, it hurts my eyes. :-P
Why, in your eyes, should people use SeaMonkey 2.0?
Because it has everything you need in one place. I think it's the combination of browser and MailNews that I like best but I've learned that people have different reasons for using SeaMonkey, and all of them are valid. I'm not saying that everyone should use SeaMonkey, though; in fact I tell people who really want to use just a browser to use Firefox instead if they feel comfortable with it. In the end it's just a matter of personal preference.
What next step do you see for SeaMonkey, and what would you like to happen in the Mozilla and SeaMonkey projects?
In the imminent future I think we need to concentrate on getting it right, i.e. fixing the most evident problems people have with SeaMonkey 2.0 (like the recurring high CPU load issue). The next step is to make use of more Toolkit features like the Places back-end for bookmarks which will enable syncing bookmarks with Weave, and to foster integration (Lightning, KompoZer; maybe instant messaging?). In the more distant future we'll have to keep an eye on what people expect from a modern Internet application and cautiously make the necessary adjustments.
What I would like to see is an evolution of usability (supporting the user's work flow), and an improved collaboration of Mozilla projects. The comm projects (Thunderbird, SeaMonkey and Calendar) are already cooperating quite nicely but I think there's room for improvement elsewhere.
We are excited to give an update on the recent progress that we’ve made for the Test Pilot program.
Since we announced the first study of Test Pilot, Tab Open/Close, about two months ago, we have received more than 7,000 data submissions from around the world, providing invaluable data into how you use tabs in your daily Web browsing. We’ve published some analysis we of this data. We’ve seen the thoughts you’ve shared about it via the discussion group and twitter . We’ve seen people use the aggregated data samples that we published to do their own analysis. The level of interest and participation in the Test Pilot community is very encouraging to us. We hope to continue delivering studies that are interesting and meaningful to both the product team and the public. Thanks for your participation, and keep it coming!
One of the problems with the Test Pilot extension so far has been that we’ve needed to release a new version of the extension every time we wanted to add a new experiment or survey, or even in order to fix a minor bug. And every time we released a new version, users had to download it, then restart Firefox; an annoyance that we’d rather not force on people.
The new release of the Test Pilot extension, version 0.3, has been rewritten from the ground up to avoid this problem. It is now based on the same technology as Jetpack, which enables it to automatically retrieve new experiments and improvements to existing experiments, without asking you to download anything or restart Firefox.
Our policy of giving pilots control over their own data is the same as it has always been: You can still quit a study at any time, you can still review all collected data before you send it, and you can still choose not to submit the data when a study ends. The only thing that’s different is that we can now update an experiment already in progress.
Many pilots have asked what is the next study, and here it comes: A Week in the Life of a Browser!
In recent years, people spend more and more time on the Web to work, to organize their daily lives, to entertain themselves and to socialize with friends. Is Firefox robust enough to support these activities smoothly all the time?
For this study, which we will be launching at the beginning of December, we would like to explore what a browser does to facilitate its user using the Web through a year. We will periodically collect your usage information about the browser for a week and run the same study again every 60 days. The main goal is to explore if the browser has been used differently over time, which may help us design a better product that works adaptively. This study is inspired by several test proposals that we received in the past months: proposals for tests of Overall Performance , Memory Usage, and Window Metrics.
This is a periodical study; pilots can choose to opt in or out of the study at any time. Each study phase is independent and equally important to us. Whether you choose to participate for the whole year, or only for a single week, the data that you share is extremely valuable. Please read the details about the study, and please visit the Test Pilot discussion group to share your thoughts if you have questions about this study.
Robert O’Callahan has been posting updates in his weblog about changes that we’re going to be making that are web-facing. It’s worth summarizing two here for web developers.
Removing the media element ‘load’ event.
Yesterday I checked in a patch that removes support for the ‘load’ event on <video> and <audio> elements. We simply never fire it. Also, the networkState attribute is now never NETWORK_LOADED. When we’ve read to the end of the media resource, networkState changes to NETWORK_IDLE. We plan to ship this change for Firefox 3.6.
This API has been removed based on consensus from everyone who are doing HTML5 video implementations and there are lots of other options for events that Robert goes over in his post.
Changing our CSS Gradient Syntax
We landed support for a form of CSS gradients on trunk a while ago, but we got considerable feedback that our syntax — which was an incremental improvement of Webkit’s syntax, which basically exposes a standard gradient API in the most direct possible way — sucked. A bunch of people on www-style got talking and Tab Atkins produced a much better proposal. Since we haven’t shipped our syntax anywhere yet, dropping it and implementing Tab’s syntax instead was a no-brainer. So Zack Weinberg, David Baron and I did that (using a -moz prefix of course), and today it landed on trunk. It should land on the Firefox 3.6 branch shortly. It’s unfortunate to land something new like this after the last beta, but in this case, it seems like the right thing to do instead of shipping CSS gradient syntax that we know nobody wants.
We’ve never shipped the “bad” CSS gradient syntax in a final release, but it is in our first beta. We’ll be updating it before we make our final release of 3.6. Stay turned for the new syntax on hacks.
We’ve been hard at work over the last month on the next milestone on our path to 1.0, and we’ve just released version 0.8. In this last pre-beta release we have made a number of changes based on feedback from users around tighter integration with Firefox and Fennec, and improvements to the incremental sync behaviour introduced in 0.7.
For more details about Weave 0.8, please check out the details over at the Weave blog!
Weave Sync is a prototype that encrypts and securely synchronizes the Firefox experience across multiple browsers, so that your desktop, laptop and mobile phone can all work together. It is part of the Weave project, which aims to integrate services more closely with the browser.
What is Weave Sync all about? In short, Weave Sync lets you securely take your Firefox experience with you to all your Firefox browsers — including our mobile browser, codenamed Fennec. It currently supports continuous synchronization of your bookmarks, browsing history, saved passwords and tabs, as well as form-field history and preferences. For example:
If you have not looked at Weave recently, now is a great time to jump in and try it out! In this last pre-beta release we have made a number of changes based on feedback from users:
– Mike Connor, on behalf of the Weave development team

I'm going to start a new meme - as I find these funny and sometimes useful.
Rules :
My Five favorite/most useful websites are :
Now the fun part, people I'm tagging :
Flore , because becoming a mother doesn't imply stopping blogging.
Stéphane, because he uses the internet in a very different way than I do.
Allan , because he's moved on the other side of the pond and as been quiet since.
Smokey, because without him Camino wouldn't be in such a good shape.
Davida, for his vision.
Fixes:
mozilla-central pushlog for 2009-10-23 04:00 to 2009-11-03 04:00
I watched Don Norman's TED Talk "3 ways good design makes you happy" last night:
<object height="326" width="446"><param name="movie" value="http://video.ted.com/assets/player/swf/EmbedPlayer.swf"><param name="allowFullScreen" value="true"><param name="wmode" value="transparent"><param name="bgColor" value="#ffffff"><param name="flashvars" value="vu=http://video.ted.com/talks/embed/DonNorman_2003-embed_high.flv&su=http://images.ted.com/images/ted/tedindex/embed-posters/DonNorman-2003.embed_thumbnail.jpg&vw=432&vh=240&ap=0&ti=480"><embed allowfullscreen="true" bgcolor="#ffffff" flashvars="vu=http://video.ted.com/talks/embed/DonNorman_2003-embed_high.flv&su=http://images.ted.com/images/ted/tedindex/embed-posters/DonNorman-2003.embed_thumbnail.jpg&vw=432&vh=240&ap=0&ti=480" height="326" pluginspace="http://www.macromedia.com/go/getflashplayer" src="http://video.ted.com/assets/player/swf/EmbedPlayer.swf" type="application/x-shockwave-flash" width="446" wmode="transparent"></embed></object>
This part of his talk really stuck out for me (transcription errors mine):
I really had the feeling that pleasant things work better and that never made any sense to me, until I finally figured it out. Look:
I'm gonna put a plank on the ground. So imagine I have a plank about 2' wide and 30' long. And I'm going to walk on it. See I can walk on it without looking, and go back and forth, and I can jump up and down. No problem. Now I'm going to put the plank 300' feet in the air... and I'm not going to go near it, thank you. Intense fear paralyzes you. It actually affects the way your brain works.
...
If you're happy, things work better because you're more creative. You get a little problem, you say "Ah, I'll figure it out. No big deal."
Don Norman's ideas may be more relevant to industrial design, but I think this can safely be applied to software design (more my domain). Don points to how being fun and beautiful can make something better -- not just seem better, but work better. That's an important point in the common trade off in software development between spending more time on features or bugs vs. spending some time on making a UI "pretty". Occassionally in work debates -- whether on Komodo or on some of the ActiveState websites I'm involved in -- that "pretty" is said dismissively. I'm happy to have Don Norman's talk as a debate point.

BTW, thanks to stephen. A few weeks ago I reinstalled my Mac book and posted a list of the software I use. Stephen suggested I add Miro to that list. Cue many evenings of watching TED talks (including the above talk) and other programs.
After installing Miro, visit https://miroguide.com/feeds/2014 to get the latest TED Talks.
We (ActiveState) released Komodo 5.1.1 today. Get it here:
Or, if you are currently running Komodo 5.1.0, click "Help > Check for Updates...". This is a bug fix release and is recommended for all users. See below for details.
Two important bug fixes in this release are:
Fixed problem in re-generating the variable tabs in the debugger (Komodo IDE) which caused slowdowns and hangs when debugger was run repeatedly. (Bug 82518, bug 82542, bug 82426, bug 82557).
Fixed a bug where closing a tab would switch to the wrong remaining tab causing potential problems, such as the Komodo window titlebar no longer updating properly (bug 82474).
See the Release Notes for a full list of changes.
This release also include two tweaks to existing features that didn't quite make the final 5.1.0 release.
The Komodo 5.1.0 release included the new "Fast Open" dialog. In Komodo 5.1.1 the fast open dialog now has path mode support. This means that you can now use the fast open dialog for opening:
/etc/httpd/httpd.conf../foo.py~/wrk/coolstuff.rbNote that the latter also works on Windows if you manually set a HOME environment variable to whereever you tend to put your files. For example, on Windows XP, I certainly don't use "C:\Documents and Settings\trentm" as my main working directory.
Perl users of Komodo can now easily get syntax checking results from Perl::Critic -- "a static source code analyzer based (mostly) on Damian Conway's book 'Perl Best Practices.'". To setup you just need the "Perl-Critic" and "criticism" Perl modules installed. With ActivePerl you can do this:
ppm install Perl-Critic
ppm install criticism
Then select the warning level in Komodo's "Perl" preferences panel. This screenshot shows the result of "Brutal" warnings on Gisle Aas's LWP::UserAgent.
Users interested in more in-depth analysis and integration with Perl::Critic should take a look at ActiveState's Perl Dev Kit 8.0.
Komodo IDE 5.1 is a free upgrade for Komodo IDE 5.x license holders. Your license entitles you to run Komodo IDE on any of the platforms we support (Windows, Mac OS X and Linux). Komodo Edit 5.1 is, as ever, open-source and free.
We (ActiveState) released Komodo 5.1 today! Get it here:
Komodo IDE 5.1 is a free upgrade for Komodo IDE 5.x license holders. Your license entitles you to run Komodo IDE on any of the platforms we support (Windows, Mac OS X and Linux). Komodo Edit 5.1 is, as ever, open-source and free.
On to the features. A goodie in the Komodo 5.1.0 release that wasn't in the previous releases is the new fast-open (a.k.a. "Go to File") dialog.
<object height="600" width="800"><param name="allowfullscreen" value="true"><param name="allowscriptaccess" value="always"><param name="movie" value="http://vimeo.com/moogaloop.swf?clip_id=3825622&server=vimeo.com&show_title=1&show_byline=1&show_portrait=0&color=&fullscreen=1"><embed allowfullscreen="true" allowscriptaccess="always" height="600" src="http://vimeo.com/moogaloop.swf?clip_id=3825622&server=vimeo.com&show_title=1&show_byline=1&show_portrait=0&color=&fullscreen=1" type="application/x-shockwave-flash" width="800"></embed></object>
Fast open in Komodo 5.1 from Trent Mick on Vimeo.
The fast-open dialog is a quicker way to open files for editing. Komodo needed it: the system native File Open dialogs can be a pain (ever try to go up one directory in the Mac OS X File Open dialog?), poking around in a Komodo project tree to find just the file you want is slow. Worse than slow, it is distracting. With the fast-open dialog you typically just need to type a few characters in the base name of the file you want to open and hit <enter> to open the file.
The fast-open dialog makes it easy to:
The filter textbox supports multiple tokens, so while a search for 'mark' with match:
Markdown.pl
markdown2.py
markdown.php
markdown.py
a search for 'mark py' will match:
markdown2.py
markdown.py
A feature I love in Firefox is Ctrl+Shift+T (Cmd+Shift+T on the Mac) to re-open the most recently closed tab. Komodo now has that.
On the road to this Komodo 5.1 release we introduced hyperlinks in Komodo 5.1b1:
find highlighting in Komodo 5.1a2:
<object height="300" width="400"><param name="allowfullscreen" value="true"><param name="allowscriptaccess" value="always"><param name="movie" value="http://vimeo.com/moogaloop.swf?clip_id=3387846&server=vimeo.com&show_title=1&show_byline=1&show_portrait=0&color=&fullscreen=1"><embed allowfullscreen="true" allowscriptaccess="always" height="300" src="http://vimeo.com/moogaloop.swf?clip_id=3387846&server=vimeo.com&show_title=1&show_byline=1&show_portrait=0&color=&fullscreen=1" type="application/x-shockwave-flash" width="400"></embed></object>
editor history in Komodo 5.1a1:
and support for a new platform -- Linux/x86_64.
Along with dozens of bug fixes, XML/HTML tag highlighting and jump to matching tag, upgrades to our xdebug builds for PHP 5.3 debugging, and regular nightly builds for Komodo IDE and Edit... this is a good release. Try it out:
</enter>
We released Komodo 5.1 beta 1 yesterday! Get it here:
Please try it out and give us your feedback:
| http://listserv.activestate.com/mailman/listinfo/komodo-beta | |
| bugs | http://bugs.activestate.com/enter_bug.cgi?product=Komodo |
| forums | http://community.activestate.com/products/Komodo |
This is the third release of Komodo 5.1 on the way to a planned final release very soon (hopefully within a week or two). Here are a few goodies in this release. (See my previous posts about the Komodo 5.1a1 and Komodo 5.1a2 releases.)
Many IDEs that have code intelligence support allow you to Ctrl+click (Cmd+click on a Mac) on a symbol to Go to Definition. Here was Komodo's feature request for that. This is now implemented in Komodo 5.1b1.
However, we've gone one step further and made a generic system where Ctrl+mouse-hover will underline interesting regions (hyperlinks) in your text for clicking on. The most common type of hyperlink is a symbol for "Go to Definition". However other types of hyperlinks include:
Colors in CSS (including CSS in HTML files):
As in Firebug, you'll get a swatch of the color when hovering over the color. What's more, Ctrl+click will bring up the system's color picker with which you can change the color.
HTTP and FTP URLs:
Ctrl+click will load that URL in your browser.
Regular expression mapping to an HTTP URL.
Currently 5.1.0b1 includes a regex to map occurrences of "bug \d+" to the appropriate bug in ActiveState's bug database. Eventually we'll have a preferences dialog where adding these mappings will be easier, but for now here is how you can add your own.
A generic handler to do whatever you can think of.
The hyperlinks above are all implemented with a simple mechanism in Komodo's ko.hyperlinks JavaScript namespace. You can add your own handlers to do other things. Following how the regexhandler works is a good place to start. We'll try to give more examples later.
Note: The hyperlink types other than "Go to Definition" are only in Komodo IDE (i.e. not in Komodo Edit) for the 5.1.0b1 release. So, if you want to play you should either use Komodo IDE 5.1.0b1 or use the latest nightlies.
koext is a command-line tool for helping in building Komodo extensions. There are some great Komodo extensions that users have been building here. However, it is far from as easy as it should be to dig in and build Komodo extensions. Part of the solution is the koext tool. (Another part is documentation for extension authors, but that is a story for another time.)
We've started doing some updates to koext again (see the change log). Recent changes are working towards making it easier to have a quick development cycle -- i.e. make it so that to test a change to your extension you just need to:
koext build --dev, e.g. if you changed an IDL file; andInstead of the more laborious:
koext build to build a new .xpi file;.xpi in Komodo;In a subsequent post I'll describe how I setup to build a Komodo extension. Here is a brief intro to koext from way back
A quick list of other feature work, notable bug fixes and fixed annoyances in Komodo 5.1.0b1:
Komodo's new "History" feature now has session support which is currently used to make your history specific to a single Komodo window.
In Komodo IDE, the History now shows the section title for locations in the History. This can make the "Recent locations" menu a lot more useful:
In XML (and HTML and PHP, etc.) files, clicking on a tag will briefly flash (highlight) the matching tag (bug 81606).
Komodo's "jump to matching brace" now works as you'd expect for opening and closing tags in XML/HTML (bug 43239).
We've done some crash fix work so that Komodo 5.1b1 should be more stable that 5.1a2. It is hard to quantify and we continue to look for crash issues in Komodo.
Greatly improved the annoyance of it being very hard to grab the bottom-pane and sidebar splitters on Mac OS X (bug 80756).
Fixed the annoyance of being unable to resize Name/Type/Value panes in Locals/Globals debugger window (bug 80566).
fix: codeintel: calltips cannot show unicode doc comments http://bugs.activestate.com/show_bug.cgi?id=70448
Added Korean and Japanese JIS encodings (bug 80890).
As well there is more coming. Try out the Komodo nightly builds for the very latest stuff:
We released Komodo 5.1 alpha 2 a couple of days ago (shame on me for not announcing until now). Get it here:
Please try it out and give us your feedback:
| http://listserv.activestate.com/mailman/listinfo/komodo-beta | |
| bugs | http://bugs.activestate.com/enter_bug.cgi?product=Komodo |
| forums | http://community.activestate.com/products/Komodo |
This is the second release of Komodo 5.1 on the way to a planned final release around mid-May. There are a few goodies worth talking about in this release. (See my post about Komodo 5.1a1 here.)
Komodo now highlights find/search matches in your buffer. Here is a short video showing it off. Sorry, no sound. This is my first screencast. :)
<object height="300" width="400"><param name="allowfullscreen" value="true"><param name="allowscriptaccess" value="always"><param name="movie" value="http://vimeo.com/moogaloop.swf?clip_id=3387846&server=vimeo.com&show_title=1&show_byline=1&show_portrait=0&color=&fullscreen=1"><embed allowfullscreen="true" allowscriptaccess="always" height="300" src="http://vimeo.com/moogaloop.swf?clip_id=3387846&server=vimeo.com&show_title=1&show_byline=1&show_portrait=0&color=&fullscreen=1" type="application/x-shockwave-flash" width="400"></embed></object>
Here I'm doing a couple of searches using Komodo's Vi mode. That highlighting makes a big difference for helping your eyes find where you want to navigate to.
Find highlighting is one of those "well, duh" features that we are now able to add with indicator support in Komodo's editing component Scintilla. Indicators in Scintilla allow one to put visual markers on regions of the editor buffer independent of the syntax coloring information. Before indicators, syntax coloring styling and other styling (squiggly underlining for syntax errors/warnings, find highlighting, ...) had to share 8-bits of data for each position (i.e. each character). That was awkward (playing with bit masks) and limiting (ran out of space in, e.g., HTML which uses 7 of those 8 bits for all the different syntax coloring styles). Another example is Komodo's Tabstops -- which were made a lot more usable in 5.0 because of what we could do with indicators.
We've added support for a new platform: Linux/x86_64. This is our first native 64-bit platform build. Linux x86_64 installs are getting to be quite common, and typically the default install of Linux distros on x86_64 don't include the 32-bit compatibility libraries. This means that attempting to use Komodo's 32-bit Linux build wouldn't work out of the box (it tends to work fine once the distro's 32-bit compat libs are installed) -- and hence was a common support issue. Hopefully, no more. As well, Linux/x86_64 users will possibly enjoy a slight performance benefit.
Way back in the heady days of 2008 (before Komodo 5.0 was released) Davide Ficano (aka dafi) made this post on Komodo's forums:
that kicked off some starter work towards localizing Komodo. One of the necessary steps to getting good localizations of Komodo was to update Komodo's chrome to more rigorously use DTDs for XUL (we were using these fairly well) and string bundles for JavaScript code (we weren't doing so well here). Dafi whipped up a bunch of patches for this. Todd has finally managed to get those all checked in, so that Komodo is now in a pretty good state to start being localized.
In addition to the above, Komodo's History feature is coming along:
As well we've a few more goodies that should be ready to show for a beta 1 release in a week or two. As ever, try out the Komodo nightly builds for the very latest stuff:
I and others here have been hard at work on Komodo 4.3 (due to go final this week) so it has been a while since I've posted. One thing I've wanted to post about for quite a while is the Komodo auto-update system. I alluded to it waaay back when working on adding auto-update support to Komodo 4.2 but haven't written anything about it since.
Last Friday gives me good reason to post about it: We now have a "nightly" channel for Komodo Edit!
Update (4-Nov-2008): Nightly updates should not work for Komodo IDE as well!
There are three Komodo auto-update "channels":
"release": This is the typical (and default) channel for installations of a final release of Komodo (e.g. 4.2.0, 4.2.1, 4.3.0). On this channel, Komodo will only update itself to the latest final Komodo release.
"beta": This is the typical (and default) channel for Komodo alpha/beta builds. On this channel, Komodo will update itself to the final or pre-release (i.e. alphas and betas).
"nightly": This is a channel that I finally got working on the server-side on Friday. Since the announcement of OpenKomodo and open sourcing of Komodo Edit we've been doing "nightly" builds of Komodo Edit (built on most nights :). These are publicly available here: http://downloads.openkomodo.com/komodoedit/nightly/
As of last Friday, if you are on the nightly update channel Komodo Edit will update to the latest nightly build. These are quite a bit more burning-edge that the "beta" channel. Often the only criteria for putting up a nightly is that the build worked for all platforms. So, occasionally some features are broken -- though I think we do pretty well.
This channel is quite new for us though, so there may be some growing pains in the first couple of weeks. Please let me know if you have any problems with it. I think it will be pretty cool to easily always be running the very latest Komodo Edit.
At this time we aren't yet doing public nightlies of Komodo IDE.
Currently there isn't a prefs panel in Komodo to tweak auto-update settings -- such as the channel you are one. There should be. I hope to get one in sometime after 4.3.0.
To set your Komodo channel edit "channel-prefs.js" in your Komodo installation as appropriate. On Windows and Linux this file is here:
INSTALLDIR/lib/mozilla/defaults/pref/channel-prefs.js
and on Mac OS X here:
INSTALLDIR/Contents/MacOS/defaults/pref/channel-prefs.js
It is a very simple file that looks like this:
// Valid values are "release", "beta" and "nightly" (internal-only).
pref("app.update.channel", "beta");
Happily that "internal-only" is no longer correct for Komodo Edit.
Update (4-Nov-2008): Ditto for Komodo IDE now.
Komodo's auto-update system, on the client side (i.e. the app), pretty much just uses the excellent Mozilla auto-update system. On the server-side we have our own (very simple) Django-based update server. On the build-side, we have our own Python scripts (mozupdate.py et al) for building all relevant partial and complete update packages as part of full builds.
I hope to post more about our AUS server and about our build tools. I think I could fairly easily package up our tools to provide a possible answer to Mozilla Bug 415181 (Package the MAR generation tools for easy external usage).
There used to be an open bug (found it: Mozilla Bug 375752) to convert some of the Bash shell scripts for Mozilla update package building to Python scripts. I see (by way of Mozilla Bug 410806) that that has at least partially happened with make_incremental_updates.py.
We (ActiveState) released Komodo 5.1.3 today. Get it here:
Or, if you are currently running any previous Komodo 5, click "Help > Check for Updates...". This is a bug fix release and is recommended for all users. See below for details.
Some bug fix highlights:
The fast open (aka "Go to File") dialog had a few improvements:
Ctrl+n & Ctrl+p keybindings for down/up navigation for Emacs-heads. (Bug 82678)Komodo's Vi Emulation is ever improving:
There have been a number of improvements for using Komodo's color schemes and package (.kpz) files. More on that in a separate post later this week.
One of the side-effects of the work for color schemes is the addition of
<notificationbox id="komodo-notificationbox"/>
in komodo.xul. This may be of interest to Komodo extension authors that would like to use a notificationbox instead of alert dialogs or other mechanisms to give feedback to users.
Eventually I think Komodo's editor tabs should also grow a notification box -- as Firefox has one for each browser tab.
Again, goofy from babelzilla has been diligently providing localization patches for Komodo: bug 82580, bug 82819, bug 82821, bug 82822, bug 82824, bug 82825.
A bug where terminating run commands on Windows would not always work was fixed. (Bug 82655) The right answer for being able to kill a process and its child processes on Windows is to use a Windows Job object. Answer courtesy of Benjamin Smedberg's killableprocess.py. Komodo now uses code based on this. I'd like to find the time to get something based on this into Python's core subprocess module.
See the Release Notes for a full list of changes.
For those who haven't noticed, Stan Angeloff has been doing some spectacular work in his HTML Toolkit and Tab Abbreviations Komodo extensions.


There was a bug in the Komodo 5.1.2 release from yesterday that broke attempts to terminate processes on Windows. This most commonly could affect debugging in Komodo IDE.
Komodo IDE 5.1 is a free upgrade for Komodo IDE 5.x license holders. Your license entitles you to run Komodo IDE on any of the platforms we support (Windows, Mac OS X and Linux). Komodo Edit 5.1 is, as ever, open-source and free.
Jan “Honza” Odvarko and I have submitted “Dynamic and Graphical Web Page Breakpoints” on the 1.5 breakpoints to WWW 2010. It motivates the various breakpoints, describes the user experience and the implementation, then relates this breakpoint work to academic papers.
If you want the Cliff Notes version, we also have a demo page. And of course if you like interactive versions, you can just install Firebug 1.5b1 and use the breakpoints on your project now.
jjb
« last meeting | index | next meeting »
SeaMonkey Meeting Details
(who needs to do what that hasn’t been recorded in a bug) We should assign people to the open items.
NEW
OPEN
CLOSED
Bug statistics for last two (full) weeks: 94 new, 17 fixed, 34 triaged.
Major wanted/needed features:
We also should take a look at the other items on wanted-seamonkey2.1+
Status Updates from developers – what are you working on, what’s the progress, any other comments? (feel free to add yourself to the list if your name is missing and you have interesting status).
Helping out in the Mozillazine SeaMonkey Support forum ;)
Working on:
Bugs Fixed:
Working on:
Bugs Fixed:
Working on:
Extension outreach:
Other:
Note:
Working on:
last meeting | index | next meeting »
Thunderbird Meeting Details :
Topcrashes 3.0b4
| status | bug | summary | rank |
| fixed 2009-10-04 | bug 513315 | @ nsScriptSecurityManager::GetCurrentJSContext() | 1 |
| fixed 2009-09-25 | bug 480090 | sending email after being in offline mode @ morkRowObject::CloseRowObject(morkEnv*) – @ nsMsgOfflineImapOperation::SetCopiesToDB – nsMsgOfflineImapOperation::Release | 2 |
| qawanted -all win7- | bug 522226 | startup @ __delayLoadHelper2 | 3 |
| FIXED 2009-10-14 | bug 505221 | @ CountTotalMimeAttachments(MimeContainer*) | 4 |
| fixed by bug 513315? | bug 518671 | @ nsXPConnect::GetRuntimeInstance() | 5 |
| idle, multiple bugs?, “needs a cycle collector hacker” | bug 482849 | @ canonicalize while doing a nightly update | 6 |
| idle | bug 519962 | startup nsPrefBranch::Observe(nsISupports*, char const*, unsigned short const*) | 7 |
| +needs more triage | various: bug 523423, bug 514734, bug 495177 | JS_CallTracer bad GCs? | 8 |
| FIXED (we hope) by bug 505221 | bug 513543 | @MimeInlineTextHTML_parse_eof (can’t verify via crash-status until 3.0rc) | 9 |
| needs triage | no bug filed | @ JS_dtobasestr | 10 |
Done / Cleared
In Progress
TODO
crash triage
Last week:
This week:
$HOME\Application Data\Mozilla\Extensions\{718*\calendar-timezones@mozilla.org
~/.mozilla/extensions/{718*/calendar-timezones@mozilla.org
« previous week | index | next week »
Firefox 3.0.16 / Firefox 3.5.6
Firefox 3.6 Beta
Firefox 3.6 Release Candidate
See more Firefox 3.6 related blocker queries, or learn about the new status and blocker flags
(Progress reports every weekend on Planet Firefox)
Join us on IRC in #startup.
| feature | review date | who | interested |
|---|---|---|---|
| Windows TSF integration (1.9.2) | unscheduled | Jim Chen, roc | |
| DNS Prefetching | unscheduled | Patrick McManus | Jesse, bz, reed(?) |
| Mail config from ISP (Tb3) | unscheduled | Ben Bucksch | |
| New system metrics (and media queries) | unscheduled | ? | dbaron |
Upcoming this week:
Plugins are in important part of the browsing experience. That is why we could use your help testing the fix for https://bugzilla.mozilla.org/show_bug.cgi?id=525533. Here is what you need to do tomorrow when the fix will have landed:
1. Update to the latest 1.9.2 Mac nightly build or download the latest Mac 1.9.2 nightly from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/
2. Comment 5 in the above referenced bug has some suggestions of what to test - basically some of the following items would be helpful:
- Flash instances hidden by a new tab, make sure audio does not cut out
- Gmail voice chat, make sure audio works without skipping even when tab is
hidden
- YouTube, make sure videos play without skips and at the correct speed when
not hidden
- Hulu, test video speed and audio as in the suggestions above
Please report bugs you see in bugzilla.mozilla.org or ping marcia on irc.mozilla.org in
the #qa channel if you see something that does not look right.
As always, thanks for your testing efforts.
We will have a scheduled maintenance window tonight from 7:00pm to 11:00pm PST. The following changes will take place:
support.mozilla.com update. We’ll be updating support.mozilla.com to pick up code updates (bug 526284) . Duration 60 minutes. getpersonas.com update and database upgrade. We’ll be updating getpersonas.com to pick up code updates (bug 526291) and moving its database to a different database cluster (bug 521597). Duration 10 minutes. smtp.mozilla.org configuration change. We’ll be removing mozilla.com and mozilla.org from the authorized recipients list on the inbound mail servers, since they are no longer used as the MX for those domains (bug 524804) No downtime expected.
www.mozilla-europe.org GLB DNS change. We’ll be making DNS changes to move www.mozilla-europe.org to our Zeus GLB servers (bug 523711). No downtime expected.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.
I just had a meeting with assorted people related to the Mozilla Developer Center work that’s ongoing, including reps from MindTouch and our own IT team. I figured it would be good to summarize what’s going on.
The test server for MDC that we’ll be using to check out updates before actually installing them is expected to be ready today. I’m working with IT and QA to schedule testing work on that, so we can roll it out as soon as possible.
We’ll also use the test system to try out the new reCAPTCHA plugin; once that’s confirmed to be working for us, we’ll be able to re-activate user registrations on MDC, which will of course be a huge win for both openness and my sanity.
The 9.08.1 update will not, unfortunately, resolve all of our problems. However, it should make restarting the site rather more reliable than it is now. We do expect to continue to have to restart periodically due to memory leakage by the Mono runtime on which MindTouch is based. The Mono team is aware of these problems, and they’re working on an improved garbage collection system, but that’s not looking like it will ship until sometime in the first half of next year.
The next major release of MindTouch, code-named Noatak, is tentatively scheduled to ship around the end of November (it’s slipped from its original November 12 target date, which I expected). MindTouch intends to resolve all of the non-Mono-related issues we’re having with reliability by that time. In addition, they plan to offer support for CKEditor 3.0, a much-improved editor that we look forward to being able to use.
Plans are starting to formulate for the features we intend to implement once stability is addressed. Hopefully the reliability problems will start to ease up significantly over the next month to month and a half.

(Continuing the blogging blitz: here is pooling, part 3.)
The build pool consists of a number of identical build machines that can handle all builds of a certain category, across branches.
Builds on checkin Pooling lends itself to building on checkin: each checkin triggers a full set of builds. This gives much more granular information about each checkin: does it build on every platform? Does it pass all tests? This saves many hours of "who broke the build" digging. As a result, the tree should stay open longer. The tradeoff is wait times. During peak traffic, checkins can trigger more build requests than there are available build slaves. As builds begin to queue, new build requests sit idle for longer and longer before build slaves are available to handle those requests. You can combat wait times via queue collapsing: Once builds queue, the master can combine multiple checkins in the next build. However, this negatively affects granular per-checkin information. Another solution to wait times is adding more build slaves to the pool. |
Dynamic allocation As long as there are available build slaves, the pool is dynamically allocated to where it's needed. If one branch is especially busy, more build slaves can be temporarily allocated to that branch. Or if the debug build takes twice as long, more build slaves can be allocated to keep it from falling behind. (At Mozilla, this happens within Buildbot and requires no manual intervention beyond the initial configuration.) This is in direct contrast to the tinderbox model, where busier branches or longer builds would always mean more changes per build. Dynamic allocation adds a certain amount of fault tolerance. In the tinderbox model, a single machine going down could cause tree closure. In the pooling model, a number of build machines in the pool could fall over, and the builds would continue at a slower rate. The main drawback to dynamic allocation is that an extremely long build or an overly busy branch can starve the other builds/branches of available build machines. |
Self-testing process In the tinderbox model, one of the weaknesses was machine setup documentation. This can be assuaged with strict change management and VM cloning, but there's no real ongoing test to verify that the documentation is up to date. Since pooled slaves jump from build to build and from branch to branch, it's easier to detect whether breakage is build slave- or code/branch- specific. This isn't perfect, especially with heisenbugs, but it's definitely an improvement. In addition, every time you set up a new build slave, that tests the documentation and process. This happens much, much more often than spinning up new tinderboxes in the tinderbox model. |
Spinning up a new branch or build Since the pool of slaves can handle any existing branch or build, it's relatively easy to spin up a new, compatible branch or build type. It's even possible to do so by merely updating the master config files, with none of the "spin up N new tinderbox machines" work. However, new branches and build types do add more load to the pool; it's important to keep capacity and wait times in mind. As the full set of builds show, it's easy to lose track of just how much your build pool is responsible for. Still, I think it's clear that this is a big Win for pooling, as the number of active branches and builds at Mozilla are as high as I've seen anywhere. |
The tyranny of the single config It's very, very powerful to have a single configuration that works for all builds across all branches. However, this is also a very strict limitation. In the tinderbox model, a change could be made to a single machine without affecting the stability of any other builds or branches. Once that one build goes green, you're golden. In the pooling model, the change needs to propagate across the entire pool, and it affects all builds across all branches. As the number of branches and build types grow, the testing matrix for config changes grows as well. And at some point, new, incompatible requirements rear their ugly head -- maybe an incompatible new toolchain that can't coexist with the previous one, or a whole new platform. At that point, you need to create a new pool. And ramping that up from zero can be a time consuming process. |
I hope the above helps illustrate the pooling model and some of its benefits and drawbacks.
We don't just have a single build pool here, however; we have multiple, and the number is growing. This was partially by design, and partially to deal with growing pains as we scale larger and larger.
I'll illustrate where we are today in the next segment: split pools.
Last week Jonathan Kew and I went down to attend and present at ATypI 2009, a typography conference that took place in Mexico City this year. There was an entire day of sessions on web fonts. Jonathan and I presented a session on “Advancing Web Typography”:
In a session discussing font rendering, Simon Daniels from Microsoft announced that Microsoft was “considering” support for the WOFF font format! Other presenters focused on the differences in font rendering across platforms/browsers. There was also a lot of interest in better typographic controls in CSS.
Finally! Since July, we have been working on bug 470430. After lots of testing, reviewing and frustration, we have finally checked in the bug's patch. This bug is of quite central importance since we want to make sure that calendar data is not broken on an upgrade between versions, which was sometimes the case.
I would appreciate if everyone could take a look at the current nightlys to see if anything fails. Especially if you have an old profile (i.e from Sunbird/Lightning 0.8 or earlier) around, it would be nice to find out if upgrading from that profile works flawlessly.
If you have ever used Sunbird, please also check if you have the following directory:
C:\Users\<your username>\AppData\Roaming\Mozilla\Extensions\{718e30fb-e89b-41dd-9da7-e25a45638b28}\calendar-timezones@mozilla.orgC:\Documents and Settings\<your username>\Application Data\Mozilla\Extensions\{718e30fb-e89b-41dd-9da7-e25a45638b28}\calendar-timezones@mozilla.org~/.mozilla/extensions/{718e30fb-e89b-41dd-9da7-e25a45638b28}/calendar-timezones@mozilla.org~/Library/Mozilla/Extensions/{718e30fb-e89b-41dd-9da7-e25a45638b28}/calendar-timezones@mozilla.orgIf you do have this directory and it is empty, please report on bug 470430. Having it causes the upgrade process to fail, since the timezones files can not be found. My hopes are that this directory was created in error due to something in the development build process.
Now all we have left for our beta release is bug 494140, which will hopefully make it into the tree a bit sooner. Also, some locales need a few more strings. When all that is taken care of, then we can finally bring out release candidates for this beta release!
I'm looking forward to hearing from you and am excited that the beta is now one giant step closer.
UPDATE: We had a small regression, bug 526264. Upgrading from an older profile should work again after tomorrow's nightlys.
Several interpolation algorithms are available through the GDK and Cairo libraries which differ in the output quality. I’ve created two script that upscale a 500×122 pixels image by 2x to 100x
I was having a look at the referrals for kompozer.net and I found this page on TheFreeCountry.com. Among the list of free wysiwyg HTML editors, there’s this paragraph:
Nvu - Complete Web Authoring System
(Update: Nvu has been discontinued. Beware of scam sites pretending to be the Nvu website and asking for donations/support. The official site is gone, and there are no replacement sites. In the meantime, use KompoZer, which is just Nvu with some bug fixes and a new name.)
Obvioulsy, “beware of scam sites” refers to net2.com, which looks like Nvu’s official website. As such, it’s asking for donations/support for the Nvu project; since this site gets a lot of traffic, it probably gets much more financial support than kompozer.net itself. It does not mention anywhere that Nvu has been discontinued in 2005, and it only mentions KompoZer as an “alternative version”.
Of course, net2.com doesn’t do anything to develop Nvu and it doesn’t give any penny to the KompoZer project either: it’s just fooling donors and making money on the Nvu trademark and the good buzz that Linspire made back in the days. The sad thing is, the owner of net2.com is the former CEO of Linspire, which sponsorred the Nvu project.
By the way, nvu.com is not dead: it displays more ads than content, and it links to net2.com/nvu and kompozer.net (in this order). I would’ve preferred that this site doesn’t mention net2.com at all — but at least, it clearly explains that the Nvu project has been dropped in 2005. Ironically, this website is the main referral to kompozer.net (~3% of the visitors) after Google.
In the meantime, use KompoZer, which is just Nvu with some bug fixes and a new name.
This is a historical mistake of the KompoZer project: KompoZer 0.7 has been developed on an Nvu 1.0 code base, and the goal was only to propose a few bug fixes to the Nvu project.
The situation is very different now: KompoZer 0.8 has been developed on a clean Mozilla code base and it doesn’t share much code with Nvu any more. The 0.8 branch is taking a different approach: Nvu was designed as a beginner tool, KompoZer 0.8 tries to be both a good learning tool and to bring useful features for advanced users.
I’m very enthusiastic about the next development branch and the merge with SeaMonkey Composer, but we really need to get more visibility on this project before spending another year on it. Here’s a few things you can do if you want to help:
Side note: GNU/Linux users, please ask your maintainers to propose KompoZer 0.8 in your favorite distro. Some distros still ship KompoZer 0.7 with GTK ≥ 2.14, hence the crashes…
I’m aware I’m terrible in marketing and communication. If you have any suggestion to improve the visibility of the KompoZer project, please let me know!
I get mail on a number of contact email addresses @mozilla.org. Sometimes, people wrongly use these addresses to send support requests (for which I have a canned reply) or praise. Most of the praise is just "Wow, thanks!" but occasionally something comes in which is a bit out of the ordinary:
Dear dear guys and gals of Firefox s/w and bug fixes...THANK YOU, THANK YOU, THANK YOU !!!!!
Thank you all for releasing me from the handcuffs, tyranny, vile and cat-o'-nine-tails of Microsoft Explorer and all its attendant BS, hype and unimaginable insane (and foreseeable!) problems!
In my heart and soul you are ALL heros (and hero-esses?!) and stars in the internet firmament !!!
May your light shine forever in the integalactic realm of truth, righteousness and ALL that is GOOD!
More power to your keyboarding souls and fingertips! :o)
Give yourselves (and/or each other [more fun, that!] :oD ) a great big hug!!!
(...or 'high-fives' if you're not yet that close! LOL )Bless you all - may your souls forever surf the infinite with brightness with freedom of spirit and goodness!
Cheers,
<name removed>
I'm off to shine a bit more light into the integalactic realm of truth and righteousness...
The word Mozilla has been used many different ways* over time and that’s understandable—the community is big and diverse and is doing a lot of different things. There are distinctions within the community that are important to make, but I think it’s helpful to also focus on the connections that hold everything together.
It’s interesting to see how other big, distributed groups handle this. For instance, Greenpeace is composed of over 20 regional autonomous offices around the world and everything is referred to collectively as one thing. This makes it easier to understand its mission since new people don’t get bogged down in technical details that are less important than what Greenpeace does.
I’d like to see our community do a similar thing and develop a One Mozilla message. This would mean phasing out references to specifics, such as the many different Mozilla legal organizations, in favor of talking about just Mozilla.
This is already happening** and I wanted to point it out and encourage us to think through what else we could change to make our story clearer. I’ve set up a One Mozilla List of Tweaks wiki page with a few ideas and you’re welcome to add to that or leave suggestions on this post.
* I can’t resist the floor wax and dessert topping reference again…
** The Firefox 3.0.12 release mentions ‘As part of the Mozilla Corporation’s ongoing security and stability process‘ and the Firefox 3.0.13 release says ‘As part of Mozilla’s ongoing stability and security update process‘.

Sumo
Knowledge Base
Live Chat
Roundtable
In this issue…
Firefox 3.6 beta 1 available
Firefox 3.6 beta 1 was released last week. This beta is built on the Gecko 1.9.2 rendering engine and introduces several new features including built in Personas, automated plugin update notifications, full screen video, support for a new open font format, improved responsiveness and performance, and support for new CSS, DOM, and HTML5 technologies. Further information about this release is available at the Mozilla Developer Center and at the Mozilla Hacks weblog. You can download the beta through Mozilla.com.
Updating add-ons for Firefox 3.6
The AMO team has put together a quick five step program that developers can use to check compatibility with Firefox 3.6 and update their add-ons if necessary. “The add-on review queues are normally very busy during update times, so you should follow these guidelines to make sure your add-on stays up to date and doesn’t have to wait too long for review.” The team has also launched a new AMO forum if you have any questions or comments, and a new Compatibility Reporter tool is available to help developers know which add-ons work with Firefox 3.6.
Light the world with Firefox
“We’re coming up on a pretty incredible milestone,” writes Mary Colvig, “Five Years of Firefox on November 9, 2009! In order to celebrate we’re kicking off a special campaign called ‘Light the World with Firefox.’ We’re putting a call out for the most creative use of the Firefox logo and light.” To read more about participating in this world-wide event, see Mary’s blogpost over at the Mozilla Blog.
Jetpack Design Challenge
Mozilla Labs and the Mozilla Foundation, with support from the John D. and Catherine T. MacArthur Foundation, are sponsoring a Jetpack for Learning Design Challenge. “We are looking for designers, educators and software developers who want to turn their innovative ideas about learning online into working prototypes in the form of Firefox add-ons. We’ll help you refine your designs and teach you how to create Firefox add-ons using Jetpack and other Mozilla technologies. Participants creating the best prototypes will be invited to the Jetpack for Learning Design Camp and the SXSW Interactive conference in March 2010.” Read the full post at the Mozilla Labs weblog.
Firefox privacy and security
Johnathan Nightingale and Drew Willcoxon have put together two new videos in which they talk about the security and privacy features of Firefox. The security features video covers phishing protection, malware protection, master passwords, the site identity button, and Firefox’s world-class software update system. The privacy video talks about the great new privacy features that were introduced with Firefox 3.5. You can view these at Johnath’s weblog, or through YouTube: Security, Privacy.
On open source and education
Professor David Humphrey, from Seneca College in Toronto, has an
excellent blog post about teaching with open source, and the
incredible impact it has on the value and quality of his students’
education. The article is in response to Joel Spolsky’s post lamenting the general quality of computer science programs and arguing for the inclusion of real-world projects in these programs. This is, of course, exactly what David has been working on at Seneca for five years, and the results have been astonishing. Read David’s full post on his weblog.
Multi-process Fennec
Joe Drew, Olli Pettay, and Benjamin Smedberg have modified Mobile Firefox (aka: Fennec) so it now has a separate process for rendering. “Getting Fennec working was difficult partly because the mobile Firefox code uses a different drawing system. Now that it’s working, we hope to be able to bring additional developers in to fix up the features we hacked around, fix DOM features, and start getting much better measurements for interactive performance and memory usage.” If you’re interested in reading more, seeing a screencast of Fennec in action, or getting involved with Fennec development, head over to Ben’s weblog.
SUMO and Firefox 3.6 progress
Chris Ilias, part of the Firefox Support (SUMO) team, writes, “For the past few weeks we have been gathering a list of changes from Firefox 3.5 to 3.6. The next step is to go through the list of articles and determine which need to be updated, and everyone can help.” Chris’ post goes on to explain exactly what you need to do if you would like to pitch in to get SUMO ready for the upcoming Firefox 3.6 release.
New features in Firebug 1.5
Jan Odvarko has been blogging about some of the new features in Firebug 1.5, including HTTP time monitor, XML explorer, and Net Panel column customization. In his most recent post, Jan talks about the new Break On Next functionality. “This feature extends the idea of breakpoints, which is one of the cornerstones of today’s debugging tools. Its primary goal is breaking the JavaScript execution at a required place in the code that is unknown to the developer beforehand.”
Mozilla Drumbeat: pilot mode
Mozilla Drumbeat is moving into pilot mode. Be a part of Drumbeat and dial in to the weekly Drumbeat Community call. The call is Mondays at 8 a.m. PST. Further information about the call and new Drumbeat newsgroup is available on the Mozilla wiki.
Mozilla.org: new “Get involved” page
The Mozilla.org site has a brand new “Get involved” page, and is looking for help figuring out what steps to take next. “We’ve had a good response so far, but getting the page up is only the beginning for what we could be doing. How do we get more people to this page? What’s the best way to help people get started when they express interest? Would having mentors for different community areas be useful? If you’re interested in these questions, please come by our next contribute group call.”
Building the Mozilla Developer Network
Mozilla’s Marketing and Evangelism teams need your help. “We’re looking for developers from all over the Web to help us build the Mozilla Developer Network. Firefox is an important tool for many developers and as the Web continues to evolve as a platform, we need your input to enable better communication and collaboration to push the Mozilla project forward and make the Web better for everyone.” The first thing you can do is take the MDN Survey, then head over to the Mozilla Hacks weblog to get more information about what the team is working on and how you can help.
Upcoming events
The Mozilla community is organizing an increasing number of events and meetups all the time, and we include a list of these here every week. If you have events you would like listed, send them along to: about-mozilla*at*mozilla.com.
* Nov 7-8 – Sofia, Bulgaria – DevGarage
Developer calendar
For an up-to-date list of the coming week’s Mozilla project meetings and events, please see the Mozilla Community Calendar wiki page. Notes from previous meetings are linked to through the Calendar as well.
About about:mozilla
about:mozilla is by, for and about the Mozilla community, focusing on major news items related to all aspects of the Mozilla Project. The newsletter is written by Deb Richardson and is published every Tuesday morning. If you have any news or announcements you would like to have included in our next issue, please send them to: about-mozilla[at]mozilla.com.
If you would like to get this newsletter by email, just head on over to the about:mozilla newsletter subscription form. Fresh news, every Tuesday, right to your inbox.
One of my obsessions has been telling the Mozilla story better. The most important elements of this story centre around topics like: ‘why we exist’ and ‘what we’re building’. Yet, we sometimes get caught up in ‘how we’re structured’ — which tends to confuse more than clarify.
We’ve come a long way on this front: we’re getting better at telling the world a simpler, more unified story about Mozilla. All around I hear people talking confidently about ‘Mozilla’ — the project and the community with a mission to create a better internet. And I see fewer public references to all the different pieces that make up Mozilla. This is important.
One core element of this is simply leading with the word ‘Mozilla’ rather than focusing on structure. It’s worth pausing to call out a few specific examples. You might not even have noticed them.
1. The marketing team came up with new ‘About Mozilla’ boilerplate text for the Firefox 3.5 launch:
Mozilla is a global community of people creating a better Internet. We build public benefit into the Internet by creating free, open source products and technologies that improve the online experience for people everywhere. We work in the open under the umbrella of the non-profit Mozilla Foundation. Everything we create is a public asset available for others to use, adapt and improve.
This tells the big picture Mozilla and mission story well, and is a useful tool for any org, team or community within Mozilla. It doesn’t focus on which entity is doing the talking, which the old one did.
2. We’re now using the same business card logo and design across all parts of Mozilla. This may seem small — but it’s critical to remember that all of our small decisions add up to tell a bigger story. They’re important.
3. The main page of Mozilla.com no longer highlights Mozilla Corporation. It simply talks about our products (the main idea) and about ‘Mozilla’.
4. mozilla.org has was relaunched earlier this year with an even stronger focus on our mission and our community, and a clear framing of how our products fit into bigger commitment to building a better internet.
The bottom line in all of these examples: we should use a single, unified Mozilla brand across all of our public communication. While Mozilla is diverse and made up of many pieces, there is still one core story to tell about who we are and what our mission is.
Of course, none of this changes the fact that Mozilla is made up of distinct legal organizations performing distinct functions. This is part of who we are and it’s something we’re transparent about. We obviously need to spell out full organization names like Mozilla Foundation and Mozilla Corporation when talking about this aspect of who we are. It’s also necessary for certain functions tied to one org, like taking donations. But we shouldn’t tie communication about our mission and what we do to names that essentially describe our structure. If people want to understand this aspect of Mozilla, the best place to point them is the recently updated ‘organizations’ page on mozilla.org.
One last point: it’s amazing to see so much community creativity offered up to shape and improve how Mozilla’s story gets told. Any time I’ve asked for ideas on this topic, I’ve been deluged in the best possible way. I am truly grateful and astounded. David Boswell has offered to help to develop things like a style guide, slide templates and a sponsorship kit as a way to keep the ball rolling on some of the threads above. He’s also started a ‘list of one mozilla tweaks’. There is an open invitation for you to get involved. We need help make these things happen.
Posted in messaging, mozilla, poetry
We landed support for a form of CSS gradients on trunk a while ago, but we got considerable feedback that our syntax --- which was an incremental improvement of Webkit's syntax, which basically exposes a standard gradient API in the most direct possible way --- sucked. A bunch of people on www-style got talking and Tab Atkins produced a much better proposal. Since we haven't shipped our syntax anywhere yet, dropping it and implementing Tab's syntax instead was a no-brainer. So Zack Weinberg, David Baron and I did that (using a -moz prefix of course), and today it landed on trunk. It should land on the Firefox 3.6 branch shortly. It's unfortunate to land something new like this after the last beta, but in this case, it seems like the right thing to do instead of shipping CSS gradient syntax that we know nobody wants.
This does mean that anyone who's currently using -moz-linear-gradient or -moz-radial-gradient on pages is going to find that their syntax doesn't work anymore. Hopefully that's not too many people yet.