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

←

• Started looking again at making Places query APIs async, bug 490714. First need to tackle bug 499985, sorting of query results should be done entirely in SQL.
• “Helped” bz with test failures in blocker bug 526178, binding loading order changed in 3.6b1 compared to previous version of firefox.
• Awaiting Josh’s review on bug 506814, get rid of / Change GetPersistentDescriptor / SetPersistentDescriptor. Spoke to him last week, think he’s pretty busy with more important things.

→

• Work on bug 499985.
• Been thinking about the gap between the Places database and its query code and the janky structure that bridges it. Think more about it, with intensity.

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.

Tab matches in Awesomebar

Status

• UI works better now
• Initial work on proper integration into nsPlacesAutocomplete

Loose ends

• None

Next steps

• Finish autocomplete work
• Preferences UI
• More unit tests
• More unit tests
• More unit tests

Target for next week

• Finish autocomplete work + preferences UI

Binding for untrusted text in security dialogs

Status

• No change

Miscellaneous

• Had my first day as a Sheriff on Tuesday – worked out pretty well
• Also had my first security review on Tuesday, for the Plugin Update Awareness project  – that went pretty well too
• New Windows box arrived on Wednesday – now running Windows 7 as my main OS
• Working on moving all my development over to Windows

Reflections

• Having the right tools can make a difficult job into a trivial job
• Pizza and coffee are always the right tools

Related posts:

1. Status update
2. Status update
3. Status update

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.

• Issue 2458: Firebug does not stop JS when debugging events
• Issue 2456: Embedding firebug service in a non-XUL app cannot getService for nsIXULAppInfo

jjb

Followups to the newsgroup please

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.

Update:
Two photos from FSOSS.

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:

• The numbers for this month are:
• 1,692 code changes to our mercurial-based repos, which triggered:
• 20,887 build jobs, or ~90 jobs per hour.
• 46,219 unittest jobs, or ~62 jobs per hour.
• 42,873 talos jobs, or ~57 talos jobs per hour.
• This was our 2nd busiest recorded month, only slightly below last month’s record high.
• The busiest day was 6th October, with 102 checkins. For comparison, this high level was only exceeded on 22nd Sept (116 checkins) and 20th May (108 checkins).
• The number of unittest and performance jobs run has increased significantly. This is because a) we added new suites, b) we enabled existing suites on more branches and c) we split some suites into smaller, quicker, self-contained suites.
• We are still not tracking down any l10n repacks, nightly builds, release builds or any “idle-timer” builds.

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.

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:

• Taking Flight with Jetpack: Next Gen Add-ons for Firefox – Aza Raskin
• Mobile Firefox Add-on Development – Mark Finkle
• The Future of the Add-on Ecosystem – Nick Nguyen and Justin Scott

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.

ShareThis

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.

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.)

Implemented UI

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.

Implemented properties

Here are some of the implementations of inherited properties that exist in my extensions:

1. (GlodaQuilla) Index in Global Database – suppresses the running of the global database indexer
2. (FiltaQuilla) Apply Filters to Folder – for Imap folders, allow incoming filters to run on that folder
3. (JunQuilla) Analyze Junk – allow junk processing to be turned on or off. This also allows junk processing to run on RSS or news folders.
4. (TaQuilla) Analyze particular automatic tags.

Issue: Existing mechanisms

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.

Issue: My RDF-inspired property for junk management

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.

Issue: Missing inheritance levels

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.

Issue: UI for global 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:

• Enabling and disabling cookies – which covers cookie settings and how to make sure cookies are enabled when a website tells you that you need to have cookies enabled.
• Deleting cookies – which covers how to clear cookies for a single site and how to clear all cookies.
• Blocking cookies – which how to block individual websites from storing cookies.

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.

The 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.

Runners Up

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!

Gerv Status 2009-11-06.

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.

More Mozilla-like

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.

Missing locales

KompoZer 0.7.10 is available in 21 languages; but so far, we have only 10 locales for KompoZer 0.8b1.

• 2 locales are almost ready: Dutch and Simplified Chinese. These locales are still available for KompoZer 0.8a4 but haven’t been updated for 0.8b1. It should require only a few minutes to update them…
• 5 locales could be easily updated from KompoZer 0.7.10: Hungarian, Japanese, Portuguese (Brazilian + European), Slovak. That should require about a day to update them.
• 2 locales could be updated from KompoZer 0.7.10 but need a little more work: Bulgarian and Czech. I’m not sure these langpacks are fully translated (especially for the Bulgarian one), and there are some known problems with accesskeys and shortcuts with the Czech langpack.
• 2 locales would need more work because they’re not supported by Gecko 1.8.1: Upper Sorbian and Esperanto. Both langpacks have been made by Michael Wolf. Michael, would you spend some time on these?

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.

Default download policy

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:

• KompoZer 0.7.10 (English) for Windows users
• KompoZer 0.8b1 (localized) for Mac OS X and GNU/Linux users

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.

Still a lot to do

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…

• in Komodo, select a code block, then click Code -> Untabify Region.
• in vim, type :%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…

• in Komodo, in Preferences -> Editor / Save Options, activate the option “Clean trailing whitespace and EOL markers”. Then open your document of choice and just save it again. However, when writing patches, you might want to refrain from keeping this option on at all times: It might result in confusion if a lot of lines are touched that do not have anything to do with the current patch. I wish there was a one-time way to run this, instead of a config option.
• in vim, type :%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:

• not mess with any source repositories
• not do any file-io that’s not really needed

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:

1. .../merged/browser/chrome/foo
2. l10n/ab-CD/browser/chrome/foo
3. mozilla/browser/locales/en-US/chrome/foo

Now it’s time to list some pitfalls that come with l10n-merge:

• If you’re passing the wrong dir for mergedir, nothing breaks. All build logic breakage would come from missing files, and due to the fallback to en-US, there are no missing files.
• l10n-merge, as compare-locales, doesn’t cover XML parsing errors inside entity values yet. Bug 504339 is filed, there are some tricky questions on reporting, as well as having to write an XML parser from scratch.
• l10n-merge only appends entities, but that’s fine 95% of the time. Only counter-examples are DTDs including other DTDs.
• People using l10n-merge need to manually maintain the merge dir. Pruning it via compare-locales is risky business if you specify the wrong path by accident, so I consider this a feature. But if you’re seeing Spanish in a French build, clobber the mergedir and build again :-)

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.

Firefox Fathead at Kiberpipa's entrance - by nitot on Flickr

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:

• Event Title: You’ve Come a Long Way, Foxy (hat tip)
• When: 19:00 on Wednesday, November 11
• Where: Kiberpipa Kersnikova 6, 1000 Ljubljana (map)
• What: 4-5 very short talks, followed by an evening of immense fun

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.

Related articles by Zemanta

• Firefox gains 30 million users in eight weeks (news.cnet.com)
• help build the mozilla developer network (hacks.mozilla.org)
• How to light the world with Firefox (chickswhoclick.wordpress.com)
• New Firefox Plugin Lets Users Dislike Facebook Feed Stories (allfacebook.com)

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.

• http://coop.deadsquid.com/2009/07/prevent-missing-files-in-your-hg-commit/
• http://robarnold.org/hg-qimport-my-bugzilla-patch-redux/
  

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) { $('

' + contents + '

').css( { position: 'absolute', display: 'none', top: y + 5, left: x + 5, border: '1px solid #fdd', padding: '2px', 'background-color': '#fee', opacity: 0.80 }).appendTo("body").fadeIn(200); } var previousPoint = null; placeholder.bind("plothover", function (event, pos, item) { $("#x").text(pos.x.toFixed(2)); $("#y").text(pos.y.toFixed(2)); if (item) { if (previousPoint != item.datapoint) { previousPoint = item.datapoint; $("#tooltip").remove(); var x = item.datapoint[0].toFixed(2), y = item.datapoint[1].toFixed(2); showTooltip(item.pageX, item.pageY,y+'s'); } } else { $("#tooltip").remove(); previousPoint = null; } }); var placeholder2 = $("#placeholder2"); var data2 = [ { data: js_large, color:"yellow"}, { data: python_large, color:"blue"}, ] var options2 = { series: { lines: { show: true }, shadowSize: 0, points: { show: true } }, xaxis: { zoomRange: [0.1, 300], panRange: [-1, 301], ticks: [0,[10,"10Docs"],[100,"100Docs"],[300,"300Docs"],], }, yaxis: { zoomRange: [0.1, 60], panRange: [-1, 61], ticks: [[0,'.'],[1,"1s"],[3,"3s"],[5,"5s"],[10,"10s"],[50,"50s"],[60,"60s"]], min: -1, max: 60 }, zoom: { interactive: true }, pan: { interactive: true }, grid: { hoverable: true, clickable: true }, } var plot2 = $.plot(placeholder2, data2, options2); placeholder2.bind('plotzoom', function (event, plot2) { var axes = plot2.getAxes(); $("#message-text2").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)); }); placeholder2.bind("plothover", function (event, pos, item) { $("#x").text(pos.x.toFixed(2)); $("#y").text(pos.y.toFixed(2)); if (item) { if (previousPoint != item.datapoint) { previousPoint = item.datapoint; $("#tooltip").remove(); var x = item.datapoint[0].toFixed(2), y = item.datapoint[1].toFixed(2); showTooltip(item.pageX, item.pageY,y+'s'); } } else { $("#tooltip").remove(); previousPoint = null; } }); }); </script>

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.

Improving Performance

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.

2009-11-05T02:13:35Z mikeal http://www.mikealrogers.com 2009-11-05T22:30:51Z http://mozillalabs.com/?p=3026

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 [...]

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.

Download the latest Test Pilot extension!

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!

2009-11-05T02:07:17Z http://pipes.yahoo.com/pipes/pipe.info?_id=e17f6e62b43c193f6e42e1a574b22118 Mozilla Labs Pipes Output 2009-11-07T12:15:16Z http://blog.getfirebug.com/?p=500

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 [...]

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!

• Issue 494: Enhancement Network Monitor adding sorting
• Issue 1682: Request to an asset on a server not found/resolved is no longer being displayed in net panel
• Issue 2324: net tab not showing requests in progress
• Issue 953: Duplicate menu entries on tabs when using SplitBrowser + Firebug on Linux
• Issue 2413: On Script Tab, “Break on Next” tooltip is backwards
• Issue 2419: Problem with checking context.window in inspector.js
• Issue 1488: Uninformative message when command line fails while NoScript enabled
• Issue 2422: Get Firebug & NoScript to play nicely together
• Issue 2416: Focus Issues in Inspect when Firebug is in standalone mode
• Issue 2428: Image preview not working
• Issue 1528: Style attribute “visibility” not included in autocomplete for live style changes
• Issue 1526: Visual indication for aborted requests
• Issue 2447: Inspecting <body> tag causes rulers to disappear from layout
• Issue 1047: Wrong timing on the Net panel

jjb

Please post followups to the newsgroup

Issue 2413: On Script Tab, “Break on Next” tooltip is backwards Issue 2419: Problem with checking context.window in inspector.js

2009-11-05T01:11:03Z johnjbarton http://blog.getfirebug.com Web Development Evolved 2009-11-07T09:00:38Z http://quality.mozilla.org/603 at http://quality.mozilla.org

Discussion Items

• Current Priorities check
  • Crash Investigation. The no.1 priority is Firefox crash investigation. See Crashkill wiki.
    • Additional notes (Tomcat)
      • Working on a list for the QA CrashKill Wiki with the Bugs from the Overall Crashkill List with Bugs that need steps to reproduce/testcases etc - also with a owner field for QA that is also open for interested community members) - should be done end of the week
      • (Discussion) - juanb will make a first pass of the crash list, and then send the notes out. the wiki page tracks what bugs are being looked, who's looking at it, and what steps are being worked on for those bugs
  • Fx3.6 beta work. quicker beta cycles starting this week. Testing still needed around major components and fix verifications
    • Plan for quick beta cycles: Spot checks (smoketest?), spot checks on l10n, and updates, at most.
    • Next Two Weeks: Identify areas where things are unclear: Windows 7 in general, session store, tabbed browsing, lightweight themes, plugins, odds and ends. Then spend quality time, a day of full-force FFT level testing on these areas.
      • (Discussion) - talk to beltzner and see which are the top areas/deltas to focus on. keep track of these on pre/post releases.
  • Fennec b5 work. A beta 5 is coming today or tomorrow. includes ~10 locales. Extra sets of eyes will help
    • (Discussion) - if person has a N810 or N900, work off of different locales; in addition to main functionality testing
  • Fx 3.5.5 testing. Al and team are working on release testing this week
    • Additional notes below
      • (Discussion) Partial updates from 3.5.3 to 3.5.5, since they turned off topcrashes for 3.5.4. shipping tomorrow
  • Your other work you have. Put them on a temporary backseat if you can.

• QMO Forum topic fields (aakashd)
  • currently, non-admin users cannot create forum topics. they can only comment in them. reasons is to block spam, but is this the best use of forum topics?
    • Forum will be fully back in function when is fixed (Tomcat)
      • (Discussion) Are these forums really being used? Mollum is filtering out about 60 spam messages a day, but that means only administrators and community leads can create forum topics. Only registered users can comment. Nearly every forum is closed.

• Shorter 3.next beta cycles (juanb)
  • Starting next week, we are looking at shorter beta cycles. How does this impact qa?
    • juanb: We need three people the day of shipping for spot-checks, l10n, and updates. Ongoing bug verifications as part of our day-to-day operations.

• Remote access to Lab Machines (marcia, raymond)
  • any new updates on this? Raymond was out this week, will resume next week.
    • Raymond can do this next week, work with marcia to set priorities
    • Request which ones to prioritize first? (See Inventory)
    • Machines will be opened on the team via VPN

• VM updates (abillings)
  • Any discussion on cleaning up old vms?
    • (Update) keeping XP w/ IE 7 around as webqa still uses it. known issue with ubuntu 9.0.4 and ogg audio issues
    • new Win 7 pro vm to be created, as it has enhancements
  • Fusion 3 licenses issued, new virtual machines are on FS, everything is a go.
    • Fusion 3 is now up on the file server. Update your license number on the virtulization page.

• Team hiring (timr, tchung)
  • project approaches and prioritization going into 2010
  • looking into contract services to assist with the daily grind work

Project Updates

• Firefox 3.0x, 3.5x (abillings)
  • Firefox 3.5.5 shipping 11/5 at 3:00 PM.

• Firefox 3.6 (juanb)
  • quicker beta turnarounds.  ETA next beta, 11/6 builds
  • See Discussion session for more

• Tegra (marcia)
  • Running the new OS and reporting and verifying bugs
  • Conference call with Nvidia scheduled for tomorrow AM

• Fennec (aakashd)
  • Candidate builds for b5 are out
  • What we're doing

• WebQA (stephend)
  • shipped SUMO 1.4.2 last night
    • working on 1.5/Selenium coverage (search/forums, particularly)
  • Five Years of Firefox testing underway (looking great)
  • working on AMO 5.3
  • closed out a few Mobile-page bugs
    • looks like the team wants them soon (we had no idea)
  • Mozilla.com 3.6 work ongoing
  • Personas work ongoing

• Weave Sync (tchung)
  • Weave sync 0.8 is out
  • beta is landing next week. Sync 1.0 is targeted before all hands in dec
  • feature is an extension that is targeting fennec and firefox integration by Q1/Q2 2010
  • Tracy will be driving the testing of smoketests, testplans, and filing bugs in the interim
  • Testday scheduled for 12/4 to do weave testing

• Mozmill Testcase automation (henrik)
  • Aakash is working on Add-ons manager tests
  • Software update tests have been revised by a community member (Maverick). Some issues have to be addressed.
  • A lot of back-end work has been done the last week
  • Started to clean-up broken tests

• QMO & Community (marcia, aakashd)
  • Trying to plan a mobile meetup for November. Awaiting word from dougt re: availability
  • Still have not had time to edit videos from MozCamp. Working with Lukas to carve out time.
  • Presenting at Independence High School this Friday
  • Testdays
    • L10n/Litmus Testday 11/20 changed to l10n+QA test Firefox Testday
    • Test Pilot Testday on 12/4 changed to Weave Beta Testday
    • ashughes will be assisting with Testday implementation and promotion

• Accessibility (marcoz)
  • Hunting new top crasher that first showed up in 3.6b1. No STR so far, and I can't reproduce, but hard on this one.
  • Tables-related patches landed on Firefox 3.6b2pre last Thursday, testing and watching crash-stats to make sure we didn't regress. So far looks good.
  • Pursuing another ARIA-related report which hasn't been formulated into a bug yet, but which might be a potential 3.6 regression. More on this over the next couple of days.

• QA Metrics ( Murali )
  • Windows code coverage data is generated. Coverage at 58 percent without jstest runs.
  • Exported code coverage data from native windows file format to XML.
    • Need to write scripts to transform XML to HTML report.
  • Working on POLISH bugs dashboard.
  • Minor improvements and consolidations done to dashboard

2009-11-05T00:39:23Z tchung http://quality.mozilla.org/home 2009-11-05T00:45:40Z http://weblogs.mozillazine.org/seamonkey/archives/2009/11/seamonkey_2_con_3.html

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.

• fixing Get All Messages (my only trip to C++ land)


• improving the Cookie Manager (making it searchable, among other things)


• adding the ability to delete bookmarks from search results (and working with Neil to make sure deleted bookmarks do not show up there anymore)


• writing several new or updated Help articles


• adding support for more Firefox-compatible command-line options


• adding UI for the MailNews Archive functionality


• supporting standard key and double click events in the new Download Manager


• adding support for multimedia keyboards to MailNews


• porting the Master Password workaround in time for SeaMonkey 2.0

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.

2009-11-05T00:20:59Z KaiRo http://weblogs.mozillazine.org/seamonkey/ 2009-11-05T00:20:59Z tag:blogger.com,1999:blog-18929277.post-7740719470656815276

Want to know how a popular extension like Personas gets built and released? Neither do I! Yet I know anyway. And I've written it down for your edification! So check it out.

2009-11-04T23:58:03Z 2009-11-04T23:58:00Z Myk noreply@blogger.com http://www.blogger.com/profile/01837818348188071923 tag:blogger.com,1999:blog-18929277 Myk noreply@blogger.com http://www.blogger.com/profile/01837818348188071923 Myk Melez working on Mozilla projects 2009-11-04T23:58:03Z http://mozillalabs.com/testpilot/?p=30

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 [...]

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!

Test Pilot 0.3

Download!

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.

A Week in the Life of a Browser

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.

Get Involved!

1. Install the latest “cuddlefish” version of Test Pilot, or become a Test Pilot if you haven’t join us!
2. Check the analysis or download the aggregated data samples from the Tab Open/Close study!
3. Share your questions and suggestions on Test Pilot discussion group or on Twitter .
4. Join the fun quiz: Tell us how long you normally stay on the Web everyday!

2009-11-04T23:33:02Z http://pipes.yahoo.com/pipes/pipe.info?_id=e17f6e62b43c193f6e42e1a574b22118 Mozilla Labs Pipes Output 2009-11-07T12:15:16Z http://hacks.mozilla.org/?p=2241

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 [...]

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.

2009-11-04T18:55:03Z Christopher Blizzard http://hacks.mozilla.org 2009-11-04T19:00:44Z http://mozillalabs.com/?p=3021

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 [...]

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!

2009-11-04T18:48:39Z http://pipes.yahoo.com/pipes/pipe.info?_id=e17f6e62b43c193f6e42e1a574b22118 Mozilla Labs Pipes Output 2009-11-07T12:15:16Z http://mozillalabs.com/weave/?p=33

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. Major [...]

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.

Major Features

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:

• Get the same results on the Smart Location Bar on each of your Firefox browsers, so you can get to your favorite sites with just a few keystrokes
• Continue what you were doing: have the ability to open any tab you have open on any of your Firefox browsers
• Keep the same list of bookmarks on all of your Firefox browsers
• If you use Personas, your currently selected Persona will be synchronized across your Firefox browsers
• Easily sign in to all your favorite sites using your saved passwords (this is especially handy on mobile phones, where it’s hard to type in complex passwords)
• Do it all securely: Weave Sync encrypts user data before uploading it to Mozilla’s servers, so that only you can access your data

What’s new in 0.8?

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:

• Incremental download support is much more aggressive at fetching data, with explicit priority given to your most important data first
• New preference and setup UI for both Firefox and Fennec, moving back to a much tighter integration with the applications
• Cut download size in half from 0.7
• Better feedback for sync progress and errors
• Many added bugfixes (see full changelog)

Getting Involved with Testing and Development

• Install Weave 0.8 (requires Firefox 3.5 or higher)
• Learn more about Weave
• Discuss, debate, and add to the design in the Weave forum
• Join us in #labs on irc.mozilla.org

– Mike Connor, on behalf of the Weave development team

2009-11-04T16:04:04Z http://pipes.yahoo.com/pipes/pipe.info?_id=e17f6e62b43c193f6e42e1a574b22118 Mozilla Labs Pipes Output 2009-11-07T12:15:16Z tag:blogger.com,1999:blog-18323498.post-4226212974362026837

In addition to our RelEng's blogging blitz I am going to blog about how our L10n release infrastructure works. In this first blog post I will explain our Firefox's coverage.

Scenarios

We currently have 3 scenarios:

• Repackages on change
• Nightly localized builds
• Release localized builds

Deliverables

What our different deliverables are:

• Langpacks (you can add a language as an add-on)
• Installers (we generate a different one for each platform)
• Complete and partial mars (these are generated for updating from one version to another one)

How many locales do we process:

• More than 70 and depends on each branch
• The number of locales per branch is determined by the all-locale's file of that branch

Key concepts

• compare-locales = it compares en-US strings with the strings of a locale showing the differences between the two of them.
• l10n-merged or merged = when a repackage is merged it means that if the locale has any missing strings then the English strings will be inserted. When we run compare-locales we tell it to create a "merged" directory in case the locale has any missing strings. When we create the installer if the "merged" directory exists the localized repackaged repackage will be based off that directory instead of the locales' repository. This ensures that it won't have any missing entities; avoiding this way any crash due to missing entities

How it works

Before I explain how each scenario works let me explain what makes them distinct:

• compare-locale. We run compare-locales in all 3 scenarios.
• l10n-merge. For releases we don't l10n-merge. We just use plain compare-locales.
  
• triggering. Repackages-on-change are triggered by localizers' pushes while the nightly and releases are triggered when the en-US build finishes.
• upload. Each scenario uploads to a different location (tinderbox-builds, nightly or releases)
• updates. Only nightly and release scenarios have updates
  

How the repack-on-change scenario works:

• We have a poller that polls for changes in all locale's pushlog and we poll every 15 minutes. The reason that we poll every 15 minutes is because it adds a huge load on the master if we did it in smaller periods of time. If we think about mc, 191 and 192 we poll more than 210 different pushlogs and that takes quite some load of our masters.
  
• When a change for that locale is detected it triggers the triggerable L10n builds for all 3 platforms.
• The deliverables for the locale are pushed to the tinderbox-builds directory on ftp.

How the nightly localized scenario works:

• Instead of being triggered by a commit change on one of the locale's repositories, it is triggered by the en-US nightly build for that platform.
• The nightly build triggers as many localized build jobs as the all-locale's file for that branch determines. This is accomplished in special buildbot schedulers that make use of the L10nMixin class by submitting a job per locale.
• The repackages are l10n-merged!
  
• The installers are uploaded to the nightly directories on ftp.
• Unlike the repack-on-change scenario we have updates for this type of builds and that is why you will get to see complete mar files under the latest-<branch>-l10n</branch> dir on ftp and partial mar files under the dated directories on ftp (NOTE that we don't keep the dated directories of localized builds forever as with the en-US builds).

 How the release localized scenario works:

• This scenario is pretty similar to the nightly one but it has few differences.
• The locales involved in the release are determined by shipped-locales and l10n-changesets and the revisions for each locale are specified in there.
  
• The repackages are not l10n-merged.
• We run l10n_verification to cross-check and make sure the repacks worked properly for the release builds.
• We upload each locale's installers in its own subdirectory rather than all of them under an "-l10n" directory.  For instance you can see all the Windows localized builds for 3.5.4 in here. You can also note that en-US is in its own directory and all the langpacks under the xpi directory.
  

I know I have gone way into details but I believe it is worth having it recorded all together for once and for all. More to come on my next blog with regards to Fennec!

EXTRA: What builders we do have:

• Firefox mozilla-{central, 1.9.0, 1.9.1, 1.9.2} {linux, macosx, win32} l10n build <- repack-on-change runs
• Firefox mozilla-{central, 1.9.0, 1.9.1, 1.9.2} {linux, macosx, win32} l10n <- nightly runs
• {linux, macosx, win32}_repack <- release runs
• l10n_verification <- cross checking
  

---

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

2009-11-04T15:45:48Z 2009-11-04T15:45:00Z armenzg noreply@blogger.com http://www.blogger.com/profile/18276390189080271638 tag:blogger.com,1999:blog-18323498 armenzg noreply@blogger.com http://www.blogger.com/profile/18276390189080271638 This blog has posts related to personal stuff, my experience with the Mozilla project, Seneca College and others 2009-11-05T17:28:52Z http://home.kairo.at/blog/2009-11/seamonkey_2_0_in_the_press

Here's a bit of an overview of press articles we got for the SeaMonkey 2.0 release. The English and German ones were collected by myself (we were pretty well-featured in German media), the French and Czech ones come from our respective localizers, Cédric and Pavel.
I've hidden two "easter eggs" in the English list that could help some of our users, by the way - a forum thread for ubuntu users (things are easier for some other Linux distros - openSUSE offers it in the build service and in upcoming openSUSE 11.2, and upcoming Fedora 12 also has SeaMonkey 2.0) and a link to the portable version that is available now.

English:

• theregister.co.uk: Mozilla's SeaMonkey 2.0 exits cryptobiosis
• cnet.com: Mozilla releases SeaMonkey 2.0
• mozillalinks.org: SeaMonkey 2.0 is here!
• slashdot.org: Mozilla Releases SeaMonkey 2.0
• lwn.net: SeaMonkey 2.0 released
• linux.com: Mozilla SeaMonkey 2.0 Released
• ubuntuforums.org: Seamonkey 2.0 released, ubuntuzilla needs tweak
• portableapps.com: SeaMonkey, Portable Edition
• it-chuiko.com: SeaMonkey 2.0 is ready
• internetnews.com: Mozilla SeaMonkey FINALLY hits 2.0
• h-online.com: Mozilla releases SeaMonkey 2.0
• ostatic.com: Mozilla Delivers SeaMonkey 2.0
• lifehacker.com: Mozilla SeaMonkey Updated to 2.0
• majorgeeks.com: SeaMonkey 2.0 Final
• maximumpc.com: SeaMonkey 2.0 Now Available
• applelinks.com: Mozilla SeaMonkey Project Releases SeaMonkey 2.0
• kabatology.com: Seamonkey 2.0 Released
• findmysoft.com: The New Features and Enhancements in SeaMonkey 2.0
• esoft.web.id: Mozilla SeaMonkey 2.0 Final: All you can do on the Internet you can do with SeaMonkey
• v3.co.uk: Mozilla SeaMonkey 2.0

German:

• heise.de: SeaMonkey 2.0 erschienen
• futurezone.orf.at: SeaMonkey 2.0 erschienen
• derstandard.at: Seamonkey 2.0: Mozilla-Nachfolger in neuer Version
• golem.de: Seamonkey 2.0 ist fertig
• pcwelt.de: Seamonkey 2.0 steht zum Download bereit
• zdnet.de: Mozilla veröffentlicht Browser-Suite Seamonkey 2.0
• winfuture.de: SeaMonkey 2.0 - Nachfolger der Mozilla-Suite
• pro-linux.de: Seamonkey 2.0 fertiggestellt
• linux-magazin.de: Browser-Suite Seamonkey 2.0 ist da
• webmasterpro.de: Mozilla Seamonkey 2.0 ist fertig
• t3n.de: Internet-Alleskönner Mozilla Seamonkey 2.0 ist fertig
• pc-professionell.de: Seamonkey 2.0 ist da
• macgadget.de: SeaMonkey 2.0 ist fertig
• tecchannel.de: Mozilla schließt kritische Lücken in SeaMonkey

French:

• 01net: Logiciel libre : SeaMonkey 2.0 à télécharger
• PC Inpact: SeaMonkey : une montagne d'améliorations pour la version 2.0
• Linuxfr: SeaMonkey 2.0 la suite Internet
• Silicon.fr: Navigateur web : la suite SeaMonkey 2.0 est en ligne !
• Generation NT: SeaMonkey : la suite Internet en version finale 2.0
• Clubic: Le navigateur tout-en-un SeaMonkey disponible en v.2.0
• PC Boost: SeaMonkey, le navigateur tout en 1, disponible en version 2.0
• Mac Generation: SeaMonkey passe la seconde
• Mac4ever: SeaMonkey : la suite communicante de Mozilla en version 2.0

Czech:

• mozilla.cz: Vyšlo SeaMonkey 2.0!
• czilla.cz: SeaMonkey 2.0
• root.cz: Vyšlo SeaMonkey 2.0
• lupa.cz: Přichází SeaMonkey 2.0, seznam novinek je dlouhý
• root.cz: Přichází SeaMonkey 2.0
• abclinuxu.cz: SeaMonkey 2.0
• slunecnice.cz: SeaMonkey 2.0: To nejlepší z Firefoxu a Thunderbirdu
• extrawindows.cz: Novinky: SeaMonkey 2.0, Simple Adblock, Unlocker a další
• mozilla-europe.org: SeaMonkey 2.0 - Moderní balík internetových aplikací je tu!

Oh, and here's a scanned image from the German IT magazine - c't (Edition of October 26th, page 52):

It's about RC2, but still cool to be present in that magazine...

2009-11-04T14:47:56Z KaiRo http://home.kairo.at/?d=w&i=1&m=v&c=atom&f.lang=en KaiRo's weBlog 2009-11-04T14:47:56Z tag:blogger.com,1999:blog-4035383417976188140.post-2395673668036544526

The Thunderbird developers have slightly revised their release schedule and are now planning to start the builds for TB3 RC1 on the upcoming Sunday or Monday.

As a result I'll be extending the opt-in period for all participating locales until next Saturday (November 7) 23:59 CET. Please post your changeset updates into the existing opt-in thread.

If you have any questions, feel free to ask them here or in the mozilla.dev.l10n newsgroup.

2009-11-04T09:43:19Z 2009-11-04T09:40:00Z Simon noreply@blogger.com http://www.blogger.com/profile/10893996574045557818 tag:blogger.com,1999:blog-4035383417976188140 Simon noreply@blogger.com http://www.blogger.com/profile/10893996574045557818 2009-11-04T09:43:19Z tag:perso.hirlimann.net,2009:/~ludo//1.3013

I'm going to start a new meme - as I find these funny and sometimes useful. Rules : Copy the rules in the beginning or at the end of your post Link to the person who tagged you Give the...

I'm going to start a new meme - as I find these funny and sometimes useful.

Rules :

1. Copy the rules in the beginning or at the end of your post


2. Link to the person who tagged you


3. Give the 5 websites you find useful, or that you use the most. Try to explain why !


4. Tag 5 people


5. The meme doesn't need to stay in english :-)

My Five favorite/most useful websites are :

• flickr, as photography is my passion , I couldn't share my pictures so easily without flickr.


• Le monde, a French newspaper, a good way to stay in touch with what's going on in my own country.


• upcoming , a nice service to find what's going on around , easily share it with friends.


• google - without which the internet wouldn't be what it is today I mainly use maps and search


• This website, which gives me the freedom to express myself and broadcast it to the world.

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.

2009-11-04T07:54:37Z 2009-11-04T07:31:02Z Ludovic Hirlimann http://perso.hirlimann.net/~ludo/ tag:perso.hirlimann.net,2008-12-11:/~ludo//1 Mon Journal en ligne. 2009-11-04T07:54:37Z http://www.squarefree.com/burningedge/?p=797

Fixes: Fixed: 523771 - Support <input type=file multiple>. Fixed: 513395 - Implement less awkward/more logical CSS gradient syntax. Fixed: 517902 - Reimplement image properties, using the existing "Media" panel. Fixed: 514490 - Per Tab Network Prioritization. Fixed: 515512 - Text urls that don't have the leading protocol should have the link context menu options when selected. Fixed: 436703 - Select all [...]

Fixes:

• Fixed: 523771 - Support <input type=file multiple>.
• Fixed: 513395 - Implement less awkward/more logical CSS gradient syntax.
• Fixed: 517902 - Reimplement image properties, using the existing "Media" panel.
• Fixed: 514490 - Per Tab Network Prioritization.
• Fixed: 515512 - Text urls that don't have the leading protocol should have the link context menu options when selected.
• Fixed: 436703 - Select all + Copy/paste in contenteditable div pastes the editable div inside itself.
• Fixed: 511503 - Need events for window focus / activation.
• Fixed: 509329 - Background image rendered incorrectly when window resized.
• Fixed: 521750 - Put a runtime NS_IsMainThread check in nsCycleCollector::Suspect2 and Forget2 (reduces frequency of crashes caused by several buggy extensions).

mozilla-central pushlog for 2009-10-23 04:00 to 2009-11-03 04:00

Windows nightly (discussion)

Mac nightly

Linux nightly

2009-11-04T06:47:06Z Jesse Ruderman http://www.squarefree.com/burningedge Developments in nightly builds of Mozilla Firefox 2009-11-04T07:00:09Z tag:blogger.com,1999:blog-1552913144533093368.post-7949454095652406525

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&amp;su=http://images.ted.com/images/ted/tedindex/embed-posters/DonNorman-2003.embed_thumbnail.jpg&amp;vw=432&amp;vh=240&amp;ap=0&amp;ti=480"><embed allowfullscreen="true" bgcolor="#ffffff" flashvars="vu=http://video.ted.com/talks/embed/DonNorman_2003-embed_high.flv&amp;su=http://images.ted.com/images/ted/tedindex/embed-posters/DonNorman-2003.embed_thumbnail.jpg&amp;vw=432&amp;vh=240&amp;ap=0&amp;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.

Miro

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.

2009-11-04T06:36:12Z 2009-06-04T20:57:00Z trentm noreply@blogger.com http://www.blogger.com/profile/12705610824898039421 tag:blogger.com,1999:blog-1552913144533093368 trentm noreply@blogger.com http://www.blogger.com/profile/12705610824898039421 2009-11-05T06:47:16Z tag:blogger.com,1999:blog-1552913144533093368.post-7089061623469928696

We (ActiveState) released Komodo 5.1.1 today. Get it here:

Komodo IDE: http://www.activestate.com/komodo/downloads/

Komodo Edit: http://www.activestate.com/komodo_edit/downloads/

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.

Bug fixes

Two important bug fixes in this release are:

1. 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).

2. 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.

A couple new features

This release also include two tweaks to existing features that didn't quite make the final 5.1.0 release.

Fast Open dialog

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:

• an absolute path: /etc/httpd/httpd.conf
• a relative path (where relative is relative to the directory of every tab you have open in your Komodo window): ../foo.py
• a path under your HOME directory: ~/wrk/coolstuff.rb

Note 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.

PerlCritic

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.

General information

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.

downloads	Komodo IDE | Komodo Edit
forums	http://community.activestate.com/products/Komodo
email	http://listserv.activestate.com/mailman/listinfo/komodo-discuss
bugs	http://bugs.activestate.com/enter_bug.cgi?product=Komodo

2009-11-04T06:33:36Z 2009-04-02T13:50:00Z trentm noreply@blogger.com http://www.blogger.com/profile/12705610824898039421 tag:blogger.com,1999:blog-1552913144533093368 trentm noreply@blogger.com http://www.blogger.com/profile/12705610824898039421 2009-11-05T06:47:16Z tag:blogger.com,1999:blog-1552913144533093368.post-3017447117010737975

We (ActiveState) released Komodo 5.1 today! Get it here:

Komodo IDE: http://www.activestate.com/komodo/

Komodo Edit: http://www.activestate.com/komodo_edit/

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.

Fast Open dialog

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&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=&amp;fullscreen=1"><embed allowfullscreen="true" allowscriptaccess="always" height="600" src="http://vimeo.com/moogaloop.swf?clip_id=3825622&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=&amp;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:

• switch to open tabs (especially useful if you have many many files open in Komodo),
• open recent files (tieing in with Komodo 5.1's new History feature),
• open files in the current directories (i.e. the directories of currently open files), and
• open files in your current project.

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

Re-open recently closed tabs

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.

Hyperlinks, Find highlighting, History

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&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=&amp;fullscreen=1"><embed allowfullscreen="true" allowscriptaccess="always" height="300" src="http://vimeo.com/moogaloop.swf?clip_id=3387846&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=&amp;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:

downloads	Komodo IDE | Komodo Edit
forums	http://community.activestate.com/products/Komodo
email	http://listserv.activestate.com/mailman/listinfo/komodo-discuss
bugs	http://bugs.activestate.com/enter_bug.cgi?product=Komodo

</enter>

2009-11-04T06:32:07Z 2009-03-24T05:41:00Z trentm noreply@blogger.com http://www.blogger.com/profile/12705610824898039421 tag:blogger.com,1999:blog-1552913144533093368 trentm noreply@blogger.com http://www.blogger.com/profile/12705610824898039421 2009-11-05T06:47:16Z tag:blogger.com,1999:blog-1552913144533093368.post-80461642555097073

We released Komodo 5.1 beta 1 yesterday! Get it here:

http://downloads.activestate.com/Komodo/releases/5.1.0b1/

Please try it out and give us your feedback:

email	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.)

Hyperlinks

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:

1. 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.

2. HTTP and FTP URLs:

   

   Ctrl+click will load that URL in your browser.

3. 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.

4. 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 updates

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:

1. make your edit;
2. possibly run koext build --dev, e.g. if you changed an IDL file; and
3. re-start Komodo

Instead of the more laborious:

1. make your edit;
2. run koext build to build a new .xpi file;
3. re-install that .xpi in Komodo;
4. re-start 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

Other stuff

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 a "duplicate line or selection" command.

• 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:

http://downloads.activestate.com/Komodo/nightly/

2009-11-04T06:29:30Z 2009-03-13T09:46:00Z trentm noreply@blogger.com http://www.blogger.com/profile/12705610824898039421 tag:blogger.com,1999:blog-1552913144533093368 trentm noreply@blogger.com http://www.blogger.com/profile/12705610824898039421 2009-11-05T06:47:16Z tag:blogger.com,1999:blog-1552913144533093368.post-7263285379066712357

We released Komodo 5.1 alpha 2 a couple of days ago (shame on me for not announcing until now). Get it here:

http://downloads.activestate.com/Komodo/releases/5.1.0a2/

Please try it out and give us your feedback:

email	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.)

Find highlighting

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&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=&amp;fullscreen=1"><embed allowfullscreen="true" allowscriptaccess="always" height="300" src="http://vimeo.com/moogaloop.swf?clip_id=3387846&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=&amp;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.

Linux/x86_64 support

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.

Localization patches from Davide Ficano (l10n)

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:

Localizing Komodo using Babelzilla dream team

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.

Other stuff

In addition to the above, Komodo's History feature is coming along:

• The same keybindings as your browser for Back/Forward should be working on all platforms.
• The side mouse buttons on 5-button mice should work for navigating the history.
• This history will now properly handle cleaning out URLs from finished remote debugging sessions.

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:

http://downloads.activestate.com/Komodo/nightly/

2009-11-04T06:27:00Z 2009-02-27T10:41:00Z trentm noreply@blogger.com http://www.blogger.com/profile/12705610824898039421 tag:blogger.com,1999:blog-1552913144533093368 trentm noreply@blogger.com http://www.blogger.com/profile/12705610824898039421 2009-11-05T06:47:16Z tag:blogger.com,1999:blog-1552913144533093368.post-3458316589919118921

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!

Komodo Auto-update channels

There are three Komodo auto-update "channels":

1. "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.

2. "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).

3. "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.

Setting the update channel for your Komodo installation

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.

Other Komodo AUS Stuff

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.

2009-11-04T06:26:00Z 2008-03-03T13:00:00Z trentm noreply@blogger.com http://www.blogger.com/profile/12705610824898039421 tag:blogger.com,1999:blog-1552913144533093368 trentm noreply@blogger.com http://www.blogger.com/profile/12705610824898039421 2009-11-05T06:47:16Z tag:blogger.com,1999:blog-1552913144533093368.post-3414577885133881821

We (ActiveState) released Komodo 5.1.3 today. Get it here:

Komodo IDE: http://www.activestate.com/komodo/downloads/

Komodo Edit: http://www.activestate.com/komodo_edit/downloads/

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.

Bug fixes

Some bug fix highlights:

• The fast open (aka "Go to File") dialog had a few improvements:

  • Tab now autocompletes instead of moving to the next match. This makes it much more natural (if you're used to the shell) to navigate directories in the dialog. (Bug 82677)
  • Removed duplicates in "Go to File" list. (Bug 82705)
  • Current search is aborted when the "Go to File" dialog is closed. (Bug 82529)
  • Added Ctrl+n & Ctrl+p keybindings for down/up navigation for Emacs-heads. (Bug 82678)

• Komodo's Vi Emulation is ever improving:

  • Comment/uncomment working correctly in visual line mode. (Bug 82369)
  • Fixed visual line selection mode indent/dedent problems. (Bug 82368)
  • The cc command now maintains line indentation. (Bug 82707)

• 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.

Komodo extensions

For those who haven't noticed, Stan Angeloff has been doing some spectacular work in his HTML Toolkit and Tab Abbreviations Komodo extensions.

What about 5.1.2?

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.

General information

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.

downloads	Komodo IDE | Komodo Edit
forums	http://community.activestate.com/products/Komodo
email	http://listserv.activestate.com/mailman/listinfo/komodo-discuss
bugs	http://bugs.activestate.com/enter_bug.cgi?product=Komodo

2009-11-04T06:16:52Z 2009-04-29T14:29:00Z trentm noreply@blogger.com http://www.blogger.com/profile/12705610824898039421 tag:blogger.com,1999:blog-1552913144533093368 trentm noreply@blogger.com http://www.blogger.com/profile/12705610824898039421 2009-11-05T06:47:16Z http://blog.getfirebug.com/?p=491

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 [...]

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

Follow up in the newsgroup please.

2009-11-04T05:57:23Z johnjbarton http://blog.getfirebug.com Web Development Evolved 2009-11-07T09:00:37Z http://blog.mozilla.com/meeting-notes/archives/260

SeaMonkey:StatusMeetings:2009-11-03 From MozillaWiki « last meeting | index | next meeting » SeaMonkey Meeting Details Time: November 03, 2009, 13:00 UTC Location: #seamonkey IRC channel Agenda Who’s taking minutes? -> Ratty Action Items (who needs to do what that hasn’t been recorded in a bug) We should assign people to the open items. NEW OPEN Get permission [...]

SeaMonkey:StatusMeetings:2009-11-03

From MozillaWiki

« last meeting | index | next meeting »

SeaMonkey Meeting Details

• Time: November 03, 2009, 13:00 UTC

• Location: #seamonkey IRC channel

• Who’s taking minutes? -> Ratty

(who needs to do what that hasn’t been recorded in a bug) We should assign people to the open items.

NEW

OPEN

• Get permission from Google to use their geolocation JSON service [KaiRo]. Contact at Google says: “We don’t have a good estimate for when GLS will be opening up more broadly, but I will be sure to let you know when we take that step. Sorry that I can not be more specific at this time.” – We can only wait right now.
  • KaiRo emailed Google again more than 6 weeks ago and again 3 weeks ago, no reply yet, even though the MoCo geolocation contact has poked the Google contact as well.

CLOSED

• Shipped on October 27!

• 167 fixed-seamonkey2.0 bugs (all post 2.0b2)!
• Pushed venkman perf hit and GetDefaultReader to 2.0.1.
  • The former needs at least a core patch landing for 1.9.1.6 (.5 will be a short-cycle crash-fixing update), the latter needs a new patch, we need progress on both fronts!
• 2.0 has 19 official languages including en-US, as well as a beta/unofficial Turkish version (requested by localizer due to incomplete L10n). More to come for 2.0.1 (or whatever it might be).
• Ratty has written to add-on authors to update their work for 2.0, not sure how much is going on there right now.
• What are we going to do wrt 1.9.1.5?
  • 2.0.1 will be based on 1.9.1.6 now as 1.9.1.5 is a crash-fixer release happening late this or early next week, and KaiRo doesn’t have enough time to generate a release this week.
• Feedback
  • Many positive messages.

  • Also many posts with problems, a few common threads among those:
    • Failure to launch when installed over 1.x – can we do something with removed-files? Ratty has filed bug 526202 on this issue.
      • Components dumped by extensions into the application/components/ directory are definitely a problem.
    • Some things already mentioned in Known Issues.
    • Profile migration failures – not sure how to diagnose these. Things like missing all passwords in migration are strange, but hard to debug especially if we don’t have access to the users system.
    • Quicklaunch from SeaMonkey 1.1.x still enabled, need to see if it’s possible/wanted to disable Quicklaunch during SeaMonkey 2 setup (should not be that difficult). IanN keep an eye on this issue ({bug|526204}}).
    • The new Password and Form Managers seem to be hard for people to grasp, do we need docs on those so we can point people to them? BenoitRen to file a bug and to contact people who can potentially help to do the documentation. There is an existing bug, bug 463903 for form autocomplete.
    • For some strange reason cut&paste isn’t working for some Windows 7 users. Specifically, nothing gets pasted.

Bug statistics for last two (full) weeks: 94 new, 17 fixed, 34 triaged.

• High rate of new bugs after 2.0 release.

• Fixing rate down as we all take a breath after this.
• We need to do triage of the incoming new bugs, most are UNCO.

Major wanted/needed features:

• bug 423281 Help updates.
  • No new progress, stefanh had been driving it but he’s been otherwise occupied for the last few weeks.

• bug 460953 kill-rdf port [sgautherie]
  • status/progress?
• bug 436794 Enable Mac OS X system address book per default and add UI.
  • SM UI needed, unowned, helpwanted.
• bug 410613 OpenSearch. helpwanted.
  • We need to check if OpenSearch can support all our existing functionality, for example the INTEPRETS section in Sherlock search plugins. Mnyromyr will check on that, and on how extensible the Firefox code is.
• bug 449728 drag tabs between windows
  • unowned so far.
• bug 498596 places bookmarks
  • unowned so far.
• bug 477845 Build a standalone (Gecko 1.9.1) Composer
  • Will look into that once KompoZer 0.8 and SeaMonkey 2.0 are done.
• bug 477840 Backport KompoZer to Composer
  • Will look into that once KompoZer 0.8 and SeaMonkey 2.0 are done.
• bug 523274 Complete new default theme icon set
  • status/progress?

  • A list of TODO icons is up in the bug
  • Still needs quite a bit of work.
  • bug 522023 is working on improving the browser globe in task icons, etc..
• bug 526210 Update the icon set for the SeaMonkey Modern Theme.
• bug 521927 Make Search, Folder Location and Views widgets for MailNews customizable toolbars.

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).

• Usual testing, reviewing and commenting.

• Bugs fixed:
  • bug 523943 Timezones Definitions needs SeaMonkey minimum correcting (on both comm-central and comm-1.9.1).

  • bug 515228 Help button in Search Addresses dialog lacks Help icon (on comm-central only).
• Working on:
  • bug 439134 “Customize toolbars” window a bit too small on linux – cuts off the “Restore defaults” button.

  • bug 515967 Add icons to addressbook menulist in Search Addresses.
  • bug 519133 Newsgroup list in Message Filters Dialog has blank entry and extra separator.
  • bug 521927 Make Search, Folder Location and Views widgets for MailNews customizable toolbars.
  • bug 525373 Make customizable toolbars play nicely with toolbaritems that contain a deck (Toolkit).

• Reviewed:
  • bug 232054 Update Help content on filters
• Bugs fixed:
  • bug 485702 Add sort markers/arrows to Password Manager

  • bug 525638 Add support for Firebug [Firebug part pending]

• Driving 2.0 to an actual release

• Installed Win7 SDK and MozillaBuild 1.4 on Windows build machines
• Cared to get our files ready for L10n dashboard listing “sea21x” for trunk
• Attended parts of the Cyber Liberties Conference in Vienna and presented SeaMonkey 2.0 there
• Added Simplified Chinese to the list of our localizations
• Going on vacation for three weeks, starting with the upcoming weekend.
• As always, my blog has more detailed status about my work.

• Helping out in the Mozillazine SeaMonkey Support forum ;)

• I started porting all SessionStore bugs for trunk, there is more than 10 of them.

• Still working on tests for Sessionstore

Working on:

• bug 521803 tabbrowser.xml: “Error: this.mPanelContainer is null”, opening MailNews.

• bug 521891 Need pref pane entry for extension blocklist feature.
• bug 522278 Header pane does no longer expand, shows scroll bar instead when opening address lists.
• bug 522434 Deleting from standalone message window doesn’t move to next message.

Bugs Fixed:

• bug 457882 News (nntp) option “ask me before downloading …” is ignored.

• bug 521263 After bug 381269 landing, browser_sanitizer.js breaks browser_passwordmgrdlg.js.
• bug 523693 Inline spell checker should be a module.
• bug 524442 startDocumentLoad and endDocumentLoad URIs don’t match.
• bug 524972 Remove nsTArray from nsINavBookmarksService.idl.

Working on:

• bug 485720 Text Descenders Do Not Display Properly In SeaMonkey Default Theme.

• bug 487700 Alert box no longer has focus after closing popup (Core).
• bug 513909 Make JS build with VC7.1 (Core).
• bug 520366 AppendInt only handles 32 bit signed ints (Core).
• bug 520535 titlebar=no windows do not receive keyboard & mouse events (Firefox).
• bug 525047 ‘make clean’ deletes automationutils.py (Core).
• bug 525725 xulrunner -help crashes [@ LoadPlatformDirectory] (Toolkit).

Bugs Fixed:

• bug 518865 Calendar Properties item missing from the SeaMonkey Edit menu.

Working on:

• bug 517684 Modern theme for Lightning, Part 1.

• bug 526148 Port bug 525712 (Remove dead throbber-specific code from customizeToolbar.js, handle it in themes).

Extension outreach:

• Posted messages to mozilla.dev.apps.extensions, the extension development forum at Mozillazine, and in irc://moznet/extdev.

• Contacted several authors directly e.g. Showcase, Calculator, Folder Accounts.

Other:

• Bug triage and bug discussions.

• AgitProp and PR in http://forums.mozillazine.org/
• Answering questions in the Mozillazine SeaMonkey Support forum.

Note:

• Currently I am concentrating on my own extensions as well as my extensions port project and won’t be too active in SeaMonkey development for a while – at least until 2.1 development starts to ramp up.

• bug 460953 Port jminta’s kill-rdf to SeaMonkey where applicable
  • 1 last patch waits for 2(++) major ports:

  • bug 444913 Port |Bug 413781 – XBLify folder-selection menus| to SeaMonkey
    • (mcsmurf’s…)
  • bug 507601 Port |Bug 414038 – Replace rdf-driven folder pane with a js-driven/non-rdf treeview| to SeaMonkey
• Fixed SeaMonkey bugs:
  • bug 255503 tabbedbrowser progresslistener list grows forever instead of resizing when removeProgressListener is called

  • bug 523562 Fix building of SeaMonkey Mac (and possibly part of Windows) on trunk following bug 516213 (Freshen WebGL implementation)
  • bug 524008 Fix “Warning: package error or possible missing or unnecessary file: bin/components/nsAxSecurityPolicy.js (packages, 258)”
  • bug 524022 Fix “Warning: package error or possible missing or unnecessary file: bin/components/proxyObjInst.xpt (packages, 203)”
  • bug 524026 Fix “Warning: package error or possible missing or unnecessary file: bin/gksvggdiplus.dll (packages, 56)”
• Fixed (MailNews) Core/… (but SM related) bugs:
  • bug 524682 comm-central should pull Chatzilla from hg rather than CVS

  • bug 523820 Remove old MOZILLA_1_9_1_BRANCH ifdefs from comm-central code
• And working on other areas… like
  • infrastructure to run tests

  • filing bugs for leaks in (TUnit) tests
  • doing a Windows comm-central-trunk SeaMonkey unit test build, filing bugs as needed; looking forward to an official build when enough new buildbot slaves can be enabled (bug 464325 follow-ups).

• See Thunderbird/StatusMeetings/2009-10-27#Standard8.

• See Thunderbird/StatusMeetings/2009-11-03#Standard8.

Working on:

• bug 525404 Appearance Pref Pane does not alter icon/text settings.

• bug 525698 [Mac] Need new css for pageinfo.

• Thunderbird mass-mailed Thunderbird extension authors on AMO reminding them to update their extensions for Thunderbird 3.0. We should do a similar mass mailing targeting two groups:
  • Existing SeaMonkey extensions that haven’t been upgraded to 2.0.

  • Firefox and Thunderbird extension authors encouraging them to make their extensions compatible with SeaMonkey 2.0.
• So what do we need? Someone to contact AMO to get a list of extension authors email addresses, and some person/software to do the spamming mass-mailing. Ratty to follow up with AMO on this. Also find out how MoMo handled this.
• KaiRo will be on vacation when the next meeting is scheduled to happen.
  • IanN to chair the meeting.

  • Ratty to set up the wiki page and to send out the invitation to the newsgroups.
• EOL date for SeaMonkey 1.1?
  • The plans for Gecko 1.8 are rather murky at the moment. KaiRo will probably try to get a clearer view when a 1.8.1.24 will be prepared possibly in December.

Retrieved from “https://wiki.mozilla.org/SeaMonkey:StatusMeetings:2009-11-03“

2009-11-04T04:00:20Z 2009-11-04T04:00:20Z bsmedberg http://blog.mozilla.com/meeting-notes/wp-atom.php http://blog.mozilla.com/meeting-notes/feed/atom Meetings notes from the Mozilla community 2009-11-04T04:00:20Z http://blog.mozilla.com/meeting-notes/archives/259

Thunderbird/StatusMeetings/2009-11-03 From MozillaWiki < Thunderbird | StatusMeetings last meeting | index | next meeting » Thunderbird Meeting Details : Tuesday, November 3rd, 17:30 UTC (9:30am Pacific, 12:30pm Eastern) How to dial-in Agenda Who’s taking minutes? –> clarkbw Minute taking Schedule. Talk to davida for schedule changes/additions. Action Items New Open [...]

Thunderbird/StatusMeetings/2009-11-03

From MozillaWiki

< Thunderbird | StatusMeetings

last meeting | index | next meeting »

Thunderbird Meeting Details :

• Tuesday, November 3rd, 17:30 UTC (9:30am Pacific, 12:30pm Eastern)

• How to dial-in

• Who’s taking minutes? –> clarkbw

• Minute taking Schedule. Talk to davida for schedule changes/additions.

• Planning for a dry-run security firedrill build
  • Fire drill itself expected to happen after code freeze

• Now in String freeze

• Branching completed
• Schedule:
  • Blockers to zero: 2009-11-06 23:59 PST

  • RC1 builds start on: 2009-11-09
  • Subsequent RCs as necessary.

• Blockers
  • blocking-thunderbird3+: 25 (-9)

  • TB 3 Needs: 1 (0)
• Proposed Blocking
  • Proposed Blockers (all): 1 (+1)

• Fixed RC1
  • TB 3.0rc1 – blocking: 127 (+11)

• Please set bugs to assigned status (as well as owner to you) if you want to do them.

• If you have other bugs assigned to you that you don’t want to do, please reassign or discuss with drivers.

• Normal bugday last week

• Ready to test RC1
• This week will be RC1 testing – as soon as we get the build.

Topcrashes 3.0b4

• top 20, about 1/3 fixed – which is great

• top 10 (”+” indicates change from last meeting) – no appreciable change in top 10 since 10-27:

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

• Press Tour Update – Completed press tour in Paris, Munich, and Tokyo. Everything going very smoothly. Had a great press conference in Tokyo with over 35 reporters with an additional 6 more interviews later in the week. Mozilla Japan has a very strong marketing team. Press has been very receptive to Thunderbird 3, all the new features, and the future ahead for our team.

• Will be wrapping up press tour this week in New York and on the West Coast.

• 2 Minis now in production

• SUMO
  • stage support.mozillamessaging.com

  • Backend ready for production

Done / Cleared

• activity manager (bug 257942, [1], [2]) (pending review)
  • Activity Manager Overview

  • Activity Manager Interfaces
  • Activity Manager Examples
• review newsgroups – tips
• bug triage
• hair-pulling MDC problems

In Progress

• folders (bug 414038) (summarize current / ask Bienvenu for help)

• TB account for https://developer.mozilla.org/devnews/
• markers for TODO items on how-to portal pages
• Mission control / autoconfig: MDC
• activity manager (257942)

TODO

• support search FAQ: tweak screenshots, edits, SUMO account, etc

• msg headers (466025, 480623)
• new bug for debugging issues? (and close 420317?)
• TB usage of XUL elements, content-in-a-tab
• collapsed threads (bug 496244 454829) (DavidA)

1. Top 5 GS Thunderbird 2 Support Topics (code in progress: http://gist.github.com/190923 ) basically the same as last week, possible McAfee false alarm
   1. Cannot send email (Verizon blocking port 25 starting fall 2009, AT&T percent sign in outgoing email due to wrong setting from AT&T support ?!?)

   2. Cannot receive email
   3. migration to Vista and Windows 7 – it works well for some not so well for others, most just need settings and migration help, be great if MozBackup or something like it was built-in
   4. McAfee finds trojan – probably false alarm, roland to follow up with Carsten and Sam
   5. email lost (fixed by compacting folders and deleting .msf)
2. Thunderbird 3 Beta Top Support Issues (not many reported, starting to monitor to see what we can improve for post 3.0)
   1. Windows 7
3. SUMO for MoMo tracker ticket: https://bugzilla.mozilla.org/show_bug.cgi?id=520628, TB3 Global Database KB – 1st article from JenZed, thanks! – should have 1st iteration of MoMo SUMO theme by end of week from contractor Gary Cunningham-Lee who did the original SUMO theme
4. Key Support stats from the following graphic:
   1. approximately 26 / day (180/7, higher than last week if we subtract the Raindrop topics – not sure why)

   2. total new topics:180 total replies: 69 (Ruby Code)
      1. date:20091027 #new support topics:23 resolved:9

      2. date:20091028 #new support topics:24 resolved:8
      3. date:20091029 #new support topics:32 resolved:9
      4. date:20091030 #new support topics:25 resolved:7
      5. date:20091031 #new support topics:17 resolved:4
      6. date:20091101 #new support topics:9 resolved:0
      7. date:20091102 #new support topics:20 resolved:9
   3. #replies from non MoMo folks: 3 from TMZ (thanks!) 14 from gyurrika (thanks!), 2 from Thomas (thanks!) MoMo folks: 2 from Philipp of Lightning (thanks!) 43 from Roland, 2 from Andreas (thanks!), Bienvenu 8 (thanks!)
   4. happiness metric: API doesn’t have happiness emotitags, asked GS staff about that, code in progress: http://gist.github.com/190094, manual happiness metric = 69 – 43 = 26 (50 last week), 56 Hendrix messages (generally Hendrix messages are unhappy but this week we had 2 happy messages from Thunderbird lovers, 1 wanted us to run our own email service! Thanks!) – bug to track down Hendrix for Thunderbird 3 and get rid of it as much as possible

• Illness slowed me down :-(

• Reviews & Driving
• Fixed bug 490817 and bug 525208 finally sorting out our EULA (removal)/License updates for TB 3.
• Made some good progress on bug 516776 – working on the final bits so that extensions should be able to provide content tabs that can load different pages.

• Reviews and Driving

• Don’t try to update virtual folders when doing an offline download sync, bug 525842
• Clone note curiosity for cloned views, per asuth, bug 525419
• Handle failure to expand thread because of threading problems by listing w/o sub-threading, fixes subsequent crash on collapse, bug 524266
• Fix hang in cross-folder threaded mode, when multiple messages have the same key in a thread, bug 518128
• Fix crash when adding thread column to search results pane, bug 524673
• Fix crash doing a quick search in a grouped single folder saved search, bug 524064
• Fix for crash in nsNntpCacheStreamListener::OnStartRequest, bug 130442
• tested uber gloda correctness patch bug 465618

• Build
  • 2 minis now in production, building green

• Web
  • Worked on stage.support.mozillamessaging.com

• Infrastructure
  • Setup complete backend DB infrastructure for Webheads

  • Ready for serious database workloads

• driving

• ui-reviews
• Started marking 3.next add-on idea’s in bugzilla

crash triage

• new
  • bug 526047 [@ nsAddrDatabase::GetRowForCharColumn(unsigned short const*, unsigned int, int, int, nsIMdbRow**)]

  • bug 525517 [@ XPCCallContext::XPCCallContext(XPCContext::LangType, JSContext*, JSObject*, JSObject*, int, unsigned int, int*, int*)] ** SM topcrash, TB3.0b4 #67 crash

• In the middle of press tour. In New York through Wednesday evening and then Bay Area tour for Thursday-Friday.

• Had one day off last week

• Finished preparing emails for people participating to the RC1 testing.

• Last week
  • Icon polish bugs bug 525232, bug 525832, bug 507508

  • Mess header pane: bug 521334
  • Looked into bug 525971
  • Looked into the stange nordic character issue

• This week:
  • Organize and upload graphic source files for all themes: bug 494804

  • Finish bug 525628
  • More polish items

Last week:

• Closed bug 524246, and bug 521928. (And checked the code in myself!)

• Posted patches for bug 248681, and bug 516680.
• Created bug 524756.
• Reviewed bug 521334, bug 525532, bug 491294, and bug 524800.
• Pushed the changes for bug 519110.

This week:

• Finish off the blockers. (I hope to get these in today or tomorrow, depending on how fast I can get reviews, and how well the reviews go.)

• Review some more bugs.
• Continue to help students with ISPDB.

• bug 470430 is finally checked in!

• If you have ever used Sunbird, please check if you have an empty folder:
  • $HOME\Application Data\Mozilla\Extensions\{718*\calendar-timezones@mozilla.org

  • ~/.mozilla/extensions/{718*/calendar-timezones@mozilla.org
  • If so, please report to bug 470430

• Now only bug 494140 is separating us from a firm code freeze.

• Waiting for a few locales to finish, will nudge them soon.
• If all this is finished, we are ready for beta 1 candidates.

Retrieved from “https://wiki.mozilla.org/Thunderbird/StatusMeetings/2009-11-03“

2009-11-04T04:00:16Z 2009-11-04T04:00:16Z bsmedberg http://blog.mozilla.com/meeting-notes/wp-atom.php http://blog.mozilla.com/meeting-notes/feed/atom Meetings notes from the Mozilla community 2009-11-04T04:00:20Z http://blog.mozilla.com/meeting-notes/archives/258

Platform/2009-11-03 From MozillaWiki < Platform « previous week | index | next week » Notices / Schedule Firefox 3.5.5 Firefox 3.0.16 / Firefox 3.5.6 Code freeze is November 10 at 11:59pm! 3.5.5: 35 open blockers … 27 need 1.9.1 patches 3.0.16: 15 open blockers … 11 need 1.9.0 patches Firefox 3.6 Beta Released on Friday, Oct 30th plan is [...]

Platform/2009-11-03

From MozillaWiki

< Platform

« previous week | index | next week »

Firefox 3.5.5

Firefox 3.0.16 / Firefox 3.5.6

• Code freeze is November 10 at 11:59pm!

• 3.5.5: 35 open blockers … 27 need 1.9.1 patches
• 3.0.16: 15 open blockers … 11 need 1.9.0 patches

Firefox 3.6 Beta

• Released on Friday, Oct 30th

• plan is to promote it heavily to rapidly increase beta audience
• will refresh frequently via the Firefox 3.6 beta update channel, each update will be versioned “3.6b#” and presented as a “revision”
• next update is aimed to be this Friday, minimally containing:
  • DLL component directory lockdown and blacklisting patch (see bug 524904 and bug 519357 (blocklist policy discussion in bug 525103)

  • syntax changes for CSS gradients (see bug 513395)
  • cycle-collector patch to stop cycle collection instead of crashing (see bug 521750)
  • other changes on mozilla-1.9.2 since we froze for beta

Firefox 3.6 Release Candidate

• proposed code freeze November 18th (2 weeks)

• proposed release November 19th (Happy Thanksgiving)
• need to check these schedules with build and QA, obviously

See more Firefox 3.6 related blocker queries, or learn about the new status and blocker flags

• Release Blockers (flag: blocking1.9.2 or blocking-firefox3.6)
  • 115 OPEN (-25 w/w)

  • 53 FIXED but not yet fixed on mozilla-1.9.2 (+22 w/w)
  • 36 nominations (-8 w/w)
  • Handy charts: Blocker snapshots, Blocker and Noms trends
• Approvals
  • 106 requests (-6 w/w)

  • 39 approved but not yet fixed on mozilla-1.9.2 (+2 w/w)
  • Charts: Nominations snapshots

(Progress reports every weekend on Planet Firefox)

• see our active projects and get involved / propose others

• Namoroka/mozilla-1.9.2 front end development:
  • 29 blockers left, 7 are crashkill

  • team estimates this number will be 10 by end of the week
  • per tab prioritization for session restore bug 514490 causing test failures on mozilla-central, should be wrapped up today or tomorrow, see the project page for more detail
  • windows 7 aero peek per-tab preview: as per bug 525475 we’re going to pref this off by default until the other bugs are fixed, allowing us to unblock on them

• 18 blockers
  • 9 are FIXED, several have patches.

  • GFX team will be triaging these to see which absolutely need to block.
  • Looks good for a November 18 freeze date.
• 3.5.4 crashes
  • We discovered once 3.5.4 had been released that we had caused two topcrashes: bug 524462 and bug 525326. These were fallout from security bug fixes.

  • More testcases helps, and we’re adding more. But the nature of graphics code (handling user-provided data) implies that it’s very difficult to have fully complete test suites.
  • It’s very likely that these could have been caught in a beta period for 3.5.4. Since we already look at crash-stats, should we just extend beta periods? Should we make it part of the “new release” signoff that we haven’t introduced new topcrashes?
• GFX team focusing on blockers, Electrolysis, crashes, and performance.

• Blocker report:
  • 18 blockers, but mostly (9) fixed on trunk and need 1.9.2 landing, or have patches, or we’re not sure there’s a bug

  • Silverlight issue fixed after conversation with Microsoft — we’re doing a trivial workaround for them calling NPN_Invalidate for a windowed plugin
  • Only 1 bug where we know there’s a bug and we don’t have a patch (519767)
  • 1 untriaged layout nom
• CSS gradient syntax change (bug 513395) landed on m-c yesterday; backport to 1.9.2 is posted to the bug, the a1.9.2 queue, and the try server; would like to land it tonight or Wednesday morning assuming all is well
• Layers API developed: https://wiki.mozilla.org/Gecko:Layers. Implementation to proceed shortly. Send feedback.
  • Framework for hardware acceleration, 3D transforms, retained buffers for elements, cross-process rendering, off-main-thread compositing, animation and video playback
• Patches ready to remove nsIScrollableView on trunk
• Jonathan Kew in Toronto office this week
• WOFF getting lots of press
• Rapturous reception at AtypI

• Excellent work by bz and smaug on a 1.9.1 stability regression

• Working on 1.9.2 blockers (26 total, 5 fixed/dup, 7 crashkill)
• crashkill work
• HTML5 parser work moving forward, getting through reviews.

• (smichaud) 1.9.2/JEP update — No new bugs in last week. No blockers.

• Almost done with a tool that shows numbers for all Talos tests across all branches for all platforms, summarizing median and mean per platform, including weekly difference, and difference from Firefox 3.5.

• Found a scenario for stable cold startup numbers on Windows. Next step is to get a Talos patch up, and work with Rel/Eng to get it deployed into testing so we can see numbers on real Talos boxes.
• Rob Strong split up the update service in bug 311965, has most reviews (affects all toolkit apps) and is about ready to land. This showed a significant win on WinCE startup.
• Taras and Joel are working on bug 524202, tracking down exactly how and when dynamic library code is loaded. See this comment for a good summary of the issue.

Join us on IRC in #startup.

pending reviews

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

• Fennelectrolysis lives: with only a medium amount of hackery of the Fennec frontend itself. Currently getting the platform-side patches landed.

• Working quickly towards getting IPC plugins landed on mozilla-central, preffed off.
  • Multiple plugins work, ipcplugin tests work (2 orange because NPN_SetException isn’t implemented)

  • cjones working on leaks during ipcplugins tests (probably shutdown-only leaks)
  • bent finishing work on Windows hangs

• Help with making debug tests green. bug 523385

• Upcoming power outage at 650 castro
  • November 14th

  • bug 524047
  • Mobile tests will be disabled for the duration

• 11 more machines on Try Talos bug 524849

Upcoming this week:

• Electrolysis tests bug 515436

• Stopping refcounting build on trunk on linux

• roc: Trying to make httpd.js do GC; xpcshell tests uncooperative

• robc: firebug – event listener service? yay!
  • bug 448602

  • bug 506961
  • bug 521010
  • bug 507448
  • shaver asserted that this is valuable and the risk profile seems right, but if it bounces it will bounce hard and need to be removed

Retrieved from “https://wiki.mozilla.org/Platform/2009-11-03“

2009-11-04T04:00:10Z 2009-11-04T04:00:10Z bsmedberg http://blog.mozilla.com/meeting-notes/wp-atom.php http://blog.mozilla.com/meeting-notes/feed/atom Meetings notes from the Mozilla community 2009-11-04T04:00:20Z http://quality.mozilla.org/602 at http://quality.mozilla.org

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.

2009-11-03T23:24:57Z marcia http://quality.mozilla.org/home 2009-11-05T00:45:40Z http://blog.mozilla.com/it/?p=667

We will have a scheduled maintenance window tonight from 7:00pm to 11:00pm PST. The following changes will take place: 7:00pm PST (0300 UTC) support.mozilla.com update. We’ll be updating support.mozilla.com to pick up code updates (bug 526284) . Duration 60 minutes. 7:00pm PST (0300 UTC) getpersonas.com update and database upgrade. We’ll be updating getpersonas.com to [...]

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

• 7:00pm PST (0300 UTC) support.mozilla.com update. We’ll be updating support.mozilla.com to pick up code updates (bug 526284) . Duration 60 minutes.
• 7:00pm PST (0300 UTC) 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.
• 7:00pm PST (0300 UTC) 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.
• 11:00pm PST (0700 UTC) 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.

2009-11-03T23:14:06Z mrz http://blog.mozilla.com/it Mozilla IT & Operations 2009-11-03T23:30:41Z http://www.bitstampede.com/2009/11/03/another-mdc-status-update/

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 [...]

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.

2009-11-03T21:38:41Z sheppy http://www.bitstampede.com Bits on the rampage: Eric Shepherd's blog. 2009-11-03T21:45:39Z http://drkscrtlv.livejournal.com/316649.html

(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.

2009-11-03T20:58:08Z Aki Sasaki aki@darksecretlove.com http://drkscrtlv.livejournal.com/ http://l-userpic.livejournal.com/21817427/759575 aki@darksecretlove.com escape(window): blog - LiveJournal.com 2009-11-03T21:00:50Z http://blog.mozilla.com/nattokirai/?p=48

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 [...]

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.

2009-11-03T19:59:50Z jdaggett http://blog.mozilla.com/nattokirai random things about fonts and graphics in Mozilla 2009-11-03T20:00:29Z http://weblogs.mozillazine.org/calendar/2009/11/10_beta_1_is_one_step_closer.html

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:

• Windows Vista: C:\Users\<your username>\AppData\Roaming\Mozilla\Extensions\{718e30fb-e89b-41dd-9da7-e25a45638b28}\calendar-timezones@mozilla.org
• Windows XP or earlier: C:\Documents and Settings\<your username>\Application Data\Mozilla\Extensions\{718e30fb-e89b-41dd-9da7-e25a45638b28}\calendar-timezones@mozilla.org
• Linux: ~/.mozilla/extensions/{718e30fb-e89b-41dd-9da7-e25a45638b28}/calendar-timezones@mozilla.org
• MacOS: ~/Library/Mozilla/Extensions/{718e30fb-e89b-41dd-9da7-e25a45638b28}/calendar-timezones@mozilla.org

If 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.

2009-11-03T19:13:50Z http://weblogs.mozillazine.org/calendar/ Calendar Copyright 2009 2009-11-03T20:30:11Z http://www.francisrobichaud.com/index.php/2009/11/03/cairo-vs-gdk-upscaling-benchmark/

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

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

2009-11-03T16:58:24Z Skaber http://www.francisrobichaud.com Getting there ... 2009-11-03T16:58:24Z urn:md5:8f7099931fb96c907d8b30d37db06ade

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:

• spread the word about KompoZer
• please don’t link to nvu.com on your websites
• if you mention Nvu, please explain that this project has been dropped in 2005
• ask your KompoZer community site to drop “nvu” in its URL
• don’t refer to KompoZer as “Nvu’s bug-fix release”: the official motto is “Easy Web Authoring!”

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!

2009-11-03T16:30:00Z Kazé urn:md5:a9f47af44d37c17f59ac5db8d567a80d Kazé There's only XUL! 2009-11-06T15:26:36Z http://weblogs.mozillazine.org/gerv/archives/2009/11/stars_in_the_internet_firmament.html

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......

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...

2009-11-03T16:26:16Z gerv http://weblogs.mozillazine.org/gerv/ gerv Gervase Markham 2009-11-06T17:24:01Z http://davidwboswell.wordpress.com/?p=1309

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 [...]

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‘.

2009-11-03T16:19:35Z davidwboswell http://davidwboswell.wordpress.com http://www.gravatar.com/blavatar/3b96fa677ec3e856af60f3912c76726f?s=96&d=http://s.wordpress.com/i/buttonw-com.png 2009-11-06T05:45:27Z http://blog.mozilla.com/sumo/?p=809

Sumo Weekly metrics Real Player is a trended search term zzxc to provide any relevant info from Live Chat in the bug Last week’s weekly support issues Re: websites blocking cookies: Findings from forum thread [1] (cilias) They complain about specific sites, not all sites. The sites vary (facebook (no specific app), google, ebay, [...]

Sumo

• Weekly metrics
  • Real Player is a trended search term
  • zzxc to provide any relevant info from Live Chat in the bug
• Last week’s weekly support issues
  • Re: websites blocking cookies: Findings from forum thread [1] (cilias)
    • They complain about specific sites, not all sites. The sites vary (facebook (no specific app), google, ebay, amazon)
    • Some instances of settings not being saved.
    • Re-installing does not work.
    • cilias to share this in the weekly common issues meeting tomorrow

Knowledge Base

• New article: Entry point js_SaveRegExpStatics could not be located
• Gathering list of articles that need to be updated for 3.6 [2]
• SUMO 1.4.2 (next SUMO release) will:
  • add an upload button for adding screenshots.
  • let us switch to a new start page
    • cilias to double-check which content blocks need to be created for the new start page and provide instructions for locale leaders on how to switch to the new start page
• Reword “Did this article solve your problem”? [3]

Live Chat

• Starting a new live chat shift at 6:00am Pacific this week

Roundtable

• SUMO 2010 update:
  • Collected lots of great ideas and suggestions for SUMO in 2010. Thanks to everyone who participated!
  • This week we’ll focus on formalizing & prioritizing these ideas into actual milestones. This involves:
    • Providing more concrete details of ideas
    • Grouping ideas together into logical milestones
    • Estimating the time needed for each milestone with the help from webdev
    • Prioritizing these milestones based on what has the most significant impact
  • First draft of 2010 roadmap should be ready within a couple of weeks

2009-11-03T16:01:05Z David Tenser http://blog.mozilla.com/sumo The support.mozilla.com (SUMO) project blog 2009-11-07T09:01:51Z http://blog.mozilla.com/about_mozilla/?p=316

In this issue… Firefox 3.6 beta 1 available Updating add-ons for Firefox 3.6 Light the world with Firefox Jetpack Design Challenge Firefox privacy and security On open source and education Multi-process Fennec SUMO and Firefox 3.6 progress New features in Firebug 1.5 Mozilla Drumbeat: pilot mode Mozilla.org: new “Get involved” page Building the Mozilla Developer Network Upcoming events Developer calendar About about:mozilla Firefox 3.6 beta 1 available Firefox 3.6 beta 1 was [...]

In this issue…

• Firefox 3.6 beta 1 available
• Updating add-ons for Firefox 3.6
• Light the world with Firefox
• Jetpack Design Challenge
• Firefox privacy and security
• On open source and education
• Multi-process Fennec
• SUMO and Firefox 3.6 progress
• New features in Firebug 1.5
• Mozilla Drumbeat: pilot mode
• Mozilla.org: new “Get involved” page
• Building the Mozilla Developer Network
• Upcoming events
• Developer calendar
• About about:mozilla

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.

2009-11-03T13:42:30Z 2009-11-03T13:42:30Z deb http://www.dria.org http://blog.mozilla.com/about_mozilla/feed/atom/ 2009-11-03T13:42:30Z http://commonspace.wordpress.com/?p=1309

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 [...]

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

2009-11-03T12:03:39Z msurman http://commonspace.wordpress.com http://www.gravatar.com/blavatar/bd66cb77716d8b6392b730fa89103c35?s=96&d=http://s.wordpress.com/i/buttonw-com.png things I'm learning along the way 2009-11-03T12:15:10Z http://weblogs.mozillazine.org/roc/archives/2009/11/css_gradient_sy.html

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.

2009-11-03T11:21:46Z roc http://weblogs.mozillazine.org/roc/ 2009-11-03T11:21:46Z