Last week, we disclosed two instances of suspected malware in experimental add-ons on AMO.  Since that disclosure, we’ve worked with security experts and add-on developers to determine that the suspected trojan in Version 4.0 of Sothink Video Downloader was a false positive and the extension does not include malware.  The same investigation also confirmed that the Master Filer extension included a valid instance of a trojan.  Our estimate of 6,000 affected downloads has been revised to under 700.  The Sothink Video Downloader has been re-enabled on AMO.  We apologize to our users and the developers of Sothink for any inconvenience this has caused.

Thanks to the team at McAfee for working with us to better understand this threat.

ShareThis

Drum roll please….we’re up to 50,000 Firefox Personas!  “Peace and Calm” was the magic 50,000th Persona.  What better way to celebrate the hard work of our Personas designers than by showcasing your favorite?  It’s not too late…just add your pic to our Flickr pool! (Note:  turns out that “personas” is a very popular tag on Flickr.)

Here are some of my favorites…

kevingo75 showing off Firefox Robot

Regnard Raquedan dons the Minefield Persona

Bob Chao's wearing his own design Sunny Foxymosa

Last week we held a series of testsdays on Tuesday, Wednesday, and Friday so we could get more eyes on out of process plugins (OOPP), a feature that was turned on the trunk nightglies on 1/28. We were hoping to try these builds, report problems, have those problems fixed overnight, and re-try them. So far we have found 16 bugs.
 
Today we held another testday, and we'll continue on Wednesday and Friday between 9am and 1pm PDT. We are hoping that tomorrow's nightly builds will contain fixes which should allow us to test past some common hangs and crashes while loading Flash and Silverlight.

Tomorrow's testday details.
Last week's testday results.
 
 

Over the past year, we set out to identify and solve any possible pain points that might arise during a person’s experience downloading and installing Firefox (previous posts are here, here, here, here, and here).  Thanks to feedback from users, and some resulting product changes, we can now safely say that there are no issues confronting new users when installing Firefox for the very first time.

How do we know this?

Last week, we re-ran our installer feedback mechanism for a short period of time.  If a user clicked “cancel” while walking through the Firefox installer, they were asked if they wanted to provide feedback.

After making an initial round of product improvements based on our first time feedback (March ‘09), here are the transformed feedback results from our more recent efforts (both July 2009 and last week):

While we still have plans to tackle the remaining big slice of the pie (see concluding paragraph), we were able to successfully solve the red and green pie slices from last time.  In our latest feedback results (pie on the right), the big pie slice now represents nearly 100% of the total feedback (the previously seen categories virtually evaporated).  One way to interpret this is that we’ve now successfully identified and resolved 3 of the top 4 issues originally encountered by users.

Here were the specific actions we took addressing those red and green slices (details are in bug 508684):

Don’t Want Firefox as Default

People indicating this issue were missing the selection option earlier in the installation process, arrived at the end, and mistakenly believed that we were making Firefox their default without being given a choice.  So, we added the choice to the final step in the installer:

Confusion About Updating-Upgrading-Installing

We did a few different things to help address this area of confusion.  First, we added content to mozilla.com and prominently displayed it on the main Firefox product pages seen by existing users:

Second, within the Firefox installer, we changed the Install button to say “Upgrade” instead of “Install”:

Thanks to Rob Strong, the Firefox team, the Funnelcake team, John Slater, and Laura Mesa, among others, for implementing the changes highlighted above.

Lastly, there remains one outstanding problem for installers of Firefox – “it tells me to close Fx, but it’s not open” (the big pie slice in the charts above).  This issue affects people who already have Firefox and are attempting to reinstall it, and as we’ve noted previously, this cohort becomes fairly frustrated during the experience.    Some fixes are starting to be contemplated (e.g., bugs 496207, 544356)… and I’ll make sure to talk more here once some progress is made.

As Chris Blizzard blogged about a few months ago, we’re in the process of creating the Mozilla Developer Network (MDN) to help unify a diverse, global developer community and give them a strong identity within the ever-growing Mozilla universe.   The MDN will serve key developer segments including those working on the Web, Add-ons, Mobile and Applications.  With early feedback and an initial roadmap, the Mozilla developer marketing team has been busy executing on a number of projects to help make the MDN a reality in 2010.

We have made a lot of progress this year with the redesigned Hacks blog and web developer outreach,  but we haven’t spent a lot of time discussing what the MDN will look like in terms of structure or brand.  We know it may take a while to figure out the right structure for our developer communities, but we can definitely make a huge impact early on by defining and developing the MDN brand.  Since MDN will serve as the official Mozilla “developer brand”, creating a strong identity is an important step in establishing the new name and concept within the Mozilla community.  That is why we have kicked off the logo design process with Studio Number One (SNO) and plan to share the concepts with you soon.  If you’re interested in learning more about the process,  check out the MDN logo design brief we provided SNO to start things off.

For those not familiar with the origins of the Mozilla dino logo, it was created in 1998 by Shepard Fairey and his BLK/MRKT design firm.  Most people know him for his more recent Obama “HOPE” poster, but the Mozilla community has been familiar with his work for years.

Fairey made a huge impact in the early days of the Mozilla project and his work is evident in the original Mozilla website design, many mozilla.org t-shirts, the Mozilla “hack” brand (which we borrowed for the Hacks web developer blog) and of course the Mozilla dino that lives on as the symbol for Mozilla today.  I am very excited that we are working with his current design firm SNO to create a new identify for the MDN.

We will have a set of MDN logo concepts later this week and I will blog more about them so that everyone has a chance to share their thoughts.   The Mozilla developer marketing team has given the SNO team three unique design directions to explore after our initial round of brainstorming and I can’t wait to see what they come up.

The MDN logo design project will be followed by a complete redesign of the developer.mozilla.org website in preparation for rebranding the site from MDC to MDN.  While we may be changing the look and feel of the website, the awesome documentation we currently have available on MDC isn’t going anywhere.   All the great developer notes, tutorials and web reference pages will be accessible from the /docs section of the MDN website.  The community will have a chance to provide their feedback during the MDN website design project as well, so stay tuned.

For more information about our MDN plans, you can track the various projects and programs on our wiki: https://wiki.mozilla.org/MDN

A really good ACM article about static analysis from Coverity’s perspective has been making rounds in Mozilla. What struck me most was the following paragraph:

At the most basic level, errors found with little analysis are often better than errors found with deeper tricks. A good error is probable, a true error, easy to diagnose; best is difficult to misdiagnose. As the number of analysis steps increases, so, too, does the chance of analysis mistake, user confusion, or the perceived improbability of event sequence. No analysis equals no mistake.

My personal view has been that “dumb” analyses are the most effective ones in terms of mistakes spotted vs time wasted writing/landing the analysis. It is interesting to see that sophisticated analyses are difficult to deploy even for Coverity.

In other news, LCA 2010 was my favourite conference so far. I met a number of awesome developers there. Mozilla’s static analysis work finally got mentioned in LWN!

A few months ago, we needed more desks for our office, so I figured I’d order them from the Ikea website. Easy to do, except that the Ikea.ca store doesn’t work with US credit cards, and our corporate card is a US card. So I bite my tongue about the craziness of e-commerce in Canada, knowing it’s not just an Ikea problem, and I use my personal card, and will deal with expensing it internally. Annoying, but oh well.

Then I’m blown away because delivery takes eons, because the desks have to come from the “online distribution center” in Quebec (”it’s Canada, so it’s got to be close, right?”), and not from either of the two warehouses within 20 miles of the delivery address (who do have the items in stock!). But I’m busy, so I live w/ the delay. Environmentally criminal, but oh well.

This month, we need more desks, and I’ve learned my lesson, so I know to take time out of my weekend to go to Ikea, order the desks and chairs. After about 45 minutes in the store, it looks like we’ll have delivery on Tuesday morning. A few high-end desks and what seems like their most expensive chairs, but I have a soft spot for Ikea, and their furniture is working out fine for us.

Turns out the chairs aren’t in stock, so they have to be scheduled for delivery a few weeks out and delivery has to be charged separately. Annoying, and a bit more expensive, but oh well.

Monday, they call and say that we hadn’t talked about delivery times (we had), and we reschedule it for the same day/time. Seems disorganized, but oh well.

Tuesday, they come and call my cell to let us know they’re downstairs, but I’m on the phone on an important call, and I thought it was someone else, so I figure I’ll get the message when I’m done with my call. By the time I get off the phone, I’m told they went on with their route, and I need to reschedule another delivery, which will cost me $75. Frustrating, but I blame it on the olympics and how it’s messing with deliveries everywhere, and blame myself for not taking the call, but oh well.

I call back to reschedule, and I’m told that I need to go back to the store to reschedule, because I need to pay for another delivery. WTF? After a bit of back and forth with the CSR, I ask to talk to a manager, and I’m told to do that I need to go to the store. WTF? I then ask about canceling the order, and I’m told that, you guessed it, I need to go back to the store.

Oh, if I want to lodge a complaint, I can do it on their website. I’ll definitely be sending them a link to this page.

I guess I know what I’m doing this weekend. What I’m not sure of is where I’ll get the next batch of furniture from. What a totally horrible customer experience, just because they don’t have a system for paying over the phone (or, hey, the internet?!?!) for silly delivery fees.

As we prepare to go live with Prism 1.ob3, I should mention that there is an issue with using the Prism extension in Firefox 3.6 on OS X. Prism uses the Firefox runtime (meaning the XUL, XPCOM and other libraries) for apps it creates. There is a small bug in Firefox 3.6 that prevents the libraries from loading on OS X. See bug 542004 for more information. The bug is currently nominated for inclusion in 1.9.2.2 (I guess it’s too late for 1.9.2.1). If someone is reading this and has the power to make this happen, please keep in mind that this issue is currently preventing Prism from running properly in Firefox 3.6 on Macs.

The good news is that there is a workaround that Mac users can use while waiting for a fixed version of Firefox 3.6. Just download the file dependentlibs.list and place it in your /Applications/Firefox.app/Contents/MacOS folder (or equivalent if you don’t have Firefox installed in the default location).

With Drumbeat gathering steam, a number people have asked for generic slides that they can use to spread the word. Which is amazing. I’ve taken a first shot at generic Drumbeat slides plus a voice over here:

<script src="http://blip.tv/syndication/write_player?skin=js&amp;posts_id=3214249&amp;cross_post_destination=-1&amp;view=full_js" type="text/javascript"></script>

You can also download the slides (PDF) or view the open video (ogg theora). The open video is actually nicer to watch than the embed above.

My goal with this version is to get feedback from people so that I can then do something more polished. I have two questions:

1. If you were in the audience, does this presentation provide you with a good intro to Drumbeat? If not, what additional topics would you want to see covered?
2. As a presenter, do the slides plus my voice over give you what you need to give a talk? If not, what else could I provide?

There are a couple of people who have offered to give Drumbeat talks in late February. So, I’ll take comments for a week or so and then post a revised slides in remixable form.

Update: Originally published on 2006-01-26 but somehow I didn't get this pushed on to the RSS feed so I've published it with a newer date.

Virtaal, a Computer Assisted Translation (CAT) tool, has been providing translators with Machine Translation suggestions through its plugin system. We've just committed a new Machine Translation plugin that allows Virtaal to use Microsoft Translator's new Haitian Creole translation engine.

The Microsoft Translator plugin has been waiting for the next major release as we didn't want to introduce any User Interface changes. But the usefulness of this tool in the current Haitian crisis means that we've released it so that people can use it and benefit from the feature.

How does this help?

• Any software that needs to be localised into Haitian Creole can now be more easily translated in Virtaal with Haitian Machine Translation support.
• Documents (OpenDocument Format and wiki texts) can be translated into Haitian Creole using Virtaal and the Translate Toolkit's txt2po and odf2xliff converters.

How do I use the plugin?

You have two options:

1. Windows: Download our special Virtaal .exe for Windows.
2. Linux: Copy the Microsoft Translator plugin into your plugin directory (on Linux this is /usr/lib/python2.6/site-packages/virtaal/plugins/tm/models/

How to use the plugin?

1. You'll need to define Haitian Creole as a language in Virtaal
1. Bottom Right > New Language Pair...



2. Add Missing Language...



3. Name 'Haitian Creole' and language code 'ht'



2. Ensure that the plugin is enabled. Edit > Preferences > Plug-ins > Translation Memory > Configure... Ensure Microsoft Translator is checked.

Open your file and begin translating, I'm using the tutorial Help > Tutorial and as you can see I'm getting Machine Translation suggestions from Microsoft for Haitian Creole.

We’re almost at the end of the Support Namoroka campaign and are tantalizingly close to our goal of $10,000 for the Madagascar Fauna Group, who support lemurs throughout Madagascar. (In fact, we’re at more than 80%!)

You can help us during this last week of the campaign. The best thing you can do to help us hit our goal is to donate.

If you’ve donated already, thank you! You can do us one more solid by spreading the word via Twitter, Identi.ca, Facebook, etc. If you’re short on creativity, you can just say this:

“Celebrate Firefox 3.6, Namoroka and help Mozilla support Malagasy lemurs! http://bit.ly/6lOsol”

You can also support the campaign with a parks affiliate button on your blog or website.

We’ve had some really amazing feedback from the Mozilla community and the public at large. Please help us hit our goal, celebrate Firefox 3.6 and help some adorable primates in Madagascar.

In this issue…

• Weave Sync APIs + developer resources
• Firefox on Android progress
• Simple vector and matrix math for JS
• Enabling Firefox plugins on mobile devices
• Video demo of Firefox on Nokia’s N900
• Visualizing the Firefox Twitter community
• Mozilla sponsors GNOME accessibility
• “Bugzilla for Humans” video
• GetFirebug.com redesign!
• Firefox UX team update
• Helping users avoid Firefox fraud sites
• Software releases
• Upcoming events
• Developer calendar
• About about:mozilla

Weave Sync APIs + developer resources
Mozilla Labs, following on last week’s launch of Weave 1.0, has now released its first set of developer resources including the Weave Sync + User APIs, documentation, and Python + JavaScript client libraries. The hope is that developers will use these resources to increase the number of places you can easily and securely access your personal data whether or not Firefox is available. “This first set of APIs focuses on enabling Weave clients to provide users access to their stored data from other devices and environments.” The team has also released a number of early prototypes and pieces of sample code.

Firefox on Android progress
The project to port Firefox to the Android operating system is progressing well, and the team recently posted an update. “After working out a few kinks, I got our first page load,” writes Vlad Vukićević, “Mouse events sort of work, toplevel windows sort of work, keyboard doesn’t work yet but shouldn’t be hard to hook up. This is running in an emulator at the moment for ease of debugging, but it’s working just fine on physical hardware as well.” Check out Vlad’s blog for the full story.

Simple vector and matrix math for JS
“One common thread running through the many different and interesting WebGL projects out there is that they all need to do vector and matrix math, do it quickly, and do it in JavaScript. Since this is such a crucial part of a successful WebGL program, I’ve put together a small package that I’m calling mjs. mjs is designed around speed and simplicity.” Vlad Vukićević has posted more information about this library on his weblog, including code samples, performance testing results, and links to the code and documentation.

Enabling Firefox plugins on mobile devices
An experimental feature is available to Nokia N900 users that will turn on plugin support in Firefox on their device. Aakash Desai has posted instructions on his blog, along with a warning that this is currently intended for development and testing only.

Video demo of Firefox on Nokia’s N900
The Firefox team has released a quick video tour of our first version of Firefox on the Nokia N900. Check it out on Caitlin’s weblog.

Visualizing the Firefox Twitter community
Tara Shahian is working on a Twitter visualization that captures the unique and multi-dimensional nature of our community, our conversations, and the energy that flows through our tweets. “As you know, there are some incredibly complex and mesmerizing data visualizations out there… my goal is to create a similarly stunning Twitter visualization that is also built on open web technology.” Tara is looking for ideas and feedback for this project, so head over to her blog post and get inspired.

Mozilla sponsors GNOME accessibility
The GNOME Foundation announced a $10,000 grant from Mozilla to advance accessibility work. “The GNOME Foundation and Mozilla are committed to open source, open standards, and open formats. Part of that effort is working hard to ensure users with physical disabilities are able to make use of a free desktop and Web browser”. See the full press release for details.

“Bugzilla for Humans” video
Johnathan Nightingale has put together a fantastic video introduction to Bugzilla, the Mozilla project’s bug tracking system. “Bugzilla is the devil we know. It’s more complicated than we’d like, it’s pretty intimidating to new users, and adding features can be a slog. It’s also essential to the way we manage our project at scale, and enough of our project’s history and daily activity lives there that understanding it is not really optional. Certain edge cases aside, you can’t really be effective in the Mozilla project without at least a passing ability to wade through Bugzilla.”

GetFirebug.com redesign!
Following hard on the heels of the recent Firebug 1.5 launch, the Firebug team has redesigned the GetFirebug.com website with a whole new look and a brand new (and very fiery) icon. Neil Lee, part of Mozilla’s Webdev team, has posted more details. “Even with intense competition from tools integrated into other web browsers, Firebug is still the leading web development tool in use with nearly two million active daily users. Its web site needed to reflect Firebug’s capabilities more clearly. The primary goals were to make the site easier to use and to highlight Firebug’s many positive qualities.”

Firefox UX team update
Alexander Limi and the Firefox User Experience (UX) team has posted an update about recent progress and UX priorities for the upcoming Firefox release. “Last week, we narrowed down the priorities for the next release of Firefox — which may be a 3.7, may be a 4.0 — in this document: UX priorities.” Limi’s post goes on to outline the main priorities which include: a new theme, home tab and app tabs, notifications, extension manager redesign, and download manager and MIME type improvements. Other ongoing projects include resource packages, Mac installer improvements, and tab matching in Awesomebar.

Helping users avoid Firefox fraud sites
Harvey Anderson, part of Mozilla’s legal team, has written about what Mozilla has been doing — and will be looking to do in the future — in response to user reports about fraudulent sites that try to trick people into paying for Firefox or downloading malware branded as Firefox. “Long term, to really scale to meet this problem, we’re going to need to explore alternative approaches that utilize organizations like Stopbadware.org, so users can be notified in advance when they end up on these sites. In combination, we may also need more messaging to warn users about the subscription traps that exist. In the interim, however, we’ll continue to utilize the tools we have so fewer users are scammed and more get the really great product contributors have created.”

Software releases
* Thunderbird “Lanikai” Alpha 1
* Processing.js 0.4

Upcoming events
* Feb 19 – Testday: OS Testing with Mobile Firefox
* Mar 5 – Learn how to testscript your add-ons
* Mar 19 – Improve the quality of QMO
* Apr 2 – Litmus 2 development review

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

A number of people have asked me: why do you still have Flash based videos on your blog?

The answer: my blog is hosted on wordpress.com, which strips out the video tag and also does not (yet) have it’s HTML5 video player. There is a trick to get around the video tag being stripped for self hosted WordPress, but not for wordpress.com.

The good news is that WordPress is working on their own HTML5 video player. Also, there is a bug filed to fix the issue of stripping out the video tag. Also good: wordpress.com automatically encodes everything you upload to Videopress into Ogg Theora. So, when HTML5 video does arrive, it will be Ogg ready.

As a happy wordpress.com customer (love the service) with a fair bit of traffic at commonspace.wordpress.com it’s worth it to me to wait around until the HTML5 video issue is fixed. In the meantime, I am posting all of my videos directly to wordpress.com using Videopress (and their Flash player) and also providing a link to the Ogg Theora version for people who would rather watch my videos natively in the browser.

PS. If anyone has a workaround that doesn’t involve leaving wordpress.com, would love to hear about it.

At the moment If you want to run a bleeding edge version of Thunderbird, you need to choose between running 3.2x and 3.1x builds. In fact, it appears that most people willing to run bleeding edge are now running 3.2x builds.

Whilst our most dedicated testers are running 3.2x builds, the engineering team is working on bringing features and bug fixes to the 3.1x branch. There's a discrepancy here. This means that the issues that might exist in 3.1x have a greater chance to be discovered after releases rather than before. It's easy to fix that, instead of running 3.2x builds, we would like our bleeding edge user to use the 3.1x builds (you can find them at http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.2/). By doing this simple switch you'll help to make the 3.1 series a great series.

China Construction Bank (CCB), which is the second largest bank in the world (by market cap) and has the second largest online user base in China, yesterday announced that their personal banking site has solved the web compatibility problem and now supports Firefox. If you read Chinese, you can see CCB’s own announcement at http://www.ccb.com/cn/ccbtoday/20100208_1265610102.html and another report at http://bank.baidu.com/2010-02-08/122642441.html.

With such a move, CCB became the first major Chinese bank to support Firefox. This is very significant and positive news for Mozilla, because online banking has been the most visible area of web incompatibility problems in China. Until now, all major Chinese banks supported an IE-only solution with ActiveX-based technology, forcing users to use Microsoft Windows/IE and seriously lagging behind their international peers. CCB’s breakthrough represents just the beginning of this ground shift and we fully expect that other banks will follow suit in the coming months.

[root@ip-ns01 ~]# mtr www.mozilla.com --report
ip-ns01.phx.mozilla.org           Snt: 10    Loss%  Last   Avg  Best  Wrst StDev
10.8.75.1                                     0.0%   0.4   0.4   0.4   0.4   0.0
v500.core1.phx.mozilla.net                    0.0%   1.1   1.3   1.0   3.1   0.6
xe-1-1-0.border1.phx.mozilla.net              0.0%   0.7   0.7   0.7   0.8   0.0
64.124.201.177                                0.0%   1.1   1.1   1.1   1.1   0.0
ge-0-3-0.mpr3.lax9.us.above.net               0.0%   9.4  13.0   9.4  44.3  11.0
xe-0-1-0.er1.lax9.us.above.net                0.0%   9.5  13.7   9.4  51.4  13.3
xe-0-1-0.mpr1.lax12.us.above.net              0.0%  94.3  21.3   9.3  94.3  27.8
xe2-3.cr01.lax01.mzima.net                    0.0%  10.0  14.0  10.0  23.0   4.6
xe1-0.cr01.lax02.mzima.net                    0.0%  16.9  15.7  10.2  22.8   4.8
te1-3.cr02.sjc02.us.mzima.net                 0.0%  18.1  22.5  18.1  30.0   4.9
ge1-mozilla.cust.sjc02.mzima.net              0.0%  18.4  18.6  18.4  19.1   0.2
v8.core2.sj.mozilla.com                       0.0%  18.4  19.7  18.2  30.8   3.9
mozcom.acelb.sj.mozilla.com                   0.0%  18.5  18.6  18.4  19.5   0.3

The following is a guest post from Chelsea Novak, Marketing and Fundraising Manager at the Mozilla Foundation

A few add-on authors have asked about directing contributions to the Mozilla Foundation. You definitely can- if you’re an add-on author and
interested in directing your contributions to the Mozilla Foundation, it’s simple and easy to do. Just set the PayPal e-mail to accounting@mozilla.org and contributions to your add-on will be directed to the Mozilla Foundation PayPal account.

You can add the following text to your add-on description so that contributors know where their money is going:

“All contributions for this add-on go to the Mozilla Foundation. Mozilla promotes openness, innovation and participation on the Internet. Learn more at www.mozilla.org/foundation.”

If you have any questions about the Foundation or our activities, please contact us at donations@mozilla.org or ping us in the #foundation IRC channel.

ShareThis

My wife strongly dislikes the new Firefox 3.6 tab behavior (where tabs opened from links appear immediately to the right of their parent tab, instead of at the extreme right of the tab bar).

I do like the new behavior, because by keeping related tabs closer together, it reduces the amount of time I have to spend interacting with the tab-bar scroll buttons (my least favorite UI element in all of Firefox).

She dislikes it for consistency reasons: when you open a new blank tab, it still appears at the far right. So now tabs can appear in two different places, depending on where you opened them. It violates the principle of consistency, which is generally considered one of the most important UI principles. This inconsistency hasn’t really bothered me personally. I’m not sure why; maybe it’s because opening a tab through a link, and opening a new blank tab, feel like different actions to me. There’s a difference in what I’m thinking about. But I can certainly understand how it feels like a consistency violation to other people.

My wife also doesn’t like that there’s no way to change Firefox back to the old behavior without going through about:config. (If you’re interested: type “about:config” in the location bar and hit enter, then do a search for a preference named browser.tabs.insertRelatedAfterCurrent and set it to True or False, as you like.)

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

As promised last week, the Firefox UX team will post weekly updates on what we’re up to. Instead of only posting individual after-the-fact updates, we’ll try to post more about what we’re about to do — which is usually a bit more interesting and higher-level, as well as gives you the chance to engage with us while we’re “in-process.” It will hopefully also give you a bit more insight into how we do our work. Our current focus areas can be found at UX priorities for the next Firefox release, as usual.

Previous week

Highlights from previous week’s activities:

• Jinghua, Boriss & Limi performed the first usability study on URL bar behaviors & expectations performed in downtown Mountain View. Definitely a success, but needs a second session to have enough subjects for meaningful analysis. Limi will follow up on this, probably next week — since it’s not directly part of the upcoming focus areas.
• Both Alex Faaborg & Stephen Horlander did some major bug filing and also updated and consolidated all the wiki pages & mock-ups. Full details.
• Limi completed his Resource Packages update, now includes inline definitions of resources. The only thing missing is a defined behavior when two packages override the same path, as detailed by Laurence Rowe in bug #529208. We’re ready to get this started, look for a post in dev.apps.firefox soon for the next steps.

This week’s meeting

We had discussions around the following:

App tabs: Handling drag events when there’s no Home tab visible

Outcome: Surface drop zones when dragging event starts, in practice this means temporarily compressing the tab closest to the app tabs area to make room. When app tab is moved into this area, it changes shape to indicate that it’ll become an app tab.

App tabs: Opening a new window when app tabs are defined

Outcome: Similar to how BarTap works, don’t load the app tabs until they are activated, but keep them around. This should probably be added as a general tab capability, since we want to use this for session restore, optimizing memory use for long-lived tabs in marathon sessions, etc.

Doorhanger Notifications: Problems with notifications from the Firefox menu

Outcome: There won’t really be any notifications coming from the Firefox menu, major updates have a dedicated, modal window already (make sure it’s modal), everything else is site-specific, so will originate from the site area. Once we have a messaging channel (home tab), we can kill off the dedicated “you’ve been updated” page for minor updates — but keep for major versions to surface new features.

Discussion on Linux theme defaults

Outcome: No matter what defaults we choose to ship, we’ll need to be able to draw in the title bar. Faaborg will follow up on this, and make sure bugs are filed.

How to handle all the bugs in a given UX focus area

Outcome: Some discussion around using whiteboard tags to keep track, but has been abused in the past in attempts to associate unrelated bugs with a feature. Easier & more predictable to define a “meta-bug” for the feature (example) and then mark all the relevant bugs as blockers for the meta-bug. A good separation is to split it into “design bugs” & “implementation bugs.”

Goal: Have the meta-bugs with all bugs connected for our projects by the end of the week.

Individual goals & focus areas this week

Jennifer Boriss

Extension manager: more mockups to do and some use cases previously unhandled, start the category association Mechanical Turk study to help determine what (if?) categories will be useful. Starting a week-long sprint for find on page — Paul O’Shannessy is willing to take up the development gauntlet but wants an outline.

Alex Faaborg

First draft of the Firefox menu & full Weave UI, possibly reorganize list of dialogs to kill for the Doorhanger Notification project.

Stephen Horlander

File more bugs, coordinate with Dão/Gavin on resourcing, designs for download panel.

Alexander Limi

Publish Download Manager Improvements article to site — guest starring Mr. Stephen Horlander. Get Resource Packages resourced (hah!) & post to dev.app.firefox about it. Get the results of the Test Pilot study on menu item & keyboard shortcut frequencies, if possible. File meta-bugs to keep track of all remaining projects.

This week’s activities design sessions

The current week is mostly about getting a lot of administrative stuff in shape in addition to the design work we do individually, so there’s only one UX-related session reserved this week:

• Wednesday: Kept open for a general design session, should we need one. Nothing scheduled yet.

Let us know what you think of this new format. Anything missing? Anything that you think is redundant? Send an email to limi@mozilla.com with your feedback.

A few add-on authors have asked about directing contributions for add-ons to the Mozilla Foundation. You definitely can! If you’re an add-on author and interested in directing your contributions to the Mozilla Foundation, it’s simple and easy to do. Just set the PayPal e-mail to accountingATmozilla.org and contributions to your add-on will be directed to the Mozilla Foundation PayPal account.

You can add the following text to your add-on description so that contributors know where their money is going:

“All contributions for this add-on go to the Mozilla Foundation. Mozilla promotes openness, innovation and participation on the Internet. Learn more at www.mozilla.org/foundation.”

If you have any questions about the Foundation or our activities, please contact us at donationsATmozilla.org or ping us in the #foundation IRC channel. Thanks to Nick and Shawn for this idea!

Last week we sent out the second issue of about:hacks, Mozilla’s newsletter for web developers.

Here are highlights from the topics covered in this new issue:

• Firefox 3.6 released: what’s new, how to give feedback
• Firefox for the Nokia N900 with Weave Sync released
• Developer Tools: Firebug 1.5
• Demos: an HTML5 image editor and uploader, a WebGL demo
• Behind the Scenes: Firefox release timeline, experimenting with sound and light
• New on MDC: Firefox.next, WebGL docs
• Hacks blog redesign

If you do not subscribe to about:hacks, you will find the second issue in the archives. If you enjoy the content, consider subscribing to make sure you receive the third issue, coming in March.

Finally, we’d love to get your feedback on the newsletter: what do you like, what would you change, what topics would you like us to cover. Please take a minute to fill out the feedback form.

• Releases:
  I prepared SeaMonkey 2.0.3 builds, which are now available on FTP as well as the beta update channel for testing by our community, offering well over 100 bug fixes. If things go well, we should be able to release this update in sync with Firefox 3.5.8 on February 16th.
  The 2.0.x nightlies now carry a 2.0.4pre version number, but we have no firm schedule for the following updates yet (will coordinate with Firefox, possibly also Thunderbird drivers on that).
  Work on 2.0.3 also included putting up a first version of the release notes.
  I also tried to let the release process generate 64bit builds for Linux this time, those are fully experimental and will only appear as "contributed" builds though, they have no official status at all.
• Build Infrastructure:
  The move of our core buildbot master code to a shared location could be completed, Thunderbird will look into using the same code in the future and we closely mirror the Firefox setup now, making it easier for people patching their side to fix ours as well (and the other way round).
  Revision reporting on packaged tests is now both generic and respecting applications that are built from different repositories as the platform (like SeaMonkey or Thunderbird).
  Additionally, I continued working with Mozilla teams to get SeaMonkey data up on the graph server, which needed a firewall rule and a correction on the staging server's database, but testing looks good now and we should be able to go live on the real server soon.
• Download Progress Windows:
  I created screen shots of some additional proposals for improving the progress windows, requested ui-review on them to see which one wins out with our "UI tsar", and finally implemented the winning proposal in a patch, which should be very close to positive review by now.
• Build System, Packaging:
  After a few runs on the Mozilla Messaging try server, I could finalize the patch for merging our package manifests and also make Mac use a manifest, get reviews and check it in.
  Another patch I worked on is about making branding usage fit Mozilla standards more closely, which should also ease the life of people wanting to ship suite versions with a different branding than the official "SeaMonkey" trademark designs.
  Some discussions about build system variables reminded me that I should re-test and attach the papering-over patch for mailnews Qt port bustage which I've had locally for quite some time now.
• SeaMonkey L10n:
  Starting with SeaMonkey 2.0.3, the language packs are marked compatible with all 2.0.* versions.
  Also with this release, Japanese is joining the collection of officially available localizations.
  This was also the first time I played with and used the new L10n sign-off dashboard for a release - further opt-ins / sign-offs for SeaMonkey 2.0.x will all run through this tool now. See the m.d.l10n thread for more details on using this tool.
• Various Discussions:
  2.1 planning discussions, Alpha 1 and further steps for 1.9.3, Gecko 1.8.1.24 and SeaMonkey 1.x EOL, KompoZer integration work, new machines, FOSDEM, places history changes, module ownership, mozilla.org planning and "Mozilla" vs. "Firefox" websites, EOL for Mac OS X 10.4 "Tiger" on 1.9.3, langpacks and switching, etc.

Patrick, Joe and I will be talking about/demoing Bespin at the Mountain View JavaScript meetup, this week on Wednesday at 7pm. If you’re in the Bay Area, we hope to get a chance to meet you there!

The Release Engineering:Future bugzilla component alternately inspires feelings of sadness, loathing, and contempt…and that’s just within the RelEng team!

I’m certain most developers first response to having their bug moved to the Future queue is, “Oh, look, my bug has fallen down a well.” Historically speaking, that may not be far from the truth.

What goes in Future?

Why does the Future component make people get punchy? For a long time, the Future component has lacked a decent description, so developers don’t know what it means when their bugs are moved there. Many have started hording their gigawatts in anticipation.

Bugzilla currently has the following small description of the Release Engineering:Future component:

“For longer term projects that have been agreed should be done, but have no immediate plans to so. These are not be part of the regular recurring triage. Advanced planning and placeholder goals for next quarter also go here.”

Despite the grammatical errors, this description is mostly accurate, but what does it actually mean:

• Triaged bugs with no immediate owners go here.
• Sadly, most enhancement bugs end up here unless they will make the core release process better, more streamlined, etc. quickly.
• Bugs that are blocked on longer term projects in other groups go here until there is something for RelEng to do.
• Advanced planning and placeholder goals for next quarter (or later) also go here. That’s pretty self-explanatory.

Remember: this description is for the Future component ONLY. The RelEng team continues to pick up and work on bugs that need to get done on a daily basis.

I’m thinking about how to improve this description, and will get the description updated in Bugzilla once I have achieved some rough consensus. In the meantime, I’ve posted this description of the Future component in the wiki as an ongoing reference.

The (Ever-Increasing) Numbers

At the time of writing, the Release Engineering:Future component has 343 bugs in it. This number has grown steadily over the past year despite having more release engineers on staff, and having made a great many improvements to our release automation and our continuous integration infrastructure.

Our turnaround time for bugs in the Future component is also not stellar. At our urging, the Mozilla Metrics team recently started setting up a dashboard to give us various statistics on our Bugzilla usage. Bugs don’t get fixed in the Future queue, so it’s hard to make truly accurate assessments here, but there are a lot of aging bugs in there. According to the numbers, fully 50% of the bugs in the Future component are older than 1 month and more than 25% are older than 6 months. How this compares to other teams or areas, I can’t say, but it certainly makes me empathize with developers who feel their Future-ed bugs have gone walkabout.

If it makes you feel better in a sadistic way, the majority of bugs filed by RelEng team members go directly into the Future queue. We’re not overly happy about it either.

I have a way? Is that better than a plan?

Things are getting done, though. For example, over the past month, the number of non-Future, release engineering bugs that are actively being worked on has gone from a low water mark of 130 up to over 200 today. For comparison, over the same period, the total number of bugs in the Future queue has slowly crept up from a low of 302 to 323. Mozilla is growing along so many axes that sometimes it feels like keeping the increase in the number of Future bugs to a linear relationship rather than exponential one is an accomplishment in itself.

So how do we stop the increase and start wrestling the Future component back under control?

The first step is triage. Starting this Thursday, February 11th, the RelEng team is going to have bi-weekly triage meetings to specifically prune down the Future queue.

As part of the triage, we’re going to be touching every bug and updating the whiteboard field with searchable tags. Our goal here is to make it easy to find classes of bugs in the Future queue so that duplicates and overlap can be easily eliminated, and fixes can be batched as much as possible.

We’ll be keeping a list of the tags we’re using in the wiki in case you want to follow along.

There are some classes of bugs that we won’t be able to eliminate (e.g. future goals), but hopefully within a few months, we’ll have the Future queue back under control.

It won’t be a quick fix, but it’s one we’re committed to.

I gave a three-minute not-actually-lightning-talk-but-let’s-call-it-that-anyway on ECMA-262 5th edition, what’s in it, and the state of Mozilla’s support for it at the Mozilla weekly meeting this week. It’s probably old hat if you’ve been following the standard closely, but if you haven’t it gives a short and sweet overview of what’s new; there’s a three-minute video of the actual talk on the meeting page (start at around 7:00 into the complete video). If you’re strapped for time, view the slides and turn off stylesheets (View > Page Style > No Style in Firefox) to see notes on what roughly accompanied each slide.

Hi,

during the Weekend i was in Brussels, Belgium and visited the FOSDEM 2010 !

I was a great experience and a very great conference and great to meet a lot of coworkers and  friends from all across Europe and the rest of the world   !

Also of course Mozilla had a booth at FOSDEM !

Mozilla @ FOSDEM 2010

We got a lot of visitors and was awesome to talk with the Community and have to say the Mozilla Community just rocks !

Also my talk about the Open Source Meetups in Germany, togehter with Florian, worked great and you can find the slides here !

A big thanks to everyone who made this Weekend possible, especially to William Quiviger!

William always at work

He worked basically around the clock on the weekend to make our Booth, Hotels, the Saturday Event etc possible – William just rocks !

- Tomcat

A quick introduction.

Rail has joined Release Engineering, and will be based in Moscow.

Some of you may already know him from his automation work in the Turkish and Russian locales for various Mozilla projects including Firefox. Or maybe you know him from his work in openoffice.org, or debian, or pootle. Anyway, he’s been using his skills in automation to make each of those better, so we’re delighted to have another like-minded automation person joining RelEng.

On irc you’ll find him as “Rail”, which is pronounced “ray-eel”.

(Oh, for the curious - he’ll be based in Moscow, as Toronto is “not cold enough” for him right now!)

For the past two months participants in Mozilla’s Jetpack 4 Learning Design Challenge have worked on Jetpack prototypes to turn the open web into a rich social learning environment and explore new possibilities for learning online. Today 10 teams were selected to participate in a hands-on Design Camp. The Jetpack 4 Learning Design Challenge is sponsored by the Mozilla Foundation with support from the John D. and Catherine T. MacArthur Foundation.

The selected Jetpacks support a wide range of learning activities. They help users learn foreign languages, support the development of sophisticated web-skills or turn the web into a quiz engine. A list of finalists (and all Jetpack prototypes) can be found on the Mozilla Wiki:

https://wiki.mozilla.org/Education/Projects/JetpackForLearning

The Design Camp in March will give the selected teams an opportunity to complete their prototypes with support from some of the world’s foremost Jetpack experts. The event is co-organized by Aspiration. An overall winner of the Jetpack 4 Learning Design Challenge will be selected during the camp and announced at the Mozilla SXSW event.(*)

The Jetpack 4 Learning Design Challenge uses an innovative combination of competition, training, and workshop to build skills in web development and drive innovation for learning on the open web. Online seminars provided participants with the necessary background on extension development and Jetpack technology. An active mailing list was used by participants to discuss and solve challenge they faced. All seminars and discussion are openly available for anyone to review and help them build their own Jetpacks.

The Mozilla Foundation is a non-profit organization that sponsors the Mozilla project and devotes its resources to promoting openness, innovation and opportunity on the Internet. We do this by supporting the community of Mozilla contributors and by assisting others who are building technologies that benefit users around the world. Through the Mozilla Education initiative we work with computer science, design and business schools around the world to create learning opportunities for a new generation of Mozilla community members and help to drive a new wave of participatory, student-led learning. By doing this we hope to move closer to Mozilla’s broader goal of making openness, participation and distributed decision-making more common experiences in Internet life. More information is available at education.mozilla.org.

The MacArthur Foundation supports creative people and effective institutions committed to building a more just, verdant, and peaceful world. In addition to selecting the MacArthur Fellows, the Foundation works to defend human rights, advance global conservation and security, make cities better places, and understand how technology is affecting children and society. In 2006 MacArthur launched its digital media and learning initiative to explore how young people are changing as a result of digital media use and what the implications are for libraries, museums and schools. More information is available at www.macfound.org/education.

(*) The Design Challenge is not connected to or affiliated with SXSW in any way.

This past Friday, February 5th, WebDevQA held a testday for the new AMO.  Overall, the test day was very successful.    We had 27 people in the #testday channel at the testday's peak.  Participants ranged from eager to learn first time community members to veteran community members.  Everyones testing efforts resulted in 7 bugs and enhancement suggestions being filed against AMO.  I'd like to thank everyone who came out to the test day and stephend and krupa for helping guide testers and answering questions.  If you want more details about the testday, see the folowing links:
 
Testday Details
Testday Detailed Results

If you’ve happened across the GetFirebug.com web site recently, you’ll notice everything has a rather pleasant freshly painted smell. After a much-too-long delay, we’ve finally updated the design and layout for the official Firebug web site, and introduced a lovely new icon by our resident Iconmaster General Sean Martell.

Even with intense competition from tools integrated into other web browsers, Firebug is arguably still the leading web development tool in use, with nearly two million active daily users. Its web site needed to reflect Firebug’s capabilities more clearly. With that in mind, the primary goals with this redesign were to make the official Firebug web site easier to use, more pleasant to look at, and give Firebug more of a traditional software-style layout to highlight its many positive qualities.

GetFirebug.com: Before

GetFirebug.com: After

It’s a fairly straightforward design, so there’s not a lot of interesting production notes to highlight, but here’s some specifics on what went into this redesign:

• The layout is roughly based on the 960 grid system. The original hope was to do the site in a fully fluid layout, but time constrains intervened.
• Headers and pull text are in the gorgeous (and open source!) Tittillium, thanks to @font-face. The body text was originally set in Droid, but due to a legibility issue on Windows machines with text-smoothing disabled, it was switched to the more common Trebuchet MS.
• The pages are build using the HTML5 doctype, with JQuery and the Fancybox plugin powering the modal pop-ups.
• The screencast on the homepage uses the Video for Everybody system to embed the OGG video, with MP4 and Flash fallback for other user agents.
• The homepage blog feed pulls in from the Firebug weblog RSS feed using SimplePie.
• For this iteration, we wanted to switch the site over to a simple content management system, and ended up settling on Perch. It has its shortcomings, but it was straightforward enough and easy enough for me (mostly a designer/UX guy) to implement.
• Sean passed along a few images that inspired the sparkly new icon. Originally, we tossed around the idea of doing something cartoony and heroic, like this lil’ dude, but ultimately decided to go with a more, well, buggier bug.
• Photographic inspiration: Bug 1 • Bug 2 • Bug 3 • Bugs!

It’s been a long time coming, and we hope you like GetFirebug.com’s new set of clothes. The content is currently being updated and will roll out as it is completed, but in the meantime, please kick the tires and let us know what you think.

Now that we're moving full-steam towards the Lightning 1.0 beta2 release, it's also time to make clean slate and show you in terms of fixed bugs, what has happened since the last status update back in late November 2009.

Overall we have fixed an impressive 55 bugs since then, keeping in mind the whole release process hassle, the holidays and Philipp's exam schedule. Here's the complete list of fixed bugs:

• Bug 313822: Make Lightning work on SeaMonkey
• Bug 357332: Holidays in Chile for 2010
• Bug 364487: Argentina Holidays 2008-2009
• Bug 376139: Sri Lanka Holiday 2010
• Bug 397180: South African Holidays 2010
• Bug 432440: Israel Holidays 2010
• Bug 472466: No small icons in edit event/task dialog available
• Bug 489882: Building with "NECKO_DISK_CACHE=" fails with unresolved external symbol
• Bug 500399: Event Dialog: Help Menu is uselesss and could be removed
• Bug 509100: Holiday file for Namibia
• Bug 511193: [Mozmill] Recursion tests
• Bug 518610: Tasks no longer work in TB3/Lightning with Kerio Mailserver
• Bug 524574: Polish holiday 2009-2020
• Bug 528676: e-mail list not updated when using next/prev button in New Calendar wizard
• Bug 529810: Views borked using wcap: dayHeaderBox.mItemBoxes is null
• Bug 529853: Creation of local calendar fails (DB Error no such column: recurrence_id_tz)
• Bug 530096: Tracking bug for Sunbird/Lightning 1.0b1 release
• Bug 530097: Create release notes for Lightning/Sunbird 1.0b1
• Bug 530100: Bump version numbers for 1.0b1 release
• Bug 530165: [Mozmill] Timezone test
• Bug 530842: Upgrade Sunbird/Lightning 0.9 to 1.0pre fails
• Bug 531028: Linux: Delete Task button in Task view is missing its icon
• Bug 531418: Allow building lightning with all locales at once
• Bug 531685: Build problems on linux and win32 due to insufficient disk space
• Bug 531699: Spanish Holidays 2007-2010
• Bug 532656: Fix Sunbird official branding on Mac.
• Bug 533070: Sunbird nightly builds fail with |No rule to make target
• Bug 533089: Malta Calendar 2010
• Bug 533259: Sunbird website does not validate to its doctype
• Bug 533324: Finnish Holidays 2010
• Bug 533329: [Mozmill] Verify that Calendar is working properly with UTF-8 characters
• Bug 533458: Fix mac and windows trunk builds
• Bug 533466: calendar-multiget REPORT should not specify the calendar collection URL
• Bug 533498: Build config changes for Cocoa Printing
• Bug 533713: gdata-provider.xpi should support SeaMonkey 2
• Bug 533747: Mention required version of Thunderbird in system requirements of Lightning
• Bug 533943: CalDav access to my calendar doesn't work on RC2, lightning 1.0, using CGP
• Bug 534969: Add sq to calendar/locales/all-locales
• Bug 535379: Create more l10n.ini files to builds against 1.9.1 and central
• Bug 535574: [Mozmill] Writing to a local ICS calendar
• Bug 535812: [Mozmill] Event with no changes shouldn't prompt to save
• Bug 536185: Update calendar/ copyright dates to 2010
• Bug 536189: Wrong Lightning version in install.rdf
• Bug 536354: getItem doesn't set calendar for items
• Bug 536525: Turkey holidays for 2010
• Bug 537066: Scrape dead bits out of credits.xhtml
• Bug 537470: Russian Holidays 2010 and onward
• Bug 537628: Building localized Sunbird l10n nightly builds fail since 02-Dec-2009
• Bug 537885: Add Arabic (ar) to Calendar builds
• Bug 538170: Mac trunk builds failing running merge-installrdf.py
• Bug 538439: static Sunbird builds from comm-central/mozilla-central fail
• Bug 538576: Singapore Public Holiday 2010
• Bug 539681: Puerto Rico Holidays
• Bug 539943: Set up builders for Lightning 1.0b2pre for Thunderbird 3.1
• Bug 543359: Adjust Lightning version and required Thunderbird version

As always, our thanks go to all developers, contributors, localizers, testers, and supporters that have made this possible.

It has been some time since the last regular Camino development status update, but that doesn’t mean we haven’t been hard at work—it just means that I’ve been pretty busy with all sorts of things, and the status updates have been fairly low on my to-do list.

As I said, though, we’ve been working on all sorts of things so far this year. Dan Weber has been hard at work on patches for some of the most visible issues with the new autocomplete experience, and I landed the fix for the magically-reappearing autocomplete window tonight. Dan is also still working on improving the speed of autocomplete for large histories, though that patch is not yet ready. Chris Lawson has also been working on various and sundry other bugs, including changes to the Flashblock exceptions list so that pasting URLs into the field will work as users expect. Philippe Wittenbergh is hard at work polishing some of our toolbar icons.

Christopher Henderson has been working on a patch that moves our history off of Mork, which is both the sane thing to do and critical for moving forward to the new Mork-less world. As usual, I have been chasing down bugs here and there and wrangling patches to get ready for the upcoming 2.0.2 and 1.6.11 releases. We’ve also seen Alex Jones, who has been working off-and-on on supporting Mobile Me sync, again recently, though it sounds like Sync Services wants to do things in a manner that is not easily compatible with Camino’s bookmarks implementation. All in all, we’ve been fairly productive since the new year began.

Which brings us back to the title of this post and to this weekend’s developments. Late Saturday afternoon, I got a debug version of Camino to build, launch, and run using Gecko 1.9.1, and early Sunday evening I was able to make a static (i.e., distributable) build do the same thing. (Even better, Christopher Henderson was able to replicate my success.) This feat would not have been possible without all the hard work that Christopher put in for the aforementioned history migration, as well as a good bit of debugging and patching he did this weekend as we hit some unexpected code-change-related build failures. After applying those patches, I mostly deleted and added things to the project and waited for the next build failure. At the end of the day, though, Camino launches and runs, plays <audio> and <video> (with Ogg), and displays pages with @font-face (with raw TrueType fonts).

This doesn’t mean that we can turn around and release a version of Camino based on Gecko 1.9.1 (and there’s a very strong possibility we may not); for starters, there are a number of known regressions (including the loss of Find-As-You-Type), as well as possibly hundreds of other serious problems we haven’t discovered in our limited test browsing. Beyond that, the “build system” is not yet a system at all; it involves pulling mozilla-1.9.1 from hg, checking out Camino from cvs into mozilla/camino, and applying a large patch. But if you’re brave or crazy, you can try this at home now (and for those less brave or more sane, there’s an Intel-only build here that you can use to help us find other broken things. N.B. You should treat this build as highly experimental. It might eat all of the cheese in your house. It will eat your profile, so make a backup copy first).

We also know (thanks to earlier attempts by Philippe Wittenbergh and Kai Rune Mathisen to build mozilla-central) that there are more serious code breakages in newer versions of Gecko, so this is only the beginning. In between other things the last few weeks, I’ve also been working on a new repository and fleshing out issues and solutions for the build system. There’s a long road ahead, and Camino 2.1 might be ready before we’ve gotten to the end of the road; we’ll have to see. However, as Christoper said on Saturday night, “it’s been a great day in Camino Land.”

FCKEditor!

This news is a bit old now (since it appeared briefly on Planet Mozilla the other day half-buried in a PR round-up, and since reader James reported it in a comment on January 21), but FCKEditor is the winner of the 2010 edition of the annual “we break our site for your browser when the new year rolls around” broken browser-sniffing contest.

If you use FCKEditor on a site and it doesn’t work with Firefox 3.6 or nightly builds of any Gecko browser built since January 1, you’re probably seeing the bug that won FCKEditor this year’s prize with a stunning upset of two-time defending champion Yahoo!

My gut feeling is that this new type of contest winner is much worse than the old “major site is broken” type, since there is no single point of contact for the fix (everyone who uses the affected versions of FCKEditor will have to patch or upgrade their install), since unpatched instances of FCKEditor could break functionality on websites far and wide for years to come, and since in some ways the distributed nature of the problem means there is less visibility than when a major website suddenly ceases to work correctly.

I think this also highlights the importance of web “library” or “component” authors doing things correctly from the beginning—not browser sniffing at all, but instead testing for features—because their code will be used widely and, as I understand it, they have little control over getting consumers to update when there are fixes for broken things like this.

If you’re going to write something for wider consumption, or that you think may one day be useful to large audiences, please take the time to get things right from the beginning, especially if your code doesn’t have a dead-simple upgrade experience. Your users, and their users, and even other unrelated software vendors, will thank you for it later.

(And remember: only you can prevent broken browser sniffing! )

Theme Bugs Filed This Week

Note: I haven’t filed any Linux bugs yet and the Wiki page is out-of-date. Still working out some details there and should have that resolved this week.

This week I filed the first round of Bugs for implementing the new theme:

• #544815 – Allow for placing Tabs over the Navigation Bar with option for Tabs under the Navigation Bar
• #544816 – Attach combined Stop/Go/Refresh button to the Location Bar
• #544817 – Create Bookmarks Widget with placement dependent on Bookmarks Bar status
• #544818 – Progress “Line” indicator for background loading tabs
• #544819 – Create a basic Home Tab linking to the current Home Page
• #544823 – [Meta] Theme Visual Refresh
• #544820 – [Windows] Theme Visual Refresh
• #544821 – [OS X] Theme Visual Refresh

This is a pretty exciting step for me after having worked on the design for so many months.

Wiki Updates

I also spent some time getting all the mockups and thought processes on the Wiki current:

• Theme and UI Revamp
• Windows Theme Mockups
• Theme/UI Direction and Feedback
• Mac Theme Mockups
• Mac Specific Visual Design

Recently, I found that I needed my chrome Mochitest to wait for a XBL binding to apply, before continuing the test. For the end-user, waiting is hardly an issue - by the time they see the new user interface, all the bindings have applied. Mochitest (and most other automated test harnesses) runs straight through, and brakes for nobody. In some cases you can pull some trickery with nsIThreadManager, convincing Firefox to wait... but that's hardly reliable.

So I came up with a three-part solution.

1. Force my XBL bindings to fire DOM events when the constructor executes.
2. Break up my test functions into (slightly) smaller functions, each of which handles a part of the overall test. Two parts cover the main functional testing, while a third part is specific to the XBL binding.
3. Implement a generic testing harness for Mochitest which can manage the flow from one function to another.

This new test harness, which I call PendingEventsTest, adds a layer of complexity on top of SimpleTest. Each test function is added via PendingEventsTest.addTest(), and you can pause for a DOM event with PendingEventsTest.addEventLock(). The whole test sequence can abort with an error by calling PendingEventsTest.abortFail(). You can advance to the next test function in the sequence with PendingEventsTest.asyncRun() or PendingEventsTest.run().

There's more complexity to it than that, of course. To move data from one test function to another, I also added "payload" support, for storing a generic object. Also, this is written for chrome Mochitests - it will likely fail in content Mochitests. Still, this new test harness helped me finish support in Verbosio for my equivalent of the <xbl:children/> element in markup templates.

Lastly, it (and the logging service I wrote a few weeks ago) is licensed under MPL 1.1/GPL 2.0/LGPL 2.1, so anyone who wants to borrow this for Mozilla code is welcome to. Cheers!