Planet Mozilla

David Humphrey: Dict: E-lec-tri-fy

david.humphrey — 2007-11-17T00:55:26+00:00

1) Charge with electricity; pass an electric current through

Yesterday Chris and I welcomed Benjamin Smedberg into our Mozilla classes for a talk on XPCOM. You couldn’t ask for a better guide into the often (always?) murky waters of XPCOM. Benjamin is a fantastic and animated speaker, who really draws you in. He’s able to keep you rapt even with deeply technical discussions about vtables and proper macro use (”…other people will tell you to do it this way, but I’m the module owner and I say you do it this way…”). It helped that both classes had spent the previous few days working on a component lab–the questions are always so much more real when you’ve been banging your head against the wall!

We filmed the talk as usual, but this time ran into major technical difficulties. Benjamin was on a role and pontificating about the dangers of assuming one object per interface and describing tear-offs, “…and whatever you do, you can’t ever do this” and the power went out. And I mean out, for most of campus and a few city blocks. I think it proved his point quite nicely.

After that we had to scramble to move him under the only emergency light in the room, run the camera on battery, and get the students to share the slides on laptops. It was just like listening to ghost stories around a campfire, and sometimes XPCOM is just that scary. A huge thanks to Benjamin for coming all the way here–we loved having you.

2) FIGURATIVE impress greatly; thrill

I woke-up this morning to Frank Hecker’s essay on Seneca and our efforts with open source education. It was incredible and humbling to see what he had to say. I’ve been asked by a lot of people for a description of what we are doing (and hoping to do) at Seneca. Frank’s post is a great introduction and reflection. I hope we can keep our current pace and arrive at some of the destinations he charts–we’re certainly going to try. And if we get there, it will be because of the help of so many friends who believed in us and never stopped supporting us along the way.

This last point is something I want to return to when I’ve had time to write it properly…

Seth Bindernagel: How we decided upon FOSS.IN

seth bindernagel — 2007-11-17T00:17:48+00:00

If you’ve been following this blog, you may have seen some posts over the past few months about Mozilla’s participation in India’s largest open source conference, FOSS.IN. Our initial planning culminated with Mozilla’s project day proposal being accepted by the FOSS.IN planning team. That was exciting. What did I learn in this process, and what, if [...]

Burning Edge - Firefox: 2007-11-16 Trunk builds

Jesse Ruderman — 2007-11-17T00:03:45+00:00

Fixes:

Fixed: 177838 - Make all popup windows resizable, ignoring resizable=no.
Fixed: 223895 - Completed downloads should include size and TLD instead of "Done".
Fixed: 400327 - Automatically add splitter whenever location bar and search bar are adjacent.
Fixed: 143046 - Reduce memory use for animated GIFs by storing frames other than the first at the original 8 bits.
Fixed: 402633 - View source leaks many CTokens and nsStringBuffers.
Fixed: 207531 - Allow editor to edit xhtml files (as html).
Fixed: 402763 - Cycle collect on memory-pressure (e.g. when using the RAMBack button).
Fixed: 400552 - Setting document.domain inconsistent in face of IDN whitelist.
Fixed: 402866 - dom.disable_window_open_feature.resizable=true makes modal dialogs (e.g. Javascript alerts) resizable.
Fixed: Some progress towards getting MathML working again (in bug 324857 and 403718).
Fixed: Bump trunk version to "3.0b2pre" and "1.9b2pre".
Fixed: 403238 - [Mac 10.5] dialogs are still getting pinstripes for their background.
Fixed: 399937 - [Linux] Separate out the Linux theme from the Windows theme.
Fixed: 118312 - [Linux] NS_THEME_TREEVIEW* implementations (GTK).

Fixes for recent regressions:

Fixed: 403664 - Crash when pasting into textfield with rich text mode.
Fixed: 381216 - Prevent bookmarks dataloss when a user goes from Firefox 2, Firefox 3 beta, Firefox 2, and then back to Firefox 3 [was: After initial import, minefield with bookmarks-on-places throws out Firefox 2 bookmarks changes].
Fixed: 397510 - Scrolling in large file is very slow due to textrun reconstruction.
Fixed: 402602 - https://paypal.com doesn't trigger the netError page that allows exceptions.
Fixed: 402439 - [Windows] Clipboard is emptied on application exit.
Fixed: 385966 - [Mac 10.5] Extra file menu appears to the right of the help menu (two file menus).

Trunk regressions:

Since ~Nov 14: 403854 - Removing search bar or location bar breaks many things.

Trunk checkins between 2007-11-06 04:00 and 2007-11-16 20:00

Windows nightly (discussion)

Linux nightly

Mac nightly

Mozilla Security: jar: Protocol XSS Security Issues

Window Snyder — 2007-11-16T23:52:04+00:00

Issue

jar: protocol is not restricted to java archives and will open any zip format file. An attacker can use this to evade filtering on sites that allow users to upload content and use this initiate a cross site scripting attack.

Impact

Firefox supports the Java Archive URI scheme that allows the addressing of the contents of zip archives. An attacker may upload a zip format file to a trusted site that allows users to upload content. The victim clicks on a link on the attacker’s website or in an email that links to the uploaded content on a trusted site. Since the content is loaded from the trusted site, content from the zip file runs in the context of the trusted site. This may allow the attacker to access information stored on the trusted site without the victim’s knowledge.

There is a second issue that if a zip archive is loaded from a site through a redirect, Firefox uses the context from the initiating site. This allows an attacker to take advantage of a site with an open redirect and host content on their own malicious site that will execute with the permissions of the redirecting site.

There is a proof of concept that demonstrates these issues in an attack against Gmail that allows the attacker access to the victim’s stored Gmail contacts.

Status
In future versions Firefox will only support the jar scheme for files that are served with the correct application/java-archive MIME type. Firefox will also adjust the security context to recognize the final site as the source of the content. This will be addressed in Firefox 2.0.0.10, which is currently in testing.

You can follow our work in bugzilla:

https://bugzilla.mozilla.org/show_bug.cgi?id=369814

https://bugzilla.mozilla.org/show_bug.cgi?id=403331

Credit

These issues were identified by Jesse Ruderman, Petko D. Petkov, and beford.org.

Mike Shaver: what makes firefox 3

shaver — 2007-11-16T23:37:35+00:00

Couple of articles today reporting that we’re going to ship Firefox 3 with 80% of our current blocker list still remaining to be fixed, which have cause quite the kerfuffle in our little corner of the internet. It appears to be an honest mistake, since a set of meeting notes did include that prediction, along with other elements that mention other approaches to the Firefox end-game, but it’s not our intent to cut Firefox blockers from the fix list against a hard numerical target or fixed deadline. As Matt Asay has noted, we’ve already demonstrated with this product cycle that we don’t roll that way.

At some point, of course, the number of “bugs we’ll ship with” will hit 100%, unless we manage to produce the first piece of bug free software I’ve ever worked with, but even with such numerical truisms aside, the picture here isn’t as simple as it seems. “Bug” in our world — as with every software shop I’ve ever worked, to be honest — includes desired feature improvements, optimizations, basically everything in the gap between “how the software is” and “how someone would like the software to be”. Because of history and some tool limitations, and because we now have a larger set of people triaging blocker nominations than we ever have before, the “blocking” flag doesn’t always strictly mean “we would not ship Firefox 3 if this specific bug isn’t fixed”. It can also mean “we should look at this in more detail before we ship” or “we’d like to focus developers on this set of bugs” or “don’t forget to do something (release note, document workaround, reach out to site authors, etc.) here before we ship”.

Sometimes, of course, it definitely does mean “we really should not ship without this bug fixed”, which is the most common understanding of “blocker bug”. Over time, our impressions of the severity of something can change, up or down, as usage on the web changes, or features get deferred (meaning that “mandatory” platform changes to support the features are no longer mandatory). Some things that we thought were blockers at one point may well be evaluated not to be later on; we reserve the right to change our minds, as must all learning people and organizations, but we’re not going to do that on a strictly numerical basis, and certainly not on the basis of some system dreamed up by a 16th century doctor.

Of course, we want to get Firefox 3 out to users soon, because there are tens of thousands of improvements there: better support for web standards, speed and memory improvements, great new productivity features, safety and security features, straight-up bug fixes, lots of UI polish, and powerful new APIs for extension developers. But we also need — which trumps the “want” of soon, as you would expect — to make sure that we ship a product that’s good enough for a quarter-billion users (on our current growth curve, we could easily see that many people using Firefox during Firefox 3’s lifetime), that’s worthy of the name Firefox, and that we’re all proud to send into the world. Many of us worked on Netscape 6, so we take this pretty seriously.

Mike Schroepfer, our VP engineering, isn’t dogmatic about many things, which is one of the reasons he’s so good at his job. But he’s pretty damned unequivocal that we’re not going to ship until we’re done, as you can read here and elsewhere:

1) We are driven by quality, not time. We want to Firefox 3 to be something that we are all proud of. This means features that delight users and the same or higher quality than previous releases. “Quality” includes performance (Tp/Ts/TDHTML/etc), footprint, web compatibility, regressions, and general fit and finish. Having said that, we want to move the web forward and are in a competitive market. So we should converge on a release as fast as possible.

…

4) We’ll release betas until we complete our regression work and incorporate feedback from wider-scale testing. Before we release the final beta Performance (specifically Ts, Tp, Tdhtml, Txul, and any other benchmarks we add to the main tinderboxes) will be as good or better than 1.8. We should strive for improved Tp and Tdhtml scores performance v.s. 1.8.

…

When will the last Beta ship?

As soon as it is ready (see #4 above)

There’s nothing new or changed here, other than an unfortunate mixup in some meeting notes and that more people than ever before are watching what we do and how we do it. That reporters are tracking our meeting minutes to track the project indicates that what we’re doing is important to a lot of people, and that makes us more motivated to focus on quality than before, and not at all motivated to push out a release to meet some arbitrary deadline. We’re in this for the long game, and years after the release date is nothing more than nerd trivia, people will remember what Firefox 3 did for them, and how well it worked. It’s going to be awesome, even if you have to wait.

Update: Matt Asay has posted a follow-up article. It’s all good.

Eric Shepherd: MDC: Big changes ahead

sheppy — 2007-11-16T20:26:34+00:00

After a lot of research, it looks likely that we’ll be moving the Mozilla Developer Center away from

MediaWiki, which we’ve been using for some time now, to Deki Wiki. There are a number of reasons we’re probably going to be making this move:

Two words: Syntax highlighting. You can specify a language for a code snippet and get syntax highlighting with numbered lines; fantastic for doing explanations of what a sample does.
Deki uses lucerne for searching, and it’s built in, so we don’t have to fight with Nutch. Searches can even go into attached files, so a search on, say, “nsIDownloadManager” will not only find articles mentioning that interface, but also any downloadable code samples that make use of it.
Deki offers a very snazzy WYSIWYG editor which should make it easier for new contributors to get going.
You can easily attach downloadable files to articles, and there’s a nice file manager for organizing these. This will make it much easier for contributors to offer sample code.
Very nice built-in statistic features.
Articles can be keyword tagged.
Advanced printing options, including PDF download option.
Since all content is stored in XML instead of in a database, we have some interesting possibilities for making portable versions of the wiki that could be downloaded and browsed offline.
It looks like it will be easier to customize the appearance and functionality of the site with Deki.

The folks at MindTouch will be writing us a utility to convert our current MediaWiki content into Deki, and will (assuming we do indeed decide to go ahead with this transition) be adding some new features to their software that we’ve requested. This is a huge plus for us: we can get the software revised to meet our needs by people that know the code inside and out.

We’re still working out exactly what changes they would be making to the code for us, but it’s looking very good, and I think folks will be pleased with the result.

Assuming this transition happens, it will take place sometime early next year. Hopefully in the first quarter but I wouldn’t be surprised if it slips into Q2, given the huge amount of stuff that needs to be done to make this happen.

I’ll blog further on this as things develop.

Shawn Wilsher: 80% Won’t Be Fixed?

Shawn Wilsher — 2007-11-16T19:49:22+00:00

I just got done reading Robert Accettura’s post referring to a New Your Times article about how 80% of Firefox bugs won’t be fixed for Firefox 3. Shocking isn’t it? It sure was shocking for me.

I’m really surprised that such a reputable news organization would post such an inaccurate article. The article talks about how only 20% of the blockers are actually expected to be fixed. While this may be true, a bug that is marked blocking-firefox3+ doesn’t actually mean a software bug exists. This is probably the most common assumption that I see people outside of Mozilla making - if a bug is filed on something, that there is something wrong with the product. The reality of the situation is that any change anyone wants to make to the code gets a bug filed for it. This means that if you want to add a feature, you file a bug. You want to rewrite some code but not change functionality? That requires a bug too. Want to remove an unused feature? That also needs to have a bug filed.

Looking at the current Download Manager bugs that are blocking Firefox 3, most aren’t software bugs. About 13 are user interface tweaks, four are feature requests, and the rest are software bugs. Of the software bugs, only six I’d really consider to be serious bugs, while the rest are fairly minor (but minor does not imply trivial to fix - that rant will have to come some other day).

Anyway, my point is that everything you read on the Internet isn’t 100% accurate, so try to think about what it is you are reading!

David Ascher: Open source peer-to-peer transportation systems

david — 2007-11-16T15:53:05+00:00

.flickr-photo { border: solid 2px #000000; } .flickr-yourcomment { } .flickr-frame { text-align: left; padding: 3px; } .flickr-caption { font-size: 50%; margin-top: 0px; }

I’m building a list of reactions to my Paris visit, touching on cultural differences in the world of email, open source, the fascinating things that various folks have done with Thunderbird in France, imperialism, and other topics, but I wanted to make sure to show this picture. There’s a transportation strike in Paris this week (great timing on my part, as usual), which makes getting around a bit harder than usual, although I tend to walk around as much as is reasonable anyway given how nice it is to do so in Paris.

Today though, I was running late for an appointment, so I hopped on one of these puppies:

These slightly frumpy 3-gear city bikes are some of the 20,000 “Velib” that a company has placed in 1000 different locations throughout Paris in exchange for advertising rights. The system is optimized for using bikes as a quick and easy way to move around short distances. With a subscription (ranging from 1 euro for a day to 29 euros for a year), trips of 1/2 hour or less are free, with costs climbing for longer rentals, thereby ensuring that people don’t hog the bikes. Apart from reports of some people using padlocks to “reserve” the bikes in anticipation of the strike, it seems to work great. The stations I see tend to have at least some bikes in them (this one was full, which is actually a problem if you’re trying to return a bike). On Wednesday there were 159,000 trips recorded .

It was a fun bike ride. In addition to the simple pleasure of zipping past cars through sunny Paris streets, there’s something about riding a “Velib” for the first time which reminds me of using open source software for the first time. A joyful personal experience based on a structured shared asset, with positive environmental consequences.

Mike Shaver: correction: Mozilla, StopBadware and Google

shaver — 2007-11-16T15:45:04+00:00

Earlier this week, Chris Soghoian posted an interview he did with me about Mozilla and our relationship with Google, as well as some other security topics. I’d had some concerns with a previous article of his, and I was glad that he was willing to take the time to discuss them with me.

In the course of that conversation, though, I misled him about how the upcoming malware list is managed; I had mistaken StopBadware’s role as review and removal channel for them having editorial control over the list in general, which is not the case. Maxim Weinstein of StopBadware contacted me to correct my misunderstanding, for which I’m grateful, and has provided a great explanation on the StopBadware site:

Mozilla, Google, and StopBadware are all expected to play a role in ensuring that the needs of both users and web site owners will be addressed in Firefox 3. Mozilla is working with Google to provide a list of potentially harmful URLs that will be used by Firefox to warn users before they browse to a site that may contain malware. This data comes from Google’s own scanning and research, not from StopBadware, as reported. (Our Clearinghouse allows users to search for a site to see if it is currently on Google’s warning list.)

StopBadware’s role will be (as it is now) to ensure that users and web site owners receive as much information as possible about the warning and to provide a transparent review process to assist site owners in understanding why a site was flagged and/or notifying Google that it has been cleaned.

By working together, we help protect users from potentially dangerous web sites while ensuring that owners of legitimate sites have a way to understand the warnings, clean up their sites, and remove the warnings.

I think this is a really good model that combines the scalability we need to protect more than 130 million users, the breadth of detection necessary to keep up with the modern pace of attacks, and a transparent and neutral process for reviewing and clearing sites that have been fixed. I just wish I’d understood it properly before speaking with Chris!

Daniel Glazman: OH !

Daniel Glazman — 2007-11-16T11:06:00+00:00

Well...

Josh Aas: Josh

Josh Aas — 2007-11-16T10:47:06+00:00

With Gecko 1.9 development wrapping up, I’ve been thinking about the roadmap for Gecko 2.0’s Mac OS X support. One of the items that we’ll need to consider is architecture support - this is something on many Mac OS X developers’ minds since Mac OS X 10.5 was just released with top-to-bottom support for PPC, PPC64, x86, and x86-64.

I think we should make 2 architecture changes during the Gecko 2 development cycle - add support for x86-64 and drop support for PPC. I think the arguments for both changes are pretty solid.

x86-64 is the future for Mac OS X applications, and that future is likely to come sooner rather than later. Apple has a history of successfully making aggressive changes to their platform in order to stay on the cutting edge, and I think it is a pretty safe bet that come the next WWDC encouraging all developers to move to x86-64 will be a top item on the agenda. They have been dropping technical hints for years and sowing the seeds for this change in their hardware offerings. The reason for this is much bigger than x86-64’s technical advantages though - Apple wants to consolidate. PPC is on the way out altogether, but if 32-bit x86 applications don’t go away soon too then Mac OS X has to ship with support for more than one architecture for a lot longer and users will need to have 32-bit and 64-bit frameworks loaded into memory at the same time. I highly doubt Apple will drop support for 32-bit x86 in Mac OS X 10.6, but I think they would like the average 10.6 user to not ever have to load a 32-bit application for performance reasons. You can bet that they’ll offer some creative enticements for 64-bit migration by making some APIs x86-64-only in 10.6.

Gecko 2.0 is a great time to add support for x86-64 even if the first version of Firefox that ships with Gecko 2.0 doesn’t ship an x64-64 binary. I’m not suggesting that we necessarily make it a tier-1 supported platform, but we can get started down the path to tier-1 quality. It shouldn’t be too hard to do the work, we will have to do it anyway, and by getting this work done earlier we’ll eventually ship a higher-quality x86-64 product with less stress on development and QA.

Obviously PPC is on the way out in the Mac OS X world. I doubt that Mac OS X 10.6 will support PPC hardware, and by the time Gecko 2.0 ships (Q1 2009 at a minimum) we will have very few PPC users remaining. It simply won’t be worth the effort required to support it properly even if it seems like a good idea at the beginning of the development cycle. Not supporting PPC will free up engineering and QA resource to work on much more important things, and we will no longer have to ship a universal binary. PPC users will have access to a supported Gecko 1.9.x Firefox for some time after Gecko 2.0 is released, so it isn’t like they will be without a modern web browser. Dropping PPC support will be unfortunate for some just like dropping support for anything is, but on the whole I think it is definitely the right thing to do for Gecko 2.0.

Update: There is some confusion in the comments about what dropping PPC Mac OS X support would actually mean. First of all, I was referring to PPC Mac OS X only. PPC Linux and any other PPC platforms would not be affected. Secondly, I should have said we would just bump it from tier-1 supported status. There would be little in the way of code changes, PPC Mac OS X builds could remain available through a community effort.

Frank Hecker: Seneca College and open source education

Frank Hecker — 2007-11-16T04:50:00+00:00

I spent October 25 and 26 in Toronto attending the FSOSS 2007 conference put on by Seneca College. I didn't attend the conference primarily to hear the conference presentations; my main aim was to talk with the people associated with two projects that the Mozilla Foundation has funded, namely the Mozilla-related educational activities at Seneca College and the Mozilla-related accessibility work at the University of Toronto's Adaptive Technology Resource Centre.

However as it turns out some of the presentations I saw had interesting connections with my Seneca and ATRC discussions. In this post I'll give my thoughts on how Seneca's efforts relate to the broader world of business and education. (Note that these are my personal opinions only, and do not necessarily reflect the positions of the Mozilla Foundation or Seneca College.)

Open source businesses and the value of commit access

The closing keynote presentation at FSOSS 2007 was by Dirk Riehle of SAP Labs. If you don't have time to watch the video you can get the essential points of Riehle's talk from his original paper and a recent interview he did for Datamation. Riehle's thesis has several parts, including some claims about software industry economics, closed source vs. open source business models, and so on. However in relation to this post Riehle's two most important claims are as follows:

The move to open source negatively impacts the job prospects of the average software developer, but improves the prospects of developers who are core contributors ("committers") to open source projects.
Job and career prospects for committers participating in "community" open source projects ("software that a community develops") are better than those for committers participating in "commercial" open source projects ("software that a for-profit entity owns and develops").

Riehle's contention is that the lowered barriers to learning about and participating in open source projects mean that there are more developers with experience with such software. Thus the typical developer within an open source project will encounter relatively intense competition for job opportunities relating to that software. But if a developer advances within a project to become a core contributor and gains commit access then they will be more attractive candidates, particularly to companies with an interest in having influence within that project.

According to Riehle this dynamic works best in community open source projects (e.g., Linux, Apache, Eclipse) where there are multiple companies that can gain advantages from employing committers, and hence competition among companies to recruit the relatively scarce candidates. In commercial open source projects (as defined by Riehle) a single company typically employs all (or nearly all) committers, so bidding wars to hire committers are minimized.

Creating Mozilla contributors

What does all this have to do with Seneca? Many traditional universities and colleges are research institutions; two of their most important products are published papers and the people who produce them. On the other hand Seneca is (to quote from its full name) a "College of Applied Arts and Technology"; its goal is first and foremost to produce graduates who have marketable skills. Seneca's Mozilla-related activities clearly support this goal:

Based on various reports from existing Mozilla contributors and others, the students in Seneca's Mozilla- and open source-related course appear to be getting valuable hands-on experience in what it takes to participate in the Mozilla project, whether that be as testers, build engineers, developers, or whatever. In effect Seneca is training a cadre of people who likely have a much better chance of becoming core Mozilla contributors than typical computer science graduates. If we accept Dirk Riehle's thesis (and it seems plausible) then these Seneca students will as a consequence have correspondingly better prospects for lucrative employment, whether at the Mozilla Corporation or one of the other companies looking for Mozilla- and Firefox-related expertise.

It's worth noting here that although the Mozilla started out as a corporation-initiated and -sponsored open source project and is still dominated by a single organization, in practice it has many aspects of Riehle's community open source projects. (Why this should be so is a topic I'll skip in the interests of brevity; however I think the non-profit nature of the Mozilla Foundation is a major factor.) In particular, although the Mozilla Corporation is still the largest employer of Mozilla developers there are now several other companies that have a vested interest in having some influence over Mozilla development, and that Mozilla developers and other contributors might consider as potential employers.

Seneca College and disruptive innovation in higher education

At FSOSS 2007 I had a conversation with David Humphrey and Chris Tyler of Seneca about additional things Seneca College could do in the Mozilla and open source spaces, and how the Mozilla Foundation might help Seneca achieve such new goals. Since our ideas about that are still in flux, I'll skip any detailed remarks on that topic for now. Instead I'll discuss a different topic, namely, why Seneca College? Sure, Seneca is in Toronto, and so are a lot of Mozilla folks, but to be honest although I was previously aware of several Canadian academic institutions I'd never heard of Seneca prior to its Mozilla activities. If it's a simple matter of proximity to Mozilla people then there are a lot more Mozilla people in Mountain View than in Toronto, not to mention world-class institutions like Stanford University and UC Berkeley.

So what's going on? I think this is a perfect example of "disruptive innovation" acting in the education market, and as it turns out Clayton Christensen provided a helpful guide to it in his book Seeing What's Next. In this view institutions like Stanford and Berkeley are focused on "sustaining innovation", i.e., improving the "product features" for which they've been traditionally recognized and valued by their most demanding customers: a comprehensive computer science curriculum, leading-edge research programs, and tight relationships with local entrepreneurs and venture capitalists that can be leveraged for the benefit of the institution and its students. (This last advantage can be had even without completing one's education, hence the "college dropout turned Silicon Valley entrepreneur" phenomenon.)

Elite institutions like Stanford and Berkeley are doing fine by their own lights, and we'd therefore expect truly disruptive innovation in higher education to occur not at those places but rather at institutions on the margins. Christensen notes three trends in education that represent disruptive innovation at work, and all three are relevant or potentially relevant to the case of Seneca:

The first trend is the growing popularity of community colleges and other institutions that offer cheaper alternatives to traditional four-year degree programs. This trend, of which Seneca is a part, is an example of "low cost" disruption: As traditional degree programs become increasingly more expensive, students look for other options that are less expensive but still good enough to serve their own personal goals, which are often more limited than those of students who attend elite institutions. (Not everyone aspires to be—or is cut out to be—a famous and wealthy entrepreneur; many people would just like a well-paying job doing work that's personally satisfying.)

The second trend noted by Christensen is the growth of for-profit institutions (like the University of Phoenix) that are targeted at older part-time students and make heavy use of distance learning using the Internet. This is an example of "new market" disruption, bringing additional higher education to people who traditionally did not pursue it. (Christensen's phrase for this is "competing against nonconsumption".) Seneca College is a public non-profit institution (chartered by the province of Ontario), and to the best of my knowledge Seneca's Mozilla-related activities conform to the more traditional model of young students receiving on-site instruction. However it's perfectly possible to imagine people already working in the IT field who might want to get an entree into new and exciting areas like open source development, and due to its distributed and decentralized nature open source development should be a good match for Internet-based learning.

The third (and I think most interesting) trend noted by Christensen is the rise of "corporate universities" providing specialized training to a corporation's employees, including such prominent examples as Motorola University, GM University, and GE's John F. Welch Leadership Center. Christensen discusses this trend (another new market disruption) mainly in the context of management education, with corporate training serving as an alternative to traditional MBA programs:

Traditional business programs excel at training managers in general business theory and exposing them to a diverse network of business leaders. But they are ill-equipped to provide learning customized for an individual company or individual employees. Corporate training programs lack campuses or access to a high-powered alumni network outside of the company. But modular, customizable corporate training has an advantage that independent M.B.A. programs can't match—a product specifically designed for each employee's needs (Seeing What's Next, p.112)

By analogy, Seneca is offering an alternative to traditional general-purpose computer science programs based on the ACM/IEEE curriculum, an alternative that is tailored to the particular task of teaching students to be productive contributors to an open source project (in this case Mozilla), thereby increasing their value to employers participating in that project. Seneca is thus in effect serving as an outsourcing provider for a prototype "Mozilla University".

Note that this "open source university" idea is even more powerful than the typical corporate university discussed by Christensen, at least as it might be applied to Riehle's community open source projects. For example, graduates of GM University no doubt learn many things that would be useful were they to leave GM and go to work for another auto manufacturer. However they'd still likely face a learning curve getting up to speed on the "Toyota way" or the "Ford way" as opposed to the "GM way"; this encompasses both learning explicit knowledge about corporate products and processes as well as acquiring more tacit knowledge that can be gained only through active participation in the corporate culture.

On the other hand, since Riehle's community open source projects (Linux, Apache, Eclipse, etc.) are cross-company by definition, a graduate of (say) a hypothetical "Linux University" would likely face minimal barriers moving between any of the companies involved in Linux kernel development; ditto for Apache, Eclipse, and (as noted above) Mozilla itself. This is especially true if the curriculum required students to invest a substantial amount of time in actively participating in the project in question (as Seneca's does).

Asymmetric competition in higher education

As noted above, Seneca College and similar institutions are still bit players in a world of traditional computer science programs dominated by the elite research institutions. But need this always be the case? One of Clayton Christensen's key concepts is "asymmetric competition", in which new entrants to a market take advantage of opportunities relatively ignored by incumbents and in the course of doing so can grow to eventually threaten the dominance of incumbents. (Christensen uses the metaphor of new entrants being defended by the "shield of asymmetric motivation" and learning to wield the "sword of asymmetric skills".)

Programs like Seneca's demonstrate possible new ways to teach software development: in the context of large real-life projects, with an emphasis on the social and community aspects of projects, and through an inter-disciplinary approach that teaches not just programming but also other skills such as QA and testing, release engineering, user-centered design, evangelism and marketing, and even software as a business. As open source development and related trends (e.g., agile development) take hold, Seneca and other institutions that might emulate it could find themselves more aligned with the needs of both students and industry, and more successful as a result.

As noted above, the elite institutions have no real reason to be threatened, at least not in the next few years; if nothing else their importance as hubs of business networks will ensure their relevance. As they move up market Seneca and others like it are much more likely to threaten the dozens of conventional computer science programs at second-tier institutions. (One sign of this is Seneca's move to offer a four-year "bachelor of software development" degree.)

However in the long run Seneca or another similar institution could potentially break into the ranks of elite institutions, albeit an elite that might be based on somewhat different criteria than today. After all, if an institution like Stanford, originally founded as a "avowedly practical" institution (in contrast to traditional east coast universities), could ride the wave of post-WWII technology and business advances to become the "Harvard of the West", who's to say that Seneca (or a Seneca imitator) couldn't aspire to some day be the "Stanford of open source"?

Robert Accettura: 80% WONTFIX?

Robert — 2007-11-16T04:35:57+00:00

I hate when misinterpretations become seen as fact. Supposedly 80% of Firefox bugs won’t be fixed. That’s said to be a bad thing. Here are some realities:

In every release cycle, everyone wants every bug to block a release and therefore everyone is “blocker-happy”, and later in the cycle, all are changed to non-blocker status except the most critical as perceived by developers, drivers, and testers.
Every release of Firefox, like every release of every large software project ships with thousands and thousands of documented bugs. The overwhelming majority of which nobody encounters, or are so minor you don’t even notice.
This process isn’t new, it’s been happening since the early days of software development.
If this process didn’t work like this, there would never be a release of major software products.

A bug is either a defect or an “unintended feature”. Complex products like browsers have thousands. This isn’t a surprise to anyone who works with software on a daily basis. Why? Because every bug you fix, feature you add introduces new code, which potentially causes new bugs in other places. Even if you devote 100% effort to fixing bugs, you’ll likely never get there. That’s the nature of the game. So what makes one bug worthy of blocking? Well generally they must meet some requirements:

Must be reproducible and clearly a bug (not a Firefox doesn’t load ActiveX).
A fix must be identifiable and achievable.
Must be in a more visible location. It’s not effective to allocate large amounts of effort for something so obscure 1 in 10 million people will ever encounter such a testcase.
Must be severe in some sense (data loss, security, usability, performance, etc.)
Fix must not be beyond risk tolerance threshold.

or, it must be a project requirement, meaning a feature that is deemed necessary to ship the release and worth holding for (artwork for UI for example).

Every project involves deciding what bugs ship, and what holds a release. Every single one. If there’s someone who doesn’t, it means their QA is likely flawed or inadequate. Firefox has the advantage of thousands of nightly testers. This helps quite a bit not only finding bugs, but seeing how prevalent a particular bug is, and what it’s impact is.

One should note that just because something isn’t blocking, that doesn’t mean it won’t get fixed. It simply means the release won’t be held for that bug. Should someone fix it, and it’s approved, it can still potentially make the release. The key is that the fix be low enough risk that the benefits outweigh the risk of potential regressions.

If you’re still shocked by this, let me alert you to something: the product (browser, feed reader, etc.) you are using to read this has thousands of bugs. The OS it runs on, has thousands of bugs. Any alternative you pick will be the same. Pick your poison.

I should note these bugs do not get marked as WONTFIX or INVALID. They remain open. They may be fixed in a subsequent release or they may just become outdated and fixed through some other means (code is depreciated and replaced with something else, feature dropped, revamped).

Planet Mozilla Blog: Planet Addition: Community Surveys Blog

Reed — 2007-11-16T04:11:38+00:00

Community Surveys Blog (feed) - A blog about community survey announcements and recent survey results.

Robert Accettura: The Shape Of Firefox 3.0

Robert — 2007-11-16T03:42:10+00:00

Alex Faaborg has an awesome post on UI changes for Firefox 3.0. It’s a little lengthy, and most pics are wireframes but it’s a rewarding read for anyone in the browser space, or has an interest in user interface.

Overall I like most of the changes. I’ve been ranting about a need for a better bookmarking interface since 2005. Not sure if I was ahead of my time, or just impatient (likely the ladder), but it’s finally becoming a reality which I’m thrilled about. I’ve got some ideas on where it could go from here to make it even better, but that’s another post I hope to get to sometime.

One change that caught my eye is this:

-The lock is being removed from primary UI, and Firefox will now use a metaphor based on identity, rather than security, which will appear on the site button if an SSL or EV certificate is available. The super short explanation for this change is that the user might have an encrypted connection to criminals, so telling them that they are safe is a false cue. For an in-depth discussion of why we are moving away from the metaphor of a lock, watch Johnathan Nightingale’s Mozilla24 presentation Beyond the Padlock.

I’m not sure if this is really the best solution. I’d personally like to see the lock stay in the UI, but it’s meaning redefined. For a decade or more, the public has been told that the best way to tell if your information is safe is to look for the lock. I’d venture 99% of the general population doesn’t really know it symbolizes the use of SSL. They just know that it means your information is “safe”. My thinking is that it would be the most graceful transition to map that to the new identity system. Essentially the information it reveals would be the new identity information, but it provides backwards compatibility with previous versions, and other browsers. One less learning curve. Still in regards to safety, look for the lock.

Regarding the iconic form:

Image from Alex Faaborg The Shape of Things.

I could make a rather infantile joke, but I’ll leave that as an exercise for the reader.

Overall it’s some great progress. I think these changes allow for a much more functional user interface with added features and less UI. The native appearance will also be excellent for Mac and Linux users who have longed for a UI that looked “right” on their systems.

Songbird: Seeking the best of Build & Release Engineer

2007-11-16T02:18:39+00:00

Are you interested in being at the center of the delivery of a cross-platform, open-source, desktop media player to the world?

We are looking for an exceptional build & release engineer who can insure that our build farm is humming and that Songbird gets installed safely on millions of desktops.

We need someone who relish the challenge of automating the customization and packaging of our product for hundreds of distribution partners.

Our build system needs to be automated, modular, scalable and flexible. Our process needs to support 40+ languages, Windows, OSX and Linux on various architectures, 100+ customizable add-ons, feathers, etc. Keeping the configuration matrix under control is a challenge within of itself. Sounds like fun? We think so.

If makefiles make sense to you, if you are obsessed with details and love making release check lists, we want to hear from you!

Check out our job description and read more about what's like to work at the nest.

Chirp,
Georges

Robert Kaiser: "Source L10n" Available For SeaMonkey Trunk

KaiRo — 2007-11-16T00:46:13+00:00

I'm proud to announce to SeaMonkey localizers that the suite is ready to start into the world of so-called "source L10n", i.e. building localized builds based of files that are all available in our public repositories.

With that, the development trunk of SeaMonkey, which is in a pre-Alpha state for a future SeaMonkey 2, will be localizable using the Core L10n files that are already in CVS. with additional SeaMonkey-specific files added in the suite/ subdirectory and some in the editor/ui/ subdirectory of the respective language directories in the l10n/ CVS repository.

If the SeaMonkey localizer for a language has already CVS access and he is the locale owner or gets authorization from the owner, and if a Firefox localization is already present (and therefore the "core", i.e. dom/, netwerk/, security/ and toolkit/, as well as extensions/reporter are already present for their localization), he can add the SeaMonkey-specific files to the L10n CVS right away. Else, the locale owner or a peer that already has CVS access can do the checkins, and the SeaMonkey localizer should file a bug for CVS access and let the locale owner vouch for him. In any case, the core as mentioned above should be in the tree first. If no core localization is present yet, please follow the Firefox rules for getting the core L10n files in first.

Once your localization gets complete (check that with compare-locales), please file a bug for adding your locale to all-locales for SeaMonkey (in "Mozilla Application Suite > Build Config") and assign it to "kairo@" so I can add you there and repackaging of nightlies will be done.

We don't need any special reviews for bookmarks, start pages or search engines at the moment as we have no special agreements with any providers of such resources. You probably should keep the existing default bookmarks unchanged though, possibly adding a small (!) selection of localized ones - not without asking the link targets if they are OK with that, though.
You also should only change any URLs we point to if you really know what you are doing and have ensured that the target can handle the amount of traffic generated by this change and you are allowed to use any brand that might occur in SeaMonkey due to your changes. This is true for bookmarks, stage pages and search engines as well as any other URLs in SeaMonkey. Be careful with all of those!

For the technical side of search plugins, the only file you need to have in that dir is the list.txt file, please do NOT copy the en-US plugins themselves, if the list.txt points to a plugin not existing in your locale but in en-US, the plugin from en-US will be packaged automatically. If you add plugins for local search providers, you need to add the base name of the files in list.txt and provide a .src and .png file for the search plugin, using the "old" sherlock format as used by mycroft.mozdev.org. Note that all icons need to be PNG, not GIF or something else, as our localization process only picks up .png files.

As we are still in pre-Alpha with this SeaMonkey development cycle, we have not yet figured out exactly how we will deal with releases, I hope I can give a better picture of that when we are nearing Alpha. What we know, as that we'll probably go into the final localization freeze for or shortly after Beta, but we don't know yet when this will exactly be.

Once a locale has been added to all-locales, you'll notice the SeaMonkey nightly build machines appearing on the respective Mozilla-l10n-* tinderbox waterfall page and nightly builds generated when those columns there are green. Those nightly builds will appear in the latest-trunk FTP directory and should be usable to a big part.

Warning: We know of some features that are still broken in localized builds at the moment, those are all marked as dependencies of the source L10n bug: Download manager and password manager windows do not work, as well as system integration hooks (on Windows) - we are working on replacing the old implementations of those with newer ones and therefore did not enable the old code to work with source L10n.

I hope we can improve quality and availability of SeaMonkey localizations with this step, so that SeaMonkey 2 will be an even better suite product than any other such all-in-one application before.

Mike Shaver: on evangelism

shaver — 2007-11-16T00:29:29+00:00

I was going to write about the latest addition to our team, but then I realized that I still haven’t actually posted about what the Evangelism team does here at Mozilla, and we’ve been together for about 3 months now.

Here’s what we’re set up to do:

Help people understand Mozilla
Help people connect productively and enjoyably with the Mozilla project
Help Mozilla communicate “with itself”
Help people understand, build, and benefit from the open web

I’ll elaborate on each of those in upcoming posts, because I think they’re each important and interesting, but the core concept that we’ve been using to organize our thoughts so far is one of “stories”. What should the story of a new contributor getting involved be like? What’s the story of the performance work happening in Firefox 3? What is our story on standards, specifications, and interoperability? What story do we need to tell to explain to people why accessibility and cross-platform technologies are important? Stories aren’t always in narrative form — though when they can be, it’s often both fun and inspiring — and they’re definitely not intended to be fictional. We might tell stories that are aspirational, describing what we want the experience to be for someone who wants to help web sites become more compatible with all browsers, but we won’t tell lies. We’ll make mistakes, and we’ll change our minds, and we might have to simplify to make things understandable, but we won’t lie to people. We don’t need to — the true things about Mozilla are fantastic — and we just aren’t good at it. Mozilla is a project that is defined by openness and candor, and fighting that nature is neither productive nor viable in the long term.

We’re going to work on helping identify and refine important stories, as well as finding ways to make some aspirational stories come to life, but we’re also going to help people tell their Mozilla stories. From a peek inside the history of Mozilla’s test automation to what’s involved in a briefing with a reporter, we want people to understand what all is going on with the Mozilla project. Helping the right stories get to the right audiences — within the community and beyond — is a big part of the value we need to provide, and we’re ready to get started.

Evangelism isn’t just about saying nice things, since productive attention to challenges and mistakes is a critical part of improving how we work, and it’s not about making everyone love Mozilla. It’s about making sure that the great things Mozilla does are visible to the world, encouraging people who share our values, and helping our unique project work together better. It’s not going to be how everyone else does evangelism, but after nearly a decade of working on Mozilla I’m used to us just being kinda different. We’ll overlap in some areas with marketing, public relations, and other activities — if we do our jobs well, we’ll probably overlap with just about every part of the project! — but we’re concerned with helping out and not with defining territory.

If you’ve been around the project for a long time, the term “Evangelism” probably makes you think of “technical evangelism“, which was the term used for people doing outreach to sites that were not compatible with web standards, and helping/encouraging the site owners to repair their problems. That’s a very small subset of the sorts of evangelism that we’re starting to work on, and to be frank we’re unlikely to do very much such technical evangelism directly, though we’re definitely interested in helping organize and support those who do. (In fact, we have some ideas about that very topic!)

Next up: meet the MoCo Evangelism team.

Alex Faaborg: The Shape of Things to Come?

Alex Faaborg — 2007-11-16T00:25:32+00:00

Firefox 3 Wireframes

Over the past couple of weeks I’ve been driving the design of a cross platform shape and control set for Firefox 3. I’ve been working with the Firefox 3 drivers Mike Connor and Mike Beltzner, along with Mozilla’s interactician Madhava Enros, Dave Brasgalla from the Iconfactory, and our OS X theme contributers Stephen Horlander and Kevin Gerich. Here is the current design, which has already gone through a lot of iterations. We are very interested in people’s thoughts and feedback.

Our goals are to design an interface that is simple, modern, and visually lighter than previous versions of Firefox. A lot of careful thought went into determining which controls we could integrate or remove. We also focused a lot on how we could leverage visual design (namely grouping and patterns) to form a user interface that is both simpler and easier to use. All of this work is still in progress, but here is the current design for OS X, Windows Vista, and Windows XP. Click through for the full mockup.

The reason Linux isn’t shown above is that all of the feedback we’ve received so far indicates that Linux users would be happier with a theme that uses native GTK icons in the navigation toolbar, which rules out this type of customized visual treatment. Linux theme work is really active right now, see the details in my last post, and some really thorough coverage over at Ars Technica.

Here is a recap of what we changed, what we removed, what we added, and what we didn’t change. We are always open to lively debate about what should or shouldn’t be in primary UI, so feel free to voice your opinion in the comments. Note that the title of this post is a question, not a statement. This isn’t a final design for Firefox 3 as much as a snapshot of our current thoughts.

What we Changed

-The back button is larger than the forward button. We did this for two reasons: first, it’s a really important button. We could probably ship a Web browser with just a location bar and a back button, and a lot of users would be totally fine with that. By making the back button larger we make it easier to visually target and hit, which isn’t the kind of thing you will necessarily consciously notice, but the best improvements to usability are often things you don’t consciously notice. The second reason we are interested in making the back button larger is to create a unique visual identity. This form serves as a visual cue that you are looking at Firefox 3 (lengthy discussion below). On OS X we are experimenting with making the toolbar 15 pixels taller, and on Windows the toolbar height is currently remaining the same.

-The home button is now the first link on the bookmarks toolbar. We are planning on keeping it in the customization pallet so users can add it back to the navigation toolbar if they really want it there.

-The throbber is being relocated to the site button. This gives it a visual and conceptual mapping with the URL being loaded, and places it directly next to the stop button (and near the refresh button and the navigational controls) so the user will immediately see feedback when interacting with these controls, as opposed to having to move their gaze to the far right side of the browser.

What we Removed

With the Web feed icon, star icon, go button, lock icon and drop down control all appearing on the right side of the location bar, we’ve recently been referring to this area of the UI as our “lucky charms” (purple horseshoes have sadly been pushed back to Firefox 4 due to a lack of developer resources, but we are accepting magically delicious patches). In these wireframes we’ve downsized from 5 lucky charms to 2: Web feed and star.

-The lock is being removed from primary UI, and Firefox will now use a metaphor based on identity, rather than security, which will appear on the site button if an SSL or EV certificate is available. The super short explanation for this change is that the user might have an encrypted connection to criminals, so telling them that they are safe is a false cue. For an in-depth discussion of why we are moving away from the metaphor of a lock, watch Johnathan Nightingale’s Mozilla24 presentation Beyond the Padlock.

-The go button now only appears when you are typing in the location bar, replacing the Web feed and star buttons as the only item on the right side of the location bar.

-In this design the drop down marker in the location bar now only appears when you hover the mouse on the location bar. The rationale was that we wanted to keep the control around for people who regularly use it (and already know that it is there), but are otherwise hiding it to reduce the overall visual complexity of the right side of the location bar, and because we don’t feel that this control needs to be discoverable.

What we Added

-The right side of the location bar now has a star icon that allows users to bookmark a Web page with a single click. We’ve found that a lot of users don’t bookmark pages anymore because it is actually easier to just search Google for any Web page that you want to visit again. So our objective when redesigning bookmarking in Firefox 3 was to create a system that was even faster for users than searching Google. Here is how it works: a single click on the star icon bookmarks the page and ensures that Firefox will never forget that you visited it. You can now search for the page again by entering any part of the title or URL In the location bar, which is more efficient than sending your search across the network, waiting for Google to generate a results page, and then locating and selecting the correct result on that page.

-The left side of the location bar now contains what we are calling the site button. Clicking on this button displays information about the identity of who you are connected to (SSL or EV certificate) if available, and in future releases we may also include actions that are contextual to the Web site you are on when you click the site button.

-On Windows we are experimenting with a small control between back and forward called the history button. This is functionally the same as the integrated drop down menu in IE7, although we believe the clock metaphor will hopefully be more descriptive than a down arrow. In particular, this is one part of the design that we are still iterating on.

What we Didn’t Change

There are lots of things we didn’t change, but I think these two decisions in particular are notable:

-The search bar and the location bar are still two different fields. Overall it seems like this is pretty redundant UI, especially since the location bar in Firefox 3 behaves a lot more like a search field (it even now contains the self describing text “Search Bookmarks and History”). However, integrating the two fields is certainly a non-trivial UI problem. Specific challenges include the fact that you should always show the location that the user has navigated to, but novice users will be reluctant to edit and replace any text that they don’t understand (and most URLs are not human readable.) Also, users who are concerned with privacy enjoy knowing when Firefox is making a network connection or not, and they don’t necessarily want everything they type into the location bar handed to a third party search engine. Additionally, the best way to integrate search suggestions with location bar auto-complete results isn’t very clear. If anyone has solutions to these three UI problems, by all means please post an answer in the comments.

-Stop and refresh are not the same button. A lot of people have suggested that we follow Safari’s lead and integrate stop and refresh. There are also some Firefox extensions out there that do this. The reason we decided not to integrate the two buttons is the case where you are thinking “this page is taking forever to load, I’m going to stop it” but then, a split second before you down-click, during the time in which your brain has sent the signal to your hand to carry out the action, the page finishes loading, the button changes state, and you end up doing the opposite of what you actually wanted, and think “@$%&!” Overall I think the speed of the user’s connection plays a large role in determining how often they will hit the wrong control. For instance, I rarely experience this problem when using Safari on a broadband connection, but I do commonly experience it when using an iPhone on the edge network. So to avoid potentially frustrating the user, we don’t think we should integrate the two buttons. However, integrating the two is a pretty big visual simplicity win, and the annoying situation is a boundary case, so there are definitely two sides to the debate.

Notes About the Design

In addition to the comments above, here are two accompanying mockups that explain in detail some of the very specific visual design and interaction attributes of the current iteration of wireframes:

Notes on the Design

Circle to Square Height Ratios on Various Platforms

Platform Integration vs. Cross Platform Identity

In a previous post about the visual refresh for Firefox 3, I discussed our goal of visual integration with each platform. This strategy has a number of advantages, including presenting you with an interface that feels familiar, and reducing the negative feeling of adding something foreign to your system. We also what to ensure that as you move between Firefox and other applications on your system, the transition does not feel jarring.

However, morphing Firefox to visually integrate on each platform has one very serious downside: we risk losing Firefox’s identity. How do we achieve perfect visual integration with OS X without looking like Safari? And how do we achieve perfect visual integration on XP without looking like IE6, and Vista without looking like IE7? In a lot of ways these two goals, achieving visual integration on each platform, and maintaining a consistent cross platform identity, are diametrically opposed. However, we’ve been working on trying to pull off both.

Our strategy is to divide up the different visual variables across the two different objectives. Contrast (value), color (hue) and texture are used to integrate with the platform, while shape, position, orientation, and size are leveraged to create a cross platform identity:

Note: the visual variables shown in this diagram are from a slide by professor Rob Miller at MIT

Another way of thinking about this strategy is that the objects remain the same across platforms, but the materials that these objects are made out of (metal, glass, plastic) change based on what OS you are running Firefox on (OS X, Vista, XP). For instance, here is the iconic shape for back and forward that gives Firefox a cross platform identity:

And here is the same object constructed out of metal, glass, and plastic, for visual integration with the different platforms:

There are a few exceptions to this approach, in particular the stop and refresh buttons appear as glyphs on shapes on OS X, instead of glyphs floating in space, and each design leverages platform specific curve ratios. Also, we are playing around with the idea of a history button on Windows, but we are still working on that design.

Establishing Identity Through Shape: Iconic Forms

Taking the discussion to a much more theoretical level, I want to discuss why I think it is important that Firefox 3 has a unique shape, and the fundamental role that shape plays in establishing identity. When we think about identity, we often focus on brand names and logos, but many objects are so visually unique, that their shape is the only thing needed to differentiate them from every other object in existence. We are so good at processing visual information that even a simple wireframe results in us easily recognizing an object. For instance, consider common tools:

After interacting with these tools, their form becomes extremely recognizable, even when shown in 2D using a simple outline. For these tools their form is dictated by functionality, as opposed to a desire to be recognizable. However, some objects have become iconic due to their clearly recognizable form. For instance, consider this hat:

Only three intersecting circles, but this is one of the most iconic forms the world has ever seen. Great designers are able to leverage simple and recognizable shapes to construct iconic forms that make their products memorable and easily differentiated from competition.

Firefox has been incredibly successful primarily because it is a fantastic product. The marketing around Firefox has also been extremely well done. Firefox has a great name, and a gorgeous and easily recognizable application icon. However, the tool itself has not been designed to contain an iconic form, a shape that you would recognize even if you only saw its’ shadow, or an outline. I believe Firefox 3 should be recognizable even if you are only viewing it momentarily, looking over someone else’s shoulder. Since the navigational controls are something we constantly view and interact with, that makes them a great candidate for trying to establish a recognizable shape:

This is just one example of the kind of shape we could use. Hopefully, whatever we end up going with, you’ll be able to catch a quick glance of it and still immediately know that just saw Firefox.

QMO: If you missed the Pre-released Firefox 3 Beta 1 Testing boat...

tchung — 2007-11-15T23:40:27+00:00

....You're not too late for Round 2! Last week was a great time for eager beavers to help test out pre-released builds of Firefox 3 Beta 1. It was such a hit, that we've decided to extend one more week for everyone to help us bless the beta before releasing next week. So join us tomorrow (11/16) between 7am - 5pm PST on irc.mozilla.org, channel #testday, grab a pre-released beta 1 rc3 build , and have some Mozilla fun!

Stuart Parmenter: pavlov

pavlov — 2007-11-15T23:15:11+00:00

I’ve had a lot of people ask whether the memory improvements that I’ve been doing recently will make it in to Firefox 3 or if they’ll only appear in a more future release.

The basic answer: many of these fixes will be included in Firefox 3, but not all of them.

The more complicated answer is that we’re still analyzing the problem and working on solutions. At this point, we’re still digging through the data and finding hotspots. We’ve already identified quite a few places where we will be able to make improvements — some big and some small — and we’re evaluating each for overall invasiveness and impact so we can make the best decisions possible about how and where to implement these fixes.

As we’re already in the beta phase for Firefox 3 we have to be very careful not to add too much risk to the process, so we’re prioritizing memory improvements to get the biggest improvements for the least additional risk. This isn’t to say that we won’t work on fixes with higher potential risk, but we do have to be very careful. What this means is that we won’t be able to address every single issue, but should be able to knock out the big ones in time for Firefox 3.

Eliminating memory fragmentation entirely is almost impossible. We’ve got some amazing tools built now to debug the issues and test our progress. We’ve got several big issues on our radar that we believe will give us big wins. The current plan of attack is to reduce numbers of allocations, group allocations of similar lifetimes together in to pools, move areas with similar size allocations in to their own areas in memory, and to look at general malloc replacement solutions. We’re looking at all of these things in parallel and have some data on each but not enough to report anything useful yet. I hope to have some good data on each of these areas by early next week. We’ve built some pretty amazing tools for testing our progress and will be able to show visually how we’re improving.

With as many of these fixes going in to Firefox 3 as possible, Firefox 3 should provide significant improvement in long term memory use over previous versions.

MozillaZine: Updates

mozillaZine.org — 2007-11-15T23:06:59+00:00

Several security and stability updates have been released in the past three months including:

Camino 1.5.3

Mozilla Firefox 2.0.0.9

Mozilla Thunderbird 2.0.0.9

SeaMonkey 1.1.6

Sunbird 0.7

We apologize for the lack of news updates in the past few months. We are planning to update the mozillaZine news software in the near future. In the meantime, please use talkback on this article as an open discussion forum.

Talkback

Mike Shaver: two things you should read

shaver — 2007-11-15T21:55:41+00:00

One thing about work: Stuart has a truly excellent post about memory work in Firefox. The sort of post I’ve been wanting to figure out how to write for some time, and he just plain-out nails it.

One thing about not-work: my lovely sister Steph is featured in an article in the Montreal Gazette, which — in spite of the strange headline and conspicuous lack of photo — I found quite enjoyable.

Deb Richardson: Great example of how to post slides

dria — 2007-11-15T17:35:01+00:00

Stumbled across a post in my feeds today that rightly points out that there is a better way to post slides. The example that inspired this is Security and Disruptive Innovation: Part I over at the Rational Survivability blog.

Posting your slides in a blog post accompanied by a brief narrative of each slide’s talking points is great for a bunch of reasons, and I think it’d be awesome if more people followed this lead.

Doug Turner: Tinderbox for 1.9-browser-chinook-armel

dougt — 2007-11-15T17:34:35+00:00

http://tinderbox.mozilla.org/showbuilds.cgi?tree=Testing

The first arm linux build of firefox. ever.

Lots of stuff to do, but this is a great start.

push out builds
run tests (emulated)
move to different tree
build xulrunner instead of browser

Alex Vincent: Web 2.0, Dilbert Style

WeirdAl — 2007-11-15T15:19:51+00:00

Today's Dilbert is probably an old joke, but a good one.

Mike Shaver: server switch

shaver — 2007-11-15T13:00:22+00:00

I finally got off my butt and moved my blog to the new machine that has php and mysql of appropriately recent vintage to actually run a supported version of wordpress; if you’re reading this, all went quite well.

Myk Melez: Alt-Tab-like history navigation

Myk — 2007-11-15T11:15:49+00:00

Here's an idea for an extension that I'll probably never get around to writing (but one of you might, perhaps for the extension contest!):

Overload Alt-(Left|Right)Arrow, the history back and forward keyboard shortcuts (Cmd-Arrows on Mac), to create an Alt-Tab-like experience with a row of thumbnail previews to which you can navigate by holding down the Alt key, pressing the arrow keys multiple times until you reach the target page, and then releasing the Alt key.

In other words, do the same thing for history navigation that Dão Gottwald is doing for tab navigation with his Ctrl-Tab extension.

(Bonus points for version 2: track non-linear meanderings and expose them as parallel tracks to which you can navigate with the up and down arrows.)

David Miller: Free SIP on Leopard exists after all!

justdave — 2007-11-15T09:14:56+00:00

So it’s been a few weeks since Mac OS X 10.5 (Leopard) came out. One of the major things that immediately hit a lot of people was that every known third-party SIP client stopped working. I work from home. I have an extension number at work that rings on a Polycom phone in my home office, thanks to the magic of VoIP. This same VoIP technology (namely SIP) has allowed me (up until I upgraded to Leopard) to run a “soft phone” program on my laptop to allow me to connect to the same phone system when I was out of my office. With the help of a set of headphones, a laptop actually makes a halfway-decent phone.

The two free (as in beer, not freedom) products previously available that I knew of were SJPhone and X-Lite. Both of these broke on Leopard. SJPhone hasn’t been updated in years, and the material on their website makes it look like the Mac version was an afterthought anyway, so I don’t hold high hopes for them ever updating it. X-Lite is a pared down version of a commercial product called eyeBeam. eyeBeam just got updated for Leopard this last week. An X-Lite update is expected “by the end of the year”. The obvious reason for the delay is to encourage people who are frustrated enough to throw money at it to upgrade to eyeBeam instead of waiting.

There *are* two free products that have been updated for Leopard which do SIP to a generic PBX of your choosing. Those are SightSpeed and Gizmo Project. Unfortunately, both of these require you to register with their service, and sign in on their service, and your generic-PBX-of-your-choosing account is a secondary login (if you don’t log into their service, your generic one won’t connect either).

The world is in really dire need right now of a good open source solution for SIP on the Mac. If any of the above programs were open source, I would bet we would have had patches posted somewhere within days (if not hours) to make them work on Leopard.

UPDATE: I was going to post this hoping to get some discussion going and/or someone to point out something that works that I missed. But before I could post it, I found one! XMeeting not only works on Leopard (it apparently didn’t break — there hasn’t been a release since July), but it also supports DTMF (touch tones) during the call, which is the one thing that’s been missing from all the other free stuff I’ve tried so far. Touch tones during a call are pretty important for things like entering the password for a conference call. XMeeting supports video, too (and so does Mozilla’s phone system).

Myk Melez: tabs for Thunderbird 2.0.0.9

Myk — 2007-11-15T08:26:52+00:00

Anticipating requests, I've spun some tab-enabled builds of the latest version of Mozilla's mail/news desktop app for Linux, Mac, and Windows.

Note that the Mac version is no longer compatible with Mac OS X 10.2, as my Mac build machine (a.k.a. my laptop) has been upgraded to Leopard and XCode 3.0 and no longer has the 10.2.8 SDK on it. It should work on 10.3.9+, 10.4, and 10.5, however.

p.s. Congrats to the Thunderbird team on the release of 2.0.0.9! Getting a security and stability release out the door is no mean feat, requiring careful coordination between several groups of talented folk with a high standard for software quality that they consistently achieve. Bravo!

Mozilla Developer DevNews: Thunderbird 2.0.0.9 security and stability release now available

beltzner — 2007-11-15T08:14:01+00:00

As part of Mozilla Corporation’s ongoing stability and security update process, Thunderbird 2.0.0.9 is now available for Windows, Mac, and Linux as a free download from www.getthunderbird.com.

Due to the security fixes, we strongly recommend that all Thunderbird users upgrade to this latest release.

If you already have Thunderbird 2.0.0.x, 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 Thunderbird 2.0.0.9 Release Notes.

(note: the last official release of Thunderbird was version 2.0.0.6; we skipped a few numbers in order to catch up with Firefox)

Mozilla IT: Mozilla Scheduled Downtime - 11/15/2007, 7pm - 10pm PST (0300 - 0600 11/16/2007 UTC)

2007-11-15T06:52:15+00:00

Mozilla Scheduled Downtime - 11/15/2007, 7pm - 10pm PST (0300 - 0600 11/16/2007 UTC)

We will have a scheduled downtime window tomorrow night from 7pm to 10pm PST. The following changes will take place:

* 7pm PST (0300 UTC) - addons.mozilla.org updates. We'll be updating code and testing the downtime notice of addons.mozilla.org. No downtime is expected.
* 7pm PST (0300 UTC) - bonsai and tinderbox server update. We'll be applying security updates to tinderbox and bonsai. 15 minutes of downtime is expected.
* 7pm PST (0300 UTC) - Kernel upgrades. Duration 4 hours. We'll be doing kernel security updates on various machines affecting the following services for approximately 10 minutes each:
- VPN and Jumphosts at all locations
- any sites requiring an LDAP login
- phone services at all locations
- people.mozilla.com
- litmus.mozilla.org
- All developer and QA machines that are running RHEL

Please let me know if you have any reason why we should not proceed with the 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 email infra at mozilla.com if you see issues past the planned downtime.

Thanks,
-Justin

John Slater: Operation Firefox: The Next Phase

John — 2007-11-15T05:06:12+00:00

As Andrew and Seth have already noted, Operation Firefox launched last month with a call for people to submit their plans to publicly display a Firefox Fathead sticker in the most interesting and eye-catching possible (legal) fashion.

We knew the success of this program would depend on whether or not people would rise to the challenge of coming up with great ideas and so far things are looking good: the initial phase of the contest ended last Friday, and we received a grand total of 3200 submissions. Very cool!

From a creative perspective, our goal was to create a website that would fire up people’s imaginations and inspire them to participate. This was a particularly fun project to brainstorm about, as we kicked around inspirational ideas ranging from James Bond to the A-Team. For the design, we turned to our friends at Nobox, and they made the astute call that site should resemble the secret hideout of an underground resistance movement rather than the slick style of a 007 HQ…hence the basement shadows and hand-sketched mission plans. It was also very important that every last bit of site text support this concept, so we worked with Elise Allen, who managed to incorporate influences from Fight Club to Flash Mobs into her copy.

The finalists have until December 3rd to execute their plans, and the winners will be announced shortly afterwards. All 50 Fatheads have been shipped to the finalists, so keep an eye out for giant Firefox logos popping up in strange locations over the next few weeks!

Calendar: Test Automation Summit Planning Meeting

2007-11-15T04:17:16+00:00

Well 0.7 has released, and we have been busy laying the ground work for the Test Automation Summit. We're ready to expose some of these preparations and plans and get to work on the documentation that we'll need in order to do the Summit.

In order to review the plans and to parcel out the work, we're going to discuss this at the next two QA Chat IRC meetings. These meetings occur at 17:30 UTC (click to find the time in your zone). The next one will be tomorrow, November 15. And the following one will be November 22.

Several great folks have stepped forward to help out, and we're looking forward to making this a success. If you are waiting for to get involved, then wait no longer! We will have lots of tasks from writing code samples, to writing documentation, to doing publicity.

I imagine that for most people out there, talking and learning about test automation doesn't sound like much fun. We're going to talk more about this when we start doing the big publicity for this event, but I'll let you in on a secret. We're going to be working on XPCShell tests, which are written in JavaScript. We're going to be teaching you what you need to know about JavaScript to be effective.

JavaScript is the heart of anything built on the Mozilla platform. That means that if you've always wanted to learn how to write a patch or an extension for Firefox, Thunderbird, Sunbird, Songbird, Seamonkey etc, then you will need to know JavaScript. This event (and learning by helping us prepare for the event) will help you get some hands on practice with the basics of JavaScript and start you on your way.

So, keep that in mind, we'll be talking about it more in the coming weeks. I hope to see you at the QA Chat in #calendar-qa.

Happy Testing!

John Resig: The World of ECMAScript

John Resig — 2007-11-14T23:53:02+00:00

So I did a little bit of digging and I've pulled together something fun: I call it "The World of ECMAScript".

(Released under the GPL v2 [SVG])

It's a full map detailing everything that exists within the world of ECMAScript (with JavaScript, ActionScript, and JScript being its most-famous implementations). Right now I'm only showing things that can be built on top of (languages, engines, browsers, servers, etc.) - not end user applications (there would probably be too many to list).

This chart started out as a simple diagram showing the relationship between ActionScript, Tamarin, ActionMonkey, and SpiderMonkey. From there I started tacking on additional relationships and it just sort of started to grow out of control. I'm fascinated by the size and breadth of everything in that exists in the ECMAScript ecosystem (and this isn't even everything, I'm sure I'm missing a ton).

Here's some links for more information:

Languages:

Engines:

Applications:

Hooks/Convertors:

Companies:

Implementation Languages:

Let me know if there's anything that you feel that I've missed. I'll use my discretion when adding, simply because I don't want this to include every half-baked ECMAScript implementation under the sun (and I still have to modify it by hand).

Update 3am Nov. 15: Removed WebKit (was redundant), added Silverlight, added IronPython and IronRuby, connected PDF to SpiderMonkey, and fixed spelling of Konqueror. Presto is wrong for Opera, but not sure what their JS Engine is named. Compressed PNGs, added an SVG download.

Update 5pm Nov. 15: Turned JavaScript into a language/cloud. Added ParenScript, YHC/JavaScript, Haxe, and Scheme2JS. Added CouchDB. Silverlight now links to JScript. Opera's two engines (futhark and linear_b) are listed. Added Flex. Changed QSA to QT Toolkit.

Robert O'Callahan: Pegs, Holes And Reflow

roc — 2007-11-14T22:55:52+00:00

I already blogged about Gecko's frame continuations being a mistake. It's time to rant about another big layout design error: the uniformity of the Reflow() API.

During layout, frames (i.e. CSS boxes) call Reflow to lay out their children and then position those children in some manner. The core problem is that Reflow's signature is the same for every frame type. That means that in theory, table frames have to interact with their row(group) frames in exactly the same way that inline frames have to interact with their inline children, or XUL boxes have to interact with their box children, etc. But this is nonsense, since the invariants, dependencies and data that need to cross the parent/child boundary are entirely different in each of these cases.

So in practice we have various kinds of magic probing and/or magic fields of structures that are only used in certain cases. This inevitably leads to breakage and overcomplex code. Problems are particularly acute in line layout, where we really would like to work with a flattened list of inline leaf items, but thanks to Reflow we can't. The textrun work has moved us to a situation where we construct a flattened representation of at least the text of a paragraph for line breaking and text shaping, and then we pull data from that in a hokey way as we Reflow text frames. It's somewhat painful as the two traversal models fight each other in nsLineLayout. Of course the aforementioned frame continuations crash the party too.

What we really should do is admit that parent-child frame type pairs are actually tightly constrained, i.e. an inline frame can only have an inline parent or a block parent, a table row frame can only have a table rowgroup parent which can only have a table parent, etc. (These invariants already exist actually, although the code sometimes doesn't want to admit it.) Then we should toss Reflow over the side and give each frame type its own specialized layout interface. Only a few frame types (e.g. blocks and tables) would be able to occur in "unknown" contexts and offer a generic layout interface.

In fact, we could go further and specialize further the types of child frames or even get rid of a uniform nsIFrame tree altogether. There's no particular reason why it makes sense to have tables, table rowgroups, table rows and table cells all be the same kind of object as text frames or SVG frames. Sure, we want to be able to iterate over CSS box tree geometry and style somehow, but there's a whole lot of generality exposed in nsIFrame that doesn't really make sense everywhere.

As an aside, the conflict between textrun layout and inline layout is an example of a general problem I've seen with cleaning up code. You rework module A to make it nice and clean, but because modules B and C are quirky, you have to add complexity to module A to keep things working and shippable. Eventually you rework B and C too but A's already been contaminated, so B and C inherit some of the sins of their fathers. You can reduce the effect by enlarging the scope of rework, but that adds risk and schedule issues of course --- in the limit you rewrite everything and sink your entire project.

Henrik Skupin: No shortcut to open contextual menus on OS X?

Henrik Skupin — 2007-11-14T22:13:05+00:00

I’m really surprised! After years of experience with different Windows and Linux versions it’s getting normal for me to open contextual menus with Shift+F10 or the special context key if a mouse is not available. But yesterday while doing some work on bug 403602 I noticed that there is nothing for OS X? What about handicapped people who aren’t able to use a mouse or even use a screen reader? How do they access the context menu?

I asked several people who are still working on OS X for a longer period of time. But no one was able to give me a hint. So I started searching the web. I got this nice shortcut overview but no system wide shortcut is given. Now, while writing this post, I found this HIG document from Apple. It’s quiet interesting but once again a keyboard shortcut isn’t mentioned.

I’ll stop searching right now and hope that someone, who reads my post, could help me. I would be deeply grateful. Thanks!

Johnathan Nightingale: Self-documenting

Johnath — 2007-11-14T21:44:49+00:00

I know I’m weird, but I’ve always really liked the way roads combine with badly maintained trucks to create emergent topographical self-documentation. Pictures are easier:

Notice the dark spots? That particular stretch of road always drives the point home for me - every time the trucks in front of me hit a bump or dip in the road, it shakes some grease loose from their chassis, and darkens the road a little bit. Like ants finding efficient routings, it’s always just sort of made me happy.

[Note: The embedded google map got very very broken in RSS, so I’ve replaced it with a static graphic. Still I suspect the RSS damage is done.]

Stuart Parmenter: pavlov

pavlov — 2007-11-14T19:37:04+00:00

I’ve seen quite a few posts lately based on the memory fragmentation work that I’m doing with titles such as “Fixing Firefox’s memory issue becomes a priority.” Others have claimed that this work is a result of Mozilla’s new focus on mobile. While I’m glad that people are paying attention to our memory work and offering great suggestions, let me say: Memory issues have always been a priority.

Since I started working on the project in 1998 we’ve always had a focus on keeping our memory footprint small and keeping leaks to a minimum. Early in the development cycle for each release we’ve set goals for memory and performance. We always set our bar under the previous release. I’ve found that developing desktop software is a pretty constant balancing act between performance and memory use. We’re always making trade-offs and we try our best to chose the things that will work best for the largest set of users:

Some examples:

Back in 2001 when I rebuilt our imaging library, I made several decisions to use more memory to store images results in faster rendering; optimizing for memory use reduces the speed at which was can display pages. We’ve looked at these issues many times over the years to make sure they were still correct. Recently we’ve adjusted that behavior to not keep full uncompressed images around as long which will result in memory savings but will cause initial scrolling to be a bit slower on documents you haven’t accessed in a while.
In Firefox 1.5 we added a feature called the back/foward cache which keeps documents in your recent history that you’ve navigated from in memory. This was done to significantly speed up hitting the back button. It worked great but caused us to use a bit more memory. We made sure that it was only using memory your computer wasn’t already using, but again, it’s an example of a trade-off. We started off with a pretty high number of pages that we kept in the cache and have continued to adjust that number to keep a more limited set of pages to help prevent unnecessary bloating. We’ve also started expiring these pages over time so that you don’t keep pages around you probably aren’t going to use.

With the popularity of extensions rising, we started hearing complaints about memory leaks. We took these reports pretty seriously and have spent a lot of time investigating what is going on. A lot of work has gone in over the last few years to reduce these leaks. Most of our early testing was around the browser, without extensions. Our investigations showed that certain extensions in caused a pretty bizarre class of leaks that were pretty difficult to fix given the architecture in Firefox 2. We fixed as many of them as we could in Firefox 2 but some we were unable to fix. In Firefox 3 some Really Smart People (graydon, peterv, dbaron, etc) have built this thing called the cycle collector in to the core which addresses many of the leaks that we were seeing from extensions (as well as leaks from other places that were of the same class). Our extensive testing shows an occasional leak here and there and we are working to fix those, but in general we aren’t seeing many leaks anymore.

It is only after we’ve gone through so many leak fixes and done so many other memory reduction fixes that we’ve needed to a deeper look at what is going on under the hood. We’ve long had suspicions that we were being hurt by memory fragmentation, but it wasn’t until recently that we had built good tools to fully diagnose the problem.

I’ll assert here that the way people use their browsers has changed. When Gecko was originally designed back around 1998 people had one, maybe two browser windows open without tabs, and they certainly didn’t have any extensions installed. I look at my browser windows now and I’ve got 3 browser windows open with a total of about 20 tabs open. That is 10x the number of documents open at once!

With the change in how people use their browsers, there is no doubt that they’re going to use more memory. We’re doing everything we can to minimize the impact of having lots of documents open. Many people are trying to shave off bytes here and there. Just in the last week we’ve removed over 200 thousand allocations just from startup and first page load. We’ve got a great community and people eager to solve these problems. We’re now equipped with data and ready to fight this battle.

Stay tuned…

Calendar: Lightning/Sunbird Status Update (November 14)

2007-11-14T16:44:12+00:00

It's been nearly four weeks since the last status update and nearly three weeks since 0.7 was released, but do not think that we've been idle in that time. We're already going full steam towards the 0.8 release and have already fixed 65 bugs since the last status update.

Three fixes deserve your special attention:

Bug 288496: Alarm indicator icon on event box
Bug 372829: Integrate unifinder into Lightning as it is in Sunbird
Bug 400279: Category colors should be displayed next to the event boxes

With those fixes we gain the ability to easily select lots of events based on different criteria (bug 372829), a feature present in Sunbird but not in Lightning until now. Category colors assigned to an event can now be much easier identified (bug 400279) and it is now much easier to identify events, which have an alarm set (bug 288496).

Here's the complete list with all the 65 bug fixes:

Bug 288496:
Alarm indicator icon on event box
Bug 324440:
Convert calendar code to frozen linkage
Bug 328442:
jsDate vs calIDateTime
Bug 341518:
Minimonth previous and next arrow buttons move when clicked
Bug 341537:
Leaking factories/modules for some components
Bug 349870:
Support building Thunderbird with preinstalled Lightning
Bug 354574:
Centralize definition and getters for PRODID and VERSION
Bug 356569:
Revising calendar prefs handling
Bug 363038:
Recurrence preview should start at the start date of an event
Bug 367456:
Memory usage increases after Reload Remote Calendars (memory leak)
Bug 370146:
API enhancement: Searching for calendars
Bug 372829:
Integrate unifinder into Lightning as it is in Sunbird
Bug 373370:
Send If-Match / If-None-Match headers on PUT & DELETE
Bug 378172:
Recurrence dialog: datepickers need a facelift
Bug 379174:
readonly events should not be dragable in the views
Bug 379204:
Add Open/Save As ICS in Thunderbird File Menu
Bug 383272:
Recurrence dialog: weekly and monthly recurrencepattern is not in sync with minimonths
Bug 385155:
Reminder /alarm dialog doesn't show times in configured timezone
Bug 390508:
Unify calendar command sets
Bug 391300:
Switching to mail mode does not restore collapsed elements properly
Bug 392853:
Unit test: calIDateTime's subtractDate doesn't honor timezones
Bug 395940:
Event Dialog: Save Changes? dialog should use descriptive button labels
Bug 395925:
Revise entity reminder.due.label
Bug 396159:
Unused entity lightning.context.deleteitem.accesskey
Bug 396337:
Some tooltips should be improved
Bug 396547:
Remove obsolete entities lightning.sidebar.showCompletedTasks.*
Bug 397538:
Mac: Right-click on event in calendar brings up non-functioning pop-up menu
Bug 397727:
Incorrect DateTime format for (Google) Calendar request
Bug 397866:
Errors are getting announced indefinitely
Bug 397912:
Switch 'app.update.url' preference to new community server
Bug 397917:
Entire today pane shifts when pressing a miniday button
Bug 398139:
X-prop parameters get corrupted
Bug 398247:
TodayPane: toolbar button icons in miniday are left aligned
Bug 398309:
Installer needs to remove obsolete files
Bug 398724:
Problems with floating all-day items
Bug 399764:
Attendees dialog: error during setting zoom level and strict warning
Bug 399864:
calAttendee lacks mutability checks
Bug 399893:
Lightning 0.7 RC 1 on Mac: Address book icon exchanged
Bug 400148:
Event dialog should compare calendars by id
Bug 400168:
Remove Mongolian as supported language
Bug 400279:
Category colors should be displayed next to the event boxes
Bug 400370:
Weektitle of miniday is not always correctly calculated
Bug 400407:
Conflicting entries in removed-files.in break update process
Bug 400808:
Change default preference to false for sendEventNotifications
Bug 400871:
General listener is called even when not defined (gdata)
Bug 400951:
Attribute calICalendar::suppressAlarms should be removed, be modeled as a calendar pref/property
Bug 401362:
Recurrence dialog: uncaught exception if creating new event
Bug 401389:
Task dialog shows dots beside start and due date checkboxes when given focus
Bug 401428:
Google calendars do not show up in any view (missing toString)
Bug 401521:
Day, Week and Multiweek View changes to Month View after restart
Bug 401572:
Selective calling of onRemoveAlarmsByItem / Error Console startDate has no Properties
Bug 401668:
calendar-unifinder.css changes text color in Thunderbird
Bug 401678:
Gdata preferences file is not correctly added
Bug 401681:
Sync calendar-event-dialog.css between trunk and branch
Bug 401710:
Unable to dismiss zero duration events
Bug 401739:
Thunderbird always starts in calendar mode
Bug 401861:
Send freebusy results immediately
Bug 401878:
Events of deselected calendars stays visible
Bug 401905:
Event grippies are no longer functional
Bug 402038:
Drop Lightning support for Thunderbird 1.5
Bug 402197:
WCAP calendar, all day recurrence -> deleting a single event isn't possible
Bug 402516:
Remove calIOperation::success
Bug 403221:
Fix typo: explaination -> explanation
Bug 403517:
New Event/Task (context) menu commands are always disabled
Bug 403676:
Remove lock from calendar list column header

Stay with us! More good stuff is yet to come. Thanks again to all our developers, contributors, localizers, testers, and supporters. Keep up the good work!

Robert Kaiser: Progress and help-wanted on SeaMonkey 2

KaiRo — 2007-11-14T16:21:44+00:00

I just received a link to a screen shot of SeaMonkey 2 with customized toolbars (this is work in progress, not in nightlies yet, see bug 394288), so I decided to give you a (probably incomplete) overview of current in-work items for SeaMonkey 2 (in no particular order) - and some we'd need help on.

As mentioned above, the work on customizable toolbars is done by Philip Chee, and his work is nearing a state that could possibly be included in our development codebase. At first, this will only be available for the browser component, work on other parts will possibly follow later.
Teune van Steeg is working on notification bars for the browser, which are basically already included in current nightlies, just not used by anything yet. Teune is currently working on making use of this feature, e.g. for installing extensions from blocked sites, missing plugins or popup blocking.
Another quite active area currently is feed support. Justin Wood is leading that effort, our module owner Neil Rashbrook is helping with some parts there. The first target is to get browser support, mainly for discovery and preview of feeds as well as hooks to subscribe to them. At a later stage, we might even get livemarks support, but probably after getting a feed reader in the mail/news component, which will probably be Justin's next target after initial browser support.
The preferences migration, targeting to base the SeaMonkey preferences window on the toolkit-style <preferences> family of XUL elements though keeping the familiar look and feel of the suite preferences window, is led by Karsten Düsterloh. The initial work of providing the new window is done already, until migrating all panels is done, we have two menuitems in the browser component, one leading to the new window with the already-migrated panels, one to the legacy window with the not yet migrated ones. That area of migrating pref panes should be a relatively easy one for newcomers to help out.
Vista users might have noticed that SeaMonkey 1.1.x integration with the new Microsoft OS is not ideal, Frank Wein is working on this among other things when replacing the old "winhooks" code with a new shell service implementation, fitting the style of other toolkit applications. This will also fix an area where localized nightly build show problems.
Mark Banner is currently working on our migration from wallet to LoginManager for password management, the toughest part of which is that the mail/news code needs to use the new password manager, which is in turn blocked by core LoginManager code not supporting all we need yet. Once Mark has fixed that core code, we should be able to throw another old unmaintained code module away and replace it with cleaner, new code. That will also fix another current case of problems with CVS-based localization.

Some areas still would badly need help though:

Using the sqlite-based places backend provided by the Mozilla toolkit would probably be a good idea, at least for browser history. After we now can use XUL templates with mozStorage templates, it should not be too hard to get our history UI hooked up with that.
If that works well, it might even be an interesting idea to use the places bookmarks backend, though without changing the UI we use in the suite for that feature (the backend change would make up the way for extension to try other UI there).
The download manager should pick up at least the new backend provided by the Mozilla toolkit, which supports goodies like cross-session resuming of downloads. This also will/should fix the probably biggest remaining problem with CVS.based localized builds - and note that there is a KaiRo.at bug bounty to fetch for this work.
Calendar support is something many people would like from an Internet suite like ours, so making the Lightning extension work on SeaMonkey is another thing we'd really like someone to help out with - and where someone could earn a KaiRo.at bug bounty.
I think there's no bug filed on it yet, but getting Firefox' session restore ported to SeaMonkey would also be a great feature, esp. as restarting from the extension manager wouldn't make you lose all open web pages.
Last not least, I once again need to mention the dynamic UA spoof mechanism, which has the largest KaiRo.at bug bounty of all waiting for whoever does the work, and which could help lots of users, multiple browser projects as well as make the web itself a better place.

I may left out some notable areas of current work or some areas we need help, if you feel I have omitted something worth mentioning, please comment on this blog entry!

All in all, I think there's a bunch of interesting stuff happening at the moment, but still some important things to be done before SeaMonkey 2 gets where we want it to be. Thanks for everyone already actively working on the future of the suite (those are all volunteers doing this in their free time!) - and to everyone who wants us to get even better and has some time and work to offer: please help us, either with the items mentioned above or in other ways of getting involved. There's something to do for everyone and we appreciate any help we can get!

John Lilly: Tokyo

John — 2007-11-14T09:13:28+00:00

Just got to my hotel in Tokyo, going to take a shower then go to a meetup here with, hey — other people who live near me in Silicon Valley!

Really here to see Chibi and Kaori and Gen and Kohei and Joi and Nobu and other folks from Mozilla Japan as we think about what to do here in 2008. It’s been fun and productive to work with the team here as they’ve grown from just a couple of folks 2 years ago to a real office now. Japan is a tough culture/market to really crack for open source, but Chibi (Takita-san, head of Mozilla Japan) has worked hard on raising awareness of OSS here for years, and is making real headway. I’m excited to talk with her, the board, and the rest of Mozilla Japan tomorrow.

But tonight, Web2 types.

2 random tidbits: (1) in Japan, my iPhone seems to be an iPod — no connectivity at all, and (2) I haven’t been here in a year or so, and am reminded what a great place Tokyo is. I’ve been to lots of great places in the past couple of years — Tokyo really is one of the world’s great cities, alongside London and Manhattan, in my view.

Songbird: A Songbird Orange

2007-11-14T05:53:36+00:00

"Yarbles, great bolshy yarblockos to you!"

Droogs and malchicks, come celebrate the launch of Songbird 0.3 with us! We're co-hosting a ~~real horrorshow~~ party with the hooligans at Get Satisfaction!

Kubrick & Cupcakes: A Satisfaction Appreciation/Songbird 0.3 Party

Thursday Nov. 15 7pm-1am
Terra SF 511 Harrison St. 2nd floor San Francisco, CA 94105. Map
RSVP: Facebook and Upcoming.org

DJ Aus
DJ Deckard
DJ Jive
MC Fossil Fool, SF bike rapper for real

All-white dress, false eyelashes, and fancy bowler hats strongly encouraged.

Paul Kim: Firefox Start Page Update

Paul Kim — 2007-11-14T01:43:23+00:00

This week, we’ll be making a minor update to the Firefox Start Page for the English locale. Here’s what’s changing:

Search navigation links will be updated to match the links on google.com. The categories over the search field in the current Firefox Start Page (Web, Images, Groups, News and Maps) will be updated to match the categories on google.com and moved to the upper left part of the page.
Links to account controls will now appear on the upper right side of the page if you’re already signed into the Google network. For example, if you’ve signed into Gmail and stayed logged in, you’ll see your Google network username and options to access your account or sign out in the upper right part of the Start Page.

We’re working with Google (who is our search partner for the Start Page) to make these minor changes to sync up with updates to the google.com search experience. You currently see the updated search navigation links in the header of the results page after you initiate a search on the Firefox Start Page. We’ll start with English and roll updates out worldwide over the coming weeks.

Alex Faaborg: Update on the Firefox 3 Linux Theme

Alex Faaborg — 2007-11-14T01:01:07+00:00

Work on the new linux theme for Firefox 3 is progressing nicely due to a very active group of contributers. To match the operating system’s theme, Firefox’s navigation toolbar will use native GTK icons. The remaining icons are being drawn in the Tango style. I owe a huge thanks to Andreas Nilsson, Michael Ventnor, Kalle Persson, Lapo Calamandrei, Garrett LeSage, Michael Monreal, jimmac, and everyone else who is contributing to help ensure that Firefox 3 looks great on linux.

[Update: there is some very thorough coverage over on Ars Technica with lots of screenshots]

Stuart Parmenter: pavlov

pavlov — 2007-11-14T00:04:13+00:00

Lots of people have asked where most of the allocations in Mozilla come from. I’ve gzipped some dtrace output that shows number of calls per size of stacks 5 deep. Note: This log only shows allocations <= 2048 bytes. This data is pretty raw but if people want to take a look at it and see if they have ideas for how to improve some of the code paths in question, that would be great.

An example:

  libSystem.B.dylib`malloc+0x37
  XUL`nsStringBuffer::Alloc(unsigned long)+0x15
  XUL`nsACString_internal::MutatePrep(unsigned int, char**,
                                      unsigned int*)+0xce
  XUL`nsACString_internal::ReplacePrep(unsigned int,
                                       unsigned int,
                                       unsigned int)+0x46
  XUL`nsACString_internal::Assign(char const*, unsigned int)+0xc8

       value  ------------- Distribution ------------- count
           4 |                                         0
           8 |@@@@@@@@@@@@@                            9724
          16 |@@@@@@@@@@@@@@@@                         11940
          32 |@@@@@@                                   4359
          64 |@                                        887
         128 |@@                                       1604
         256 |@                                        497
         512 |@                                        676
        1024 |                                         47
        2048 |                                         0

This shows that there are 9724 8 byte allocations, 11940 16 byte ones and so on.

Things to look for include:

Things with lots of allocations
Things that could be stack allocated to avoid memory churn
Things that the lifetime is well understood that we could put in to pools
etc…

Edit: I’ve also posted another log with 8 frame deep stacks as well as a log that only includes allocations post-startup (also 8 frames deep).

Blog of Metrics: Mozilla Comes to the Defense of Radiohead

kkovash — 2007-11-14T00:00:14+00:00

Polvi and I have been following the release of Radiohead’s new album, In Rainbows, for a couple reasons. First, it’s a fresh and great approach to open source marketing – open pricing! Second, their process has some flavors of our funnelcake project. For In Rainbows, they’re considering the path of fans as: visit -> download -> pay $0 or any amount -> listen.

The link above references a comScore study attempting to roughly measure the success of In Rainbows (via the number of downloads). The entrance of their funnel relies on an estimate of 1.2 million visitors to Radiohead’s web site, InRainbows.com, during the month of October. From the study’s numbers, one can then see what percent of visitors paid for their download and what average price those fans paid.

Radiohead has come out contesting comScore’s analysis. Radiohead and comScore can have their own disagreement over the middle of the funnel, i.e., download percentages and prices paid. Where Mozilla can perhaps shed some light on the situation is the entrance of the funnel, i.e., how many fans visited Radiohead’s site in October? All other analysis is completely dependent on this piece of the puzzle, so it’s critical that any discussion be certain that the answer to this question be 100% accurate.

So, how can Mozilla help?

For the month of September 2007, Mozilla saw 42.7 million unique visitors (this includes just our www.mozilla.com domain, which hosts about 50% of all Mozilla traffic).

What about comScore and Compete.com? How close did they come to estimating our traffic for September 2007?

comScore’s study says 16.7 million unique visitors
Compete shows our “people count” as 3.4 million

Perhaps Radiohead has a legitimate concern…

Stuart Parmenter: pavlov

pavlov — 2007-11-13T23:55:29+00:00

As promised, some Minefield beta 1 Windows builds with the low fragmentation heap turned on.

Installer
Zip

These are built off of the beta1 branch. Beta 1 isn’t out so this isn’t final use at your own risk blah blah blah.

I am curious to hear how these compare memory use wise to other builds for people.

I’m working on putting together an extension (maybe updating RAMBack) to let you produce pretty heap images but I’m not there yet. Stay tuned for that.

Songbird: Today's Media Web Meet-up...

2007-11-13T23:40:06+00:00

Thanks so much to you, the 50+ media service developers, Media Web innovators and entrepreneurs, birdbuilders and birdwatchers who came to the first Media Web Meet-up. I'll post video from the meet-up just as soon as we polish in post-production.

Special thanks to Mike Linksvayer of Creative Commons for first an overview of CC's lawyer- and machine-readable Some Rights Reserved licenses, services and software followed by a compelling State of the Union update of music on the Web. I'll link to his slides as soon as they're posted.

Mike also mentioned that Creative Commons is fundraising and offering a limited edition, smirk-worthy tshirt:

Also my thanks to Tara and crew from Citizen Agency for driving this and future Media Web Meet-ups. Thanks to our operations crew Sharon and Marion for producing another flawless event!

As mentioned, a supporting OpenMediaWeb.org web site is forthcoming. I'll blog its launch.

chirps,
Rob

Chris Blizzard: day number one

blizzard — 2007-11-13T23:03:23+00:00

Today was my first full day of employment at the Mozilla Corporation. I’m of two minds right now: first, it’s exhilarating to be starting a new job. You never know exactly what it’s going to be like, even though you have mapped out a set of goals and ideas of what you’re role is going to be before you start. On the other hand, this feels eerily familiar just because I know all these people and I’ve been so closely tied to the organization since nearly its inception. It’s just strange to have things on my plate that directly affect the organization instead of working so indirectly from outside for so long. I’ll be able to feel the changes I drive in a very tangible and immediate fashion. I’m pretty excited about that.

One of the side effects of taking this role is that I’ve resigned my position on the Mozilla Corporation Board. I’ll really miss the chance to work so closely with Reid, John and Mitchell in that format. I will still get to work with John and Mitchell every day, of course, but it’s not in the same form. Of course, being able to affect things in a much more direct manner makes up for it, but I am still a little sad about it.

Onward to day number two!

Mitchell Baker: Focus on the general consumer: "what would my neighbor think?"

mitchell — 2007-11-13T19:30:16+00:00

Here's another element of building a consumer product that colors daily life for much of the Mozilla project.

Firefox is intended to be useful to both power users and to people who are not technical experts, who want to use the Internet without having to understand all the pieces that make it work. The power users are more demanding in some ways, but also easier to address in many ways. After all, the developers of Firefox are power users themselves. Mozilla bagan a much more serious focus on the general consumer when we shifted primary development from our initial product (the "Mozilla Application Suite") to Firefox and Thunderbird.

This change of focus seems obvious but it is in fact quite hard. One has to really care -- at a deep level -- for people with far less technical mastery. Or for someone who cares only enough to get things done and not because he or she finds Internet architecture remotely interesting. For example, there are many, many people who do not distinguish between the the url bar, the search box, the buttons at the top of the browser, the start page (web content) served jointly by Google or Yahoo and Mozilla, and the software provided by Mozilla. They often describe that combination as "my internet" or "firefox search" or "google".

These are not "dumb users." I hear these comments here in the heart of Silicon Valley regularly. Here in the Valley one can usually clarify a bit, because the Internet is after all the engine of local economic life. But elsewhere many people really don't care. They want to know only what they need to know to get other things done. As an analogy, I think of the international postal system. It's highly complex, with inter-governmental agreements, local arrangements, and a raft of supporting infrastructure. Most of us don't know or care much about the details; we care about what postage costs and how long it takes a letter to get there.

Designing a product for people for whom new features may be frightening or unintelligible is very different from designing for the power user. It's limiting in some ways, and yet can force a useful focus on what's really important. It's not for everyone.

We think about this all the time. We strive to build products that are effective for the general consumer. We consciously make decisions that something that is awesome to us may not be right for the general product. Even more tricky, we aim to build a product for the general consumer that is powerful and elegant, that allows people to experience the richness of the Internet, and that grows with people all the way to power users.

As in many things, Mozilla is a hybrid. We are a pioneer in this aspect of open source and we are trying new things constantly. We hope others become experts in this -- one of our explicit goals is to share what we learn so that our experiences end up benefiting people far beyond the products we produce. We couldn't do our work without the efforts of those who came before us; we hope that others will find the same to be true of our work.

Eric Shepherd: Places

sheppy — 2007-11-13T19:23:45+00:00

Aeraj has been working hard on Places reference documentation. While it’s still a work in progress, it’s coming along very nicely, and I’m quite pleased with his work so far. Please feel free to give it a look and do edits if you see anything that’s busted.

Places is one of those technologies that sounds like something that won’t make any difference in your life at all — until you actually start using it and realize that it really is better than the way things used to be. I’m really enjoying the changes to how bookmarks (and the super-cool URL bar) work.

John Lilly: congratulations Miro!!

John — 2007-11-13T17:53:02+00:00

One of my very favorite software projects, Miro, launches their 1.0 today! I’ve written about this before, when Miro was called the Democracy Player. Today represents the culmination of two years of hard work by the Miro team, and a serious start at reinventing video. As Josh Quittner at Fortune points out, this makes even more sense in the context of the WGA strike — entertainment is changing quickly, for sure.

[2 disclaimers: (1) Miro uses Mozilla technology for their Windows & Linux versions, and (2) I’m on the Board of Directors of the non-profit Participatory Culture Foundation, who makes Miro.]

Doug Turner: Minimo and Mobile.

dougt — 2007-11-13T16:33:40+00:00

Over the past few years the Minimo project has provided (1) a set of build and runtime options optimized for resource constrained devices, and (2) A XUL-based UI for prototyping and experimenting with new user interfaces for navigating and viewing web content and general browsing on mobile devices.

Recently you have probably read that the Mozilla Corporation is building the embeddable version of Mozilla and a mobile Firefox. In the new and expanded mobile effort the project will create a standards-based open-source browser engine and full open source development stack based on Mozilla technology, optimized for mobile devices, and embeddable on a variety of device targets. This new work will replace the Minimo project.

If you are a developer using Minimo as the basis for your embedding needs, this new effort will help you. This is picking up where Minimo’s build configure left off, and further squeezing and optimizing Mozilla.

Although we haven’t committed to specific platforms, all of the effort that was focused on the Minimo front end will be refocused on this new project. This new browser product will take advantage of lessons learned in minimo UI prototyping and experimentation. It will also include support for XUL-based add-ons, and deliver on Firefox's key principles of ease-of-use and accessibility.

We hope you can join the conversation. Most of the developers and interested people hang out on irc.mozilla.org #mobile. If you have questions, or need clarification, please drop by.

Doug Warner: Mozdev sysadmin meeting minutes for 2007-11-13

silfreed — 2007-11-13T16:31:20+00:00

Present: David Boswell, (davidwboswell), Doug Warner (silfreed), Michael Dosser (tanker), Gerry Murphy (gjm), Chris Neale (cdn-work), Brian King (kinger)

Discussion was held publically in #mozdev

Discussed developer priorities

download counters enabled; projects can use downloads() function again
D.MD.o now shows size of download files
mycroft doesn't use mirror system; we might want to try to help them get moved over
several projects have requested and started using drupal
integrating blog into main site will be happening soon
Chris reminded me that Thanksgiving is next week so I'll probably work on that theme soon

Discussed sysadmin priorities

httpd.conf cleanup - cleaning up aliases, using virtualhosts, cleaning up rewrite rules, combining HTTP and HTTPS servers
apache cleanup will need tested by project owners, but that will probably bring up the old content on stage again
syncing production and stage is probably possible if we exclude logs
stage and production will be synced tomorrow, so Doug will get his stuff backed up today
mailman has been configured to perform actions through HTTPS
Gerry is still researching mailman slowness problems
bugzilla 3.0 is ready to deploy; we'll wait until after the sync so that POs can test w/ recent content

Allan Beaufour: Joost Developer Days

2007-11-13T14:16:22+00:00

Joost has grown up, and we are thus opening up to the world :) So the first “Joost Developer Days” are coming up:

London (Covent Garden) – 1pm – 6pm – Friday 16th November
Amsterdam (Central location) – 1pm - 6pm - Saturday 1st December
New York (Broad Street) - 12pm – 5pm - Friday 7th December

It’s a chance to learn how we do widgets in Joost, and how you can do them yourself. More information on our Joost Development Group.

Mike Shaver: leaking, growing, and measuring

shaver — 2007-11-13T05:56:57+00:00

(This post started small, but got bigger as I noticed more things that aren’t necessarily as obvious to my readers as they are to me, with respect to our process and software. So it grew over time, oh ha ha! It’s almost 1AM, so I will not be editing it further this evening! I might post a summarized version at some point in the future, or I might not.

And then I edited it because Dave pointed out that it sounded like I was saying that other browsers necessarily suffered similar fragmentation woes, which wasn’t my intent. Indeed, the main point of the post is that there can be many possible causes for a given symptom, and that the popular theories (e.g. “massive memory leaks”) may not prove correct.)

I’m going to share some non-news with you: Firefox has memory leaks. I would be shocked to discover that there were any major browser that did not have memory leaks, in fact. Developers in complex systems, be they browsers or video games or operating systems, fight constantly against bad memory behaviours that can cause leaks, excess usage, or in the worst cases even security problems.

(As an aside, it’s still quite, quite common to read articles which reference this long-in-the-tooth post from Ben as the “Mozilla development team” denying that there are leaks in Firefox. You would have a hard time getting any developer to say that there are no leaks in Firefox, and indeed the post in question says second sentence that Firefox has leaks. You do not need a secret nerd decoder ring here to interpret the text, just basic literacy. Also, it’s no secret that Ben hasn’t been active in Firefox development for quite some time, so for people to point at an article that’s thinking hard about what it would like for its second birthday, rather than actually contacting any of the rather visible and accommodating developers of today — well, it just feels kinda sloppy to me.)

So, Firefox has leaks, and Firefox uses a lot of memory in some cases. A student of logical fallacy will no doubt have no difficulty setting development priorities: to reduce the amount of memory used by Firefox, fix all the leaks. In this case, though, a student of Mencken can happily triumph over the student of fallacy, for even with multifarious leak fixes we would still see cases where Firefox’s “used memory” was quite a bit higher than leaks could account for.

Let me now take you on a journey of discovery. Measuring leaks — contra identifying their root causes or fixing them — is actually quite simple: you count the total amount of memory that you ask the operating system for (usually via an API called malloc), you subtract the amount of memory that you tell the operating system you’re done with (usually via free), and if the number isn’t zero when your program exits, you have a leak. We have a ton of tools for reporting on such leaks, and we monitor them very closely. So when we see that memory usage can go up by 100MB, but there are only a few kilobytes leaked, we get to scratching our heads.

Schrep, our intrepid VP of Engineering and sommelier, was doing just this sort of head-scratching recently, after he measured some surprising memory behaviour:

Start browser.
Measure memory usage (”Point 1″).
Load a URL that in turn opens many windows. Wait for them to finish loading.
Measure memory usage (”Point 2″).
Close them all down, and go back to the blank start page.
Measure memory usage again (”Point 3″).
Force the caches to clear, to eliminate them from the experiment.
Measure memory usage again (”Point 4″).

You might expect that the measurements at points 1 and 4 would be the same, or at least quite close (accounting for buffers that are lazily allocated on first use, for example). You might, then, share the surprise in what Schrep found:

Point 1	Point 2	Point 3	Point 4
35MB	118MB	94MB	88MB

(You can and should, if you care about such things, read the whole thread for more details about how things were measured, and Schrep’s configuration. It also shows the measured sizes for a number of browsers after this test as well as at startup with some representative applications loaded. You may find the results surprising! Go ahead, I’ll wait here!)

So what does cause memory usage to rise that way, if we’re not leaking supertankers worth of memory? Some more investigation ruled out significant contribution from the various caches that Firefox maintains for performance, and discovered that heap fragmentation is likely to be very significant contributor to the “long-term growth” effects that people observe and complain about. Heap fragmentation is a desperately nerdy thing, and you can read Stuart’s detailed post if you want to see pretty pictures, but if you’ve ever opened a carefully packed piece of equipment and then tried to put it all back in the box, you’ve experienced something somewhat similar; if you take things out and put them back in different orders, it’s hard to get every thing to fit together as nicely, and some space gets wasted.

The original design for Gecko placed an extremely high premium on memory efficiency. The layout code is littered with places where people did extra work in order to save a few kilobytes here or there, or to shave a few bytes off a structure. If you compute the classic malloc/free running total I mentioned above, I think you’ll find that Gecko typically uses a lot less memory than competitors. But, as I hope I’ve made at least somewhat clear here, there’s more to managing the memory impact of an application than simply balancing the checkbook and keeping your structures lean. When and how you allocate memory can be as-or-more important in determining the application’s “total memory footprint” than the things that are simple to theorize about. And making sure that you’re measuring the same things that users are seeing is key to focusing work on things that will be the maximum benefit to them, in the shortest time. We’re working now on ways to reduce the effects of heap fragmentation, just as we’ve invested in fixing leaks and improving our tools for understanding memory consumption and effects, and the outlook is quite promising.

The real punch line of this for Firefox users is that Firefox 3 will continue to improve memory behaviour over long-term usage, and you’ll soon be able to try it out for yourself with the upcoming Firefox 3 beta. Beta 1 won’t have the benefits of the work on fragmentation reduction, but many testers are already reporting dramatically improved memory consumption as well as significant performance gains. We’re never satisfied with the performance of Firefox, just as we always seek to make it more secure, more pleasant to use, and nicer to smell.

Robert Accettura: Android SDK Released

Robert — 2007-11-13T03:58:22+00:00

We knew it was coming, and it’s now here. I haven’t looked at it too closely, but a few things I’ve noticed:

Yet another XML UI? Clearly it’s becoming a popular way to do things, but do we need so many? XUL, MXML, XAML, now Android? Surely there must be another way. XUL as a standard sadly never materialized.

There’s a mention of 3D libraries, but notes:

…the libraries use either hardware 3D acceleration (where available) or the included, highly optimized 3D software rasterizer…

We all know how well graphics drivers have historically been on Linux. Hopefully the embedded/mobile market will prove better than the desktop.

One thing I do wonder is all the variables. The platform seems to have a fair amount of potential, but there’s no real standard regarding what you can be assured will exist on a handheld (for example 3D acceleration) or even what restrictions might be imposed by the carrier (firmware lockdown). At least with the iPhone you know they all ship with certain CPU’s, graphic capabilities, etc. It’s a very predictable platform. Android reminds me a lot of programming for the PC, there’s a ton of variations out there on the web to account for. Even if most run the same OS. Mobile has the added complexity of carriers who are notoriously restrictive. I wonder if this will really change. This is why the web as a platform is so great. It overcomes most of these limitations.

In general I have to agree with most of what Robert Scoble says (vaporware, unimpressive UI, etc.) but it’s still very early on, and you can’t judge much based on this early preview. Right now, the iPhone is a clear winner, but I wouldn’t discount Android just yet.

My general feeling is that it’s too early to make much of a judgment. There many things that can happen in the next several months that can drastically alter the fate of Android for better or worse both business and tech wise.

The next key moment in the mobile landscape will be the release of the iPhone SDK due early next year.

Then there’s always the underdog OpenMoko.

Chris Cooper: Community a go-go

Coop — 2007-11-13T03:35:24+00:00

I’m not even supposed to be here today, but I just had to write a little something about the Firefox 3 Beta 1 test day that we ran last week.

Tomcat says that some of the European tech press picked up our testday announcement, and it certainly showed. Lots of new faces in #testday, and over 1300 test results filed by the community over the course of the day (another 270 if you add results from Mozilla QA staff). This was even more impressive considering that this was the second test day we held last week. In the past we’ve seen an attendance drop-off if we hold events too close together.

People seem genuinely stoked about Firefox 3. Lots of testing remains to be done, so I hope to see a lot of those folks back to help some more. Keep it locked to QMO for details.

John Resig: JavaScript Method Overloading

John Resig — 2007-11-13T01:12:12+00:00

In a side project that I've been working on I built a quick-and-dirty function for doing simple method overloading. For those of you who aren't familiar with, it's just a way of mapping a single function call to multiple functions based upon the arguments they accept.

Here's the function in question:

// addMethod - By John Resig (MIT Licensed)
function addMethod(object, name, fn){
var old = object[ name ];
object[ name ] = function(){
if ( fn.length == arguments.length )
return fn.apply( this, arguments );
else if ( typeof old == 'function' )
return old.apply( this, arguments );
};
}

and here is how you might use it:

function Users(){
addMethod(this, "find", function(){
// Find all users...
});
addMethod(this, "find", function(name){
// Find a user by name
});
addMethod(this, "find", function(first, last){
// Find a user by first and last name
});
}

Or, if you wanted to use it with an object prototype:

function Users(){}
addMethod(Users.prototype, "find", function(){
// Find all users...
});
addMethod(Users.prototype, "find", function(name){
// Find a user by name
});
addMethod(Users.prototype, "find", function(first, last){
// Find a user by first and last name
});

And here's what the end result would look like to the user:

var users = new Users();
users.find(); // Finds all
users.find("John"); // Finds users by name
users.find("John", "Resig"); // Finds users by first and last name
users.find("John", "E", "Resig"); // Does nothing

Obviously, there's some pretty big caveats when using this:

The overloading only works for different numbers of arguments - it doesn't differentiate based on type, argument names, or anything else. (ECMAScript 4/JavaScript 2, however, will have this ability - called Multimethods - I'm quite excited.)
All methods will some function call overhead. Thus, you'll want to take that into consideration in high performance situations.

Now, the secret sauce is all going back to the fn.length expression. This isn't very well known, but all functions have a length property on them. This property equates to the number of arguments that the function is expecting. Thus, if you define a function that accepts a single argument, it'll have a length of 1, like so:

(function(foo){}).length == 1

I did some basic testing and this technique seems to work in all modern browsers - please let me know if I'm wrong.

If you're concerned about adding a function call overhead when binding only a single function, then you can give this version of addMethod a try:

// addMethod - By John Resig (MIT Licensed)
function addMethod(object, name, fn){
var old = object[ name ];
if ( old )
object[ name ] = function(){
if ( fn.length == arguments.length )
return fn.apply( this, arguments );
else if ( typeof old == 'function' )
return old.apply( this, arguments );
};
else
object[ name ] = fn;
}

That one will attach the first bound function with no additional checks - keeping it nice and speedy. Once extra functions are bound, things will slow ever so slightly.

This, also, has the added benefit of being able to bind default "catch all" functions which will handle all the calls that pass through. The result would look something like this:

var users = new Users();
users.find(); // Finds all
users.find("John"); // Finds users by name
users.find("John", "Resig"); // Finds users by first and last name
users.find("John", "E", "Resig"); // Finds all

This function won't change the world, but it's short, concise, and uses an obscure JavaScript feature - so it wins in my book.

Blog of Metrics: Vista Users Enjoy the Web on Weekends

kkovash — 2007-11-12T23:54:01+00:00

For funnelcake, we’ve looked at various analyses by OS. Firefox users primarily use three operating systems: XP (first place by a wide margin), followed by Vista and then Mac. When looking at Firefox usage by OS, one pattern that stands out is usage by Vista users does not seem to drop significantly during weekends.

In a previous post, we considered the effect of day of the week on Fx usage (and internet usage more generally). The swing from a typical weekday to a Saturday or Sunday amounted to about a 20% drop-off in usage. For funnelcake users, we’ve seen that most of the Fx weekend usage decline in driven by XP users. However, this is explained by the fact that they represent the greatest percent of total users by OS; on a percentage basis, XP users show about a 20% weekend decline. Of the three biggest OS cohorts, Mac users display the greatest weekend drop-off on a percentage basis – about 25%.

And Vista users of Fx?

Their Fx usage decline on weekends amounts to a tiny 8%.

Furthermore, when we look across all Fx users (not just funnelcake users), the numbers are fairly similar. We’re not entirely sure what to make of this analysis… If you’re aware of any reasons or causal factors, we’re all ears!

Mozilla SVG Update: Mozilla SVG speed and cairo

tor — 2007-11-12T23:41:02+00:00

When using Mozilla SVG, you might have encountered cases where we are quite slow. While there have been great strides in fixing these in both the mozilla codebase and cairo between Firefox 1.5/2.0 and Firefox 3.0, we still see performance problems appearing.

When we profile these slow cases using tool like sysprof, cairo (or what it cause the X server to do in the case of unix/X11) usually makes up the majority of the time spent. If you're interested in helping with Mozilla SVG but don't feel like diving into the thick of Mozilla's flavor of C++, contributing to cairo would a great choice. It's a smaller, simpler codebase in straight C, has a responsive developer list, and improvements you make will help a large world of software beyond Mozilla.

Specific areas of interest to Mozilla SVG are:

Hit detection.: Currently, cairo_in_fill() and cairo_in_stroke() are implemented by tessellating the path and tests against the generated trapezoids. There are a number of other point in polygon testing methods which would be more efficient for implementing cairo_in_fill(). cairo_in_stroke() might be implementable by doing distance to line/curve tests for the path segments, along with some extra tests for the segment joins. Both of these hit detection functions are important to SVG as we are continually checking for objects underneath the pointer for event delivery. We do perform an early reject test against a cached bounding rectangle, but for complex geometry the time spent in cairo can become significant.
Track down overuse of *CompositeGeneral.: Many profiles we've run of slow SVG testcases show lots of cputime disappearing into this method, both on the client (named pixman_compositeGeneral or pixman_compsite_rect_general* depending on the version of cairo you're looking at) and in the copy inside the X server (fbCompositeGeneral). While ideally we'd like to avoid cairo's software renderer completely (as in Michael Dominic's work), it would be good to track down why rendering operations often end up there. My guess is that the frequent use of clipping in SVG (for inner <svg>, <image>, <marker>) is the cause of this.
Server side gradients.: Cairo does not use RENDER's gradients with the xlib backend. Since gradients are a frequently used SVG feature, speeding them up seems like a good thing to do, and if we can keep work on the server side it could be a win (might need work the server side to get the performance and fix possible problems with a currently unused server feature).
Extents.: Right now cairo implements extent calculation for both fill and stroke by tessellating the path in question. This is straightforward and allows cairo to reuse code needed for rendering, but it uses more memory and cpu time that is necessary for the query operation. SVG calculates the coverage information of an object each time a presentation attribute or property changes, so this can add up for complex geometry. Mozilla's SVG code can be changed in the post Firefox 3 world to work better with Gecko to avoid unnecessary calculations for changes that don't change geometry, but for now we need to assume the worst case.
Path extents.: This is a specification conformance issue rather than performance - the SVG IDL allows the bounding box of geometry (without stroke or mask effects) to be queried, and cairo_fill_extents() is both wasteful performance/memory-wise (see previous item) and doesn't give the answer we want for degenerate geometry.
Filters.: Mozilla SVG implements a full SVG pixel filter set (two of which, feImage and feDisplacementMap, unfortunately will not make Firefox 3) by hand as cairo has no native filters. It would nice to have filters in cairo; for the additional functionality it would provide to other users, the ability to hardware accelerate through OpenGL and pixel shaders, and to get more developers looking at speeding up the code.

If any of this sparks an interest, join the cairo mailing list and let people know. You'll be in touch with others working on cairo and get feedback on your ideas.

Justin Scott: Stupid Filter

fligtar — 2007-11-12T23:26:14+00:00

“Because the internet needs prophylactics for memetically transmitted diseases.”

There’s a new open source project at StupidFilter.org to create filtering software that can detect “stupid” comments on the internet, such as comments on YouTube and similar sites. While this is an interesting project, the part that really caught me is that they’re going to release it as a Firefox extension. (They actually said plugin, but I’m guessing they meant extension.) While they mention other forms of delivery, all but the extension are aimed at the hosts of the content, not the consumer.

When I first read about the project on Slashdot, I thought “I hope they make it a Firefox extension”. It’s exciting that so many of the ideas and innovations people have these days are implemented through Firefox add-ons. Hopefully we’ll see even more of that in the future, as Mozilla is investing heavily in its add-ons community and I expect the results of that will be apparent in Firefox 3 and the upcoming changes to the add-ons website, as well as some much awaited new tools for add-on developers that I’ll be blogging about in the coming weeks on the WebDev blog.

John Lilly: uncategorized

John — 2007-11-12T23:10:28+00:00

I’ve been thinking a lot the past day or so about Noam Cohen’s piece in the New York Times about Mozilla. It’s really been rattling around inside my head because it missed so much of the essence of what Mozilla is and what we’re doing. It’s ostensibly a story about how Mozilla has sort of grown up — going from cute little underdog to corporate competitor. Here’s one line: “But in trying to build on this success, the Mozilla Foundation has come to resemble an investor-backed Silicon Valley start-up more than a scrappy collaborative underdog.”

But here’s the thing: by trying to categorize Mozilla with simple labels (SV start-up, scrappy underdog, cold war proxy (!), corporation, open source project, on and on…), he’s missing the point. Mozilla is a complicated thing, filled with tensions and subtleties.

We’re an open source project. We’re also a set of companies around the world.

We have distributed decision making. We also make some centralized decisions.

We’re a non-profit. We also pay people competitive wages for the industry and the geographies that they live in.

Our mission is to keep the Internet a medium of participation by everyone. We also care about Firefox market share because that’s our most useful tool at the moment to achieve the mission.

We do resemble a startup — we recruit talented techies who could work anywhere in the world, we work 24/7 on our technology, we participate in industry events. But we’re trying to build an organization — and an idea — that can last 50 or 100 years, and can make the Internet experience better for all.

We’ve got business relationships with Google, Yahoo, Amazon, eBay and many others. But we prioritize the user experience over any business term.

We have a mission, but we also compete, in direct ways, for the hearts and minds and clicks of humans using the Internet.

We have a lot of money in the bank compared to any other open source project. We don’t have much compared to anyone else who’s generally considered competitive with us.

We donate money to other projects, but we also use money that we have to further our public benefit mission.

We build applications that people use — Firefox is one of them — but we also provide a technology platform with an open license that many, many developers have built great things on, commercial or otherwise.

I could go on and on and on. Mozilla doesn’t fit into clean categories — it never has, in my view. It didn’t fit neatly into a category when it started as an experiment at Netscape nearly a decade ago. It didn’t fit neatly when the small team left AOL to start something completely new called the Mozilla Foundation. And it doesn’t fit now, as an organization/company/project/product with more than 100 million people around the world using Firefox and with something approaching $100M in the bank.

I think it does a disservice to the project to over-constrain Mozilla with simple labels. I’m glad that Noam got as many of the facts right as he did. And I’m glad that more people are starting to tell the story about who Mozilla is and what it’s trying to do in the world — it’s an important story. We’re trying to do a better job at helping folks understand the story, too, in all it’s messy, complicated, contradictory and uncategorized glory.

Al Billings: The New York Times askes whether success will spoil Firefox

Al — 2007-11-12T21:28:39+00:00

Today in the New York Times, there is an article titled, “Will Success, or All That Money From Google, Spoil Firefox?”

The article focuses on the amount of money that the Mozilla Foundation has generated through the deals that MoCo has with Google and other search providers. To quote the article:

The foundation has used a for-profit subsidiary, the Mozilla Corporation, to collect tens of millions of dollars in royalties from search engine companies that want prominent placement on the browser. And by collecting that money as a war chest to compete against giants like Microsoft and Apple, the foundation has, at least temporarily, moved away from the typical activities of a nonprofit organization.

“The Mozilla community has been a bit hybrid in terms of integrating public and private investment all along — its history is fairly unique in this respect,” Professor O’Mahony said.

So far, the many contributors to Firefox seem pleased with its financial success. The bigger question is what Mozilla will do with all its money.

Overall, the piece doesn’t really bring up anything really new, in my opinion. People have been wondering aloud and making comments for a while now about both the amount of money that the Mozilla Foundation has brought in, what the foundation is going to do with it, and the fact that most of it comes from partnering with Google. The less common question about what happens if Google decides not to continue the relationship was also raised but, again, nothing new was really said.

As a whole, the NYT piece really seems to be repeating the questions that have been raised before along with speculations about “what if…?” that are not terribly new. The only thing that I really saw that was new was the interviews/quotes with people that I have not seen comment up until now.

I did find it amusing, given the recent newspaper story in Seattle about the silence around Internet Explorer 8, that Dean Hachamovitz was quoted in this story and managed to raise concerns around the IE8 silence while discussing Mozilla:

“We are much more reserved about thinking out loud as we make the browser better,” he said. “I can go through and talk about all the innovations we have made, but we don’t talk about them until they are done. People make very important decisions based on what Microsoft says; we have a responsibility about what we say out loud.”

I find that kind of a poor excuse for their silence for an entire year about IE8. I also find it to be an odd comment in the middle of a newspaper article about success and the Mozilla Foundation. I wonder why the author of the piece decided to include it in an article about IE’s main competitor.

In any case, the NYT does not really raise any new issues or answer questions that some have had but it does continue to put the spotlight, to some extent, on “What next?” for the foundation. It has a lot of money in the bank. Some plans, like the ones for MailCo, are obviously in the works (though not even mentioned in the article) but this is obviously a question to be solved, over time, as the foundation moves forward.

Taras Glek: Cleaning up my act

tglek — 2007-11-12T21:10:19+00:00

I added an “ongoing work” and “tools” sections to the Mozilla 2 page.

The pork suite now has a wiki page.

#mercurial regulars kindly educated me about hg branches. Turned out hgimportsvn tries to map some subversion concepts onto hg branches which causes problems for people checking out pork using never versions of hg. For people googling for this issue: do “hg up trunk ; hg branch -f default; hg commit” to produce a magic empty revision to fix this problem.

If you have tried to compile pork before and gave up in despair, please try again using the pork wiki page for instructions.

QMO: The Testday for Firefox 3 Beta 1 continues - Join us Friday, November 16th !

Tomcat — 2007-11-12T21:06:12+00:00

Start: 2007-11-16 08:00

End: 2007-11-17 06:00

Timezone: Etc/GMT-8

Hi,

Many thanks for all the help we got on the first Firefox 3 Beta 1 Release Candidate Testday last Friday. We got a lot of good feedback and bug reports. You can see the result of this very successful testday here .

QMO: Join the Firefox Bugday tomorrow, November 13th 2007 !

Tomcat — 2007-11-12T20:22:44+00:00

Start: 2007-11-13 09:00

End: 2007-11-14 09:00

Timezone: Etc/GMT-8

Hi,

Just another friendly reminder to join in #bugday on

*Tuesday, November 13th:*

* Asia session - 14:00-16:00 (Beijing)

* Euro session - 14:00-16:00 (Berlin)

* Amer. session - 12:00-14:00 (Los Angeles)

See also the timetable on
http://quality.mozilla.org/events/bug-days#Schedule for your Timezone.

Nagappan: Linux Desktop Testing Project editor

Nagappan — 2007-11-12T18:37:00+00:00

A nice post by Hari, Thanks for your nice post.

Want to use LDTP to test your application? Or do you want to automate the actions you do often? Or are you a GNU/Linux user who want to show “magic” to your friends by recording your actions and playing them back? You can use LDTP for this. But one small issue with LDTP is that you should know the LDTP Python API to write any test suite. But with the new LDTP Editor, this makes your job really simple. A screenshot of the LDTP Editor is shown below.

This is a simple HOWTO for recording and playing back the recorded script.

Installing LDTP.

Download the lastest LDTP source code from http://people.freedesktop.org/~nagappan/ldtp-0.9.2.tar.gz.
Uncompress the file.
Compile the code using ./configure and make
If you don’t have the access to install softwares, run the ldtpeditor file in the python folder
If you have access to install softwares, then run “make install”

Note:: After installing LDTP Editor, i when i tried to run ldtpeditor, got an error saying

hari@hari-laptop:~/ldtp/ldtp-0.9.2$ ldtpeditor (ldtpeditor:11130): libglade-WARNING **: could not find glade file '/usr/share/local/ldtp/glade/ldtpeditor.glade' Glade file not found

The ldtpeditor.glade file is present in the python folder. I got this error because i compiled the code as ./configure. If i had done it as ‘./configure –prefix=/usr’, then i wouldn’t have got this error. Anyway i copied the file manually to that folder.

hari@hari-laptop:~/ldtp/ldtp-0.9.2$ sudo mkdir -p /usr/share/local/ldtp/glade/ hari@hari-laptop:~/ldtp/ldtp-0.9.2$ sudo cp python/ldtpeditor.glade /usr/share/local/ldtp/glade/ hari@hari-laptop:~/ldtp/ldtp-0.9.2$ ldtpeditor

After that when i ran ldtpeditor, it ran without any issues.

Recording using LDTP Editor

For this let us consider recording the actions performed in gcalctool.

First make sure Assistive Technology is enabled in your desktop. If you are not sure about this, open gnome-control-center and in that open Assistive Technology Preferences. You should have Enable Assistive Technologies checked to use LDTP.
If you are enabling Assistive Technology only now, logout and login again.
Run ldtpeditor and gcalctool.
Make sure both you have enabled ‘Always on Top’ or both the applications and both the window doesn’t overlap with each other.
Click the Start button the LDTP Editor. All actions performed after this are recorded.
Perform actions in the gcalctool. Check out this video to see the actions i recored in my computer .
After you’re done with the actions in the gcalctool, click the Stop button in the LDTP Editor.
You can see that the ‘Recorded Code’ tab is updated with code as when you perform actions in gcalctool.
Click the convert button in the LDTP Editor. You’ll see that the Generated LDTP Code and Generated LDTP XML tabs are filled with generated code.
The Play button is not working now. I wrote the patch for that yesterday night ;-).
Save the contents of the ‘Generated LDTP Code’ into a python file (for ex frisco.py) . Note that if the file name you specify already exists, then it OVERWRITES the filename without any warning.
Then run hari@hari-laptop:~$ python frisco.py
The actions you performed while recording will be played back again :-)

Currently the Play button in the LDTP Editor is not enabled. But you can make it work by applying the patch mentioned below. I guess this patch will be added to LDTP Editor in a week or so. So check the ChangeLog file before applying the patch.

LDTP Editor Preferences

Using the LDTP Prefereces, you can control what all actions you can control. A brief summary about the options given in the Preferences window.

Listen key events
This option is not yet implemented. Checking/Unchecking this doesn’t make any difference now.
Listen mouse events
This option is not yet implemented. Checking/Unchecking this doesn’t make any difference now.
Generate LDTP Code
Only when if this option is enabled, Convert will generated to LDTP code in the ‘Generated LDTP Code’ tab. This is enabled by default when you run LDTP Editor.
Generate Data XML
If this option is enabled, the LDTP Editor will generate data XML for the actions you perform.
Generate keyboard events code
Generates code for the keyboard events you performed during the recording session.
Generate wait time code
Calculates the delay one takes between each action during the recording session and generates code so that similar time delay is generated while play back.
Generate Memory / CPU statistics.
The code to generate Memory and CPU statistics will be generated. You need to install pystatgrab and libstatgrab packages.

Patching to make the Run button work

Copy this patch file to your ldtp folder.
Runhari@hari-laptop:~/ldtp/ldtp-0.9.2$ cd ldtp-0.9.2 hari@hari-laptop:~/ldtp/ldtp-0.9.2$ patch -p0
Compile the code again and run ldtpeditor. This time after you Convert the Code, you can Run the code from the LDTP Editor. :-)

Note:: The generated code had many unwanted waittillguiexist. I saw waittillguiexist(”dlg0″) in many places. If your playback is stopped because of this, remove that before running the scripts.
Sometime the resource will go high as the application map info is collected from the application, so no need to worry.

If you find any issues regarding LDTP Editor, report it to ldtp-dev@lists.freedesktop.org or nagappan@gmail.com or sp2hari@gmail.com

All patches are welcome. :-)

My comments:

You can use ./configure --prefix=/usr to avoid that glade file missing warning.

Additional notes:

* After clicking record click 'Convert' to get the code converted in LDTP format (It does some post processing, so its required)
* Click save button to save generated python script, if 2nd tab is empty, then it will try to get the contents of first tab and store it in the file you specify. If file already exist, it will *OVER-WRITE*
* control+c, control+v doesn't work
* Sometime the resource will go high as the application map info is collected from the application, so no need to worry. With Thunderbird, the recording really sucks
* You need to have GNOME 2.14 and above to use LDTP editor

Daniel Glazman: Moi j'vou'l'dis

Daniel Glazman — 2007-11-12T18:17:00+00:00

Si malgré les grèves monstrueuses qu'on se prépare j'arrive jusqu'à ParisWeb mercredi, ça va faire coin-coin moi je vous le dis !!!

Doug Warner: Mozdev status update for W45-2007

silfreed — 2007-11-12T17:14:24+00:00

Another big week of mirror work. I received responses from all the current mozdev.org mirrors as well as some that I wasn't aware was acting as a mirror. I have most of the mirrors assigned to regions so redirection to the closest mirror should be happening in the near future (once I work out a couple little quirks).

Updated mirrors.mozdev.org content - Our mirrors.mozdev.org content was a little stale but is now being generated dynamically from our list of available mirrors. There's even a tool for you to enter your IP address and see what your preferred mirror set is.
Download counters - I've setup tracking of downloads so that we could re-enable the downloads() function for our project sites so they can see how many downloads they're receiving for particular files. The Top 50 page has even been updated to show downloads for the last month.
Drupal setup for several projects - Several projects have requested to have Drupal setup so that they can evaluate its features. The projects include stalemate, Mycroft, and Brief.

I would like to get the last pieces of the download redirection completed.

I will also be working on a secure installation method and would appreciate any comments people have about my proposal.

Happening simultaneously might be the Bugzilla 3.0 upgrade. We'll be announcing on the project-owners list when this is planned to occur and will be asking people to check out our test install to make sure we haven't overlooked anything.

Robert Kaiser: Weekly Status Report, W45/2007

KaiRo — 2007-11-12T17:08:56+00:00

Here's a summary of my SeaMonkey/Mozilla-related work items in week 45/2007 (November 5 - 11):

SeaMonkey Releases:
SeaMonkey 1.1.6 was released on Monday, I continued uploading contributed builds throughout the week.
SeaMonkey Website:
I spent another bunch of time on getting the new Website finalized to be our primary web appearance, which we switched to on late Sunday finally.
SeaMonkey Project Structure:
Internal discussions in a core team around the SeaMonkey Council continue, we hope to get something about our restructuring into the public soon.
Source L10n:
My SeaMonkey L10n announcement is written, but I still want some signoff by the Mozilla L10n lead. Wait to read more about this soon.
The L10n review for CVS-based ChatZilla langpacksis a bit unclear to me, I need to discuss that a bit further with Axel.
German L10n:
FF3beta1 should really be able to ship in German, and SeaMonkey trunk builds were also kept up-to-date.
Various Discussions:
Cert override UI, feed discovery, browser notifications, login manager, storage templates, dictionary licensing, auto-update system, etc.

As you might have seen, the new SeaMonkey website features a "Powered by Mozilla" logo - we are proud to be part of this amazing project and glad to be able to advertise our Mozilla heritage and core (and not some other brand). I still love the old theme that I think is now as accurate as ever for the Mozilla project: "hack - this technology could fall into the right hands"

Robert Kaiser: New seamonkey-project.org Website Is Live!

KaiRo — 2007-11-12T13:36:01+00:00

I've been working on a new SeaMonkey website for a while - now it's finally live at www.seamonkey-project.org!

The old www.mozilla.org pages are replaced with a redirect to the new site, so everyone accessing our project should be directed to seamonkey-project.org now.

We have reworked the whole design, added new developer and documentation sections (which could need some more content, help wanted), made the download box at the front dynamic for people using JavaScript, and did lots of other tweaks, including preparation for eventual future localized versions of the website.

I hope the new look suit(e)s you all!

Frederic Wenzel: OSX Leopard: Keep XTerm from starting with X11

Fred — 2007-11-12T12:54:49+00:00

As we established before, X11 on OSX 10.5 Leopard is, at least kind-of, broken.

Gladly, there are numerous community efforts to bring our tragic hero back on stage. For example, like in OSX 10.4 Tiger, it is possible to deactivate the XTerm window starting up every time you start X11. It has just become a little more complicated.

First, this is what has changed with launching X11 on Leopard (as described on boredzo.org):

In Tiger, when you launch X11, it runs .xinitrc, and .xinitrc runs xterm (unless you comment that line out).

In Leopard, X11.app is just a launcher. All it does is run /usr/bin/login -pf $USER /usr/X11/bin/xterm. In other words, its only purpose is to run xterm (semi-)directly, by itself–it’s not the actual X11 server anymore. When xterm starts, launchd sees it, notices that xterm requires X11, and launches the real X11 server (/usr/X11/X11.app) automatically.

In other words, there’s no commenting out a line in .xinitrc anymore in Leopard. Instead, we need to change the launcher itself (as described in the very useful X11 on Leopard FAQ on macosxhints):

defaults write org.x.X11_launcher app_to_run /usr/X11/bin/xlsclients

Instead of xlsclients, we can alternatively run xprop (thanks, JP!). Both applications have the good habit not to do much (i.e. not to waste a lot of cycles/energy/water/CO₂/whatever) and also not to open an annoying window like xterm does.

Hope this helps

Frank Hecker: Mozilla Foundation activities, week ending 2007/11/09

Frank Hecker — 2007-11-12T05:22:00+00:00

This is my report on activities related to the Mozilla Foundation for the week ending November 9, 2007.

Projects for the week

Here's a summary of what Foundation-related activities went on last week; for more information about others' activities please see the weekly status reports published by David Boswell, Gerv Markham, and Zak Greant.

Grants and related expenditures
- The Mozilla Foundation made a grant to the Perl Foundation to support Perl 6 and Parrot development.
- We're funding some work by Eitan Isaacson to follow up from his project to migrate the Orca screen reader for Linux to the pyatspi library, including in particular improving the performance of Orca with Firefox. This project also includes work covered by GNOME bugs 448848, 446277, and 491862.
- We're also funding Codethink Ltd to do a study to evaluate the feasibility of porting the GNOME AT-SPI accessibility interface from ORBit to D-Bus; we're looking at this because ORBit is being deprecated, and we want to make sure that the accessibility infrastructure used by Firefox on Linux is as up to date as possible.
- Dojo 1.0 was released last week with lots of accessibility-related enhancements, including those developed by the University of Toronto Adaptive Technology Resource Centre with funding from the Mozilla Foundation; for more information see the final report on the project.
CAs and related issues
- Last week I published version 1.1 of the Mozilla CA certificate policy; this new version formalizes our policy for considering requests from CAs to have their certificates marked as capable of issuing Extended Validation certificates. Note carefully: This does not guarantee that you'll see EV capability enabled in Firefox, particularly for every CA that claims to issue EV certificates; this is just a policy revision, and actual EV support will depend on the work of the NSS and Firefox developers.
- I did some work on CA applications from SwissSign and VeriSign, and will continue working on other CA applications this week.
Other
- Gerv did some work on Mozilla community activities in the UK.
- Zak delivered a keynote address at the International PHP Conference.
- David was on vacation all week.

Upcoming activities

I'm tentatively planning to be in Mountain View on December 11 and 12.