Planet Mozilla

Robert O'Callahan: Text Progress@Planet Mozilla

Among other things, I've been working away on the new textframe code. I've (re)written the layout part around the new gfxTextRun abstraction and things fit together pretty much as I expected except for a couple of issues. One issue is that CSS :first-line and :first-letter styling doesn't map well onto the gfxTextRun concept. gfxTextRun assumes that the glyphs used for a chunk of text are largely independent of the formatting of the text into lines. I worked around this by aggressively recreating textruns when :first-line and :first-letter are in use. Ugly but effective and simple. Another issue that came up was that we really want textruns to span multiple DOM text nodes, if those nodes are visually consecutive and use the same font. This allows chunks of shaped text to be styled differently ( e.g., as a link) without breaking shaping between chunks. Even for Latin text, it allows kerning and ligatures to work across styling boundaries. It also means that a set of text nodes adjacent in the DOM will render identically to a single text node, which is an important property to have. So I had to rework everything to allow a gfxTextRun to span DOM nodes. This added some complexity but I think it's worth it. It will make textrun setup slower, but it will make other things faster because we'll be able to create fewer and bigger textruns, which means fewer expensive calls down into Pango and other APIs. The next step is for me to implement gfxPangoTextRun. This is requiring me to delve into Pango and figure out how to use its APIs. A key concern is to minimize the memory usage of live textruns. I think I have a scheme that will use four bytes per character in most common cases. We'll see how it goes. Once nice benefit of textrun objects is that those four bytes directly encode glyph indices and advance widths for the text, and we can also keep cairo_scaled_font_t pointers in the textrun, so painting text becomes very simple: very little more than a single pair cairo_set_scaled_font()/cairo_show_glyphs(). Repeated rendering of the same text should be about as fast as it possibly can be from our end ... any remaining problems can be blamed on cairo :-). One remaining issue I haven't figured out yet is the problem of line endings changing the shape of characters in the textrun. For example, what happens if a font has a "tt" ligature and we hyphenate "cutting"? Also, since you can't kern across line breaks, the advance width of a character could be different if there's a line break after it. Furthermore, OpenType supports glyphs with different shapes when they occur at the beginnning or end of lines (although I don't think Pango does this yet). Currently gfxTextRuns are nearly immutable, which is very nice; the only visible mutable state they can have is cached spacing data. But I think we'll have to solve the line-ending problem by breaking that immutability and adding line ending state. Implementing this with Pango seems tricky though, for example we'll have to somehow un-ligate ligatures. I really don't want to have to recreate the entire layout, or keep enough data around in case we need to do so. For now I think I will just check at textrun creation time whether there are any break opportunities inside "problematic" text (say between two non-space characters) and only keep around the information to recreate the layout if there is at least one such opportunity. There is a related issue: how do you draw text where the style changes in the middle of a ligature? E.g. affluent where the font has a ligature for "ffl". I think we'll be doing what everybody else seems to do, a cheesy hack where you use clipping to cut the ffl glyph into three equal horizontal segments. (But you can't use this approach to avoid the un-ligating I mentioned. For example if you applied it to hyphenate "af-fluent", you're likely to have a pixel or two from the top of the first f appearing on the other side of the hyphen, or something equally disgusting.)

Robert O'Callahan: Here Comes A New Challenger!@Planet Mozilla

A friend pointed me at a very interesting article about the New York Times Reader, which is based on the Windows Presentation Foundation. You should also read The Times' FAQ. It fulfills my expectations that I blogged about before: a classy application that takes eyeballs away from the Web and back to a world fully under Microsoft's control. Obviously we need to make it possible to do the same things in a Web page. As far as I can tell there are three sets of issues: offline access and layout. The rest of Reader's features could be implemented using existing Web technology, as an AJAX application (although XUL would help). I believe the offline access issues are actually easier to solve; we're shipping part of a solution in Firefox 2 (DOM Storage). The other part of a solution is the ability to fetch and pin pages in the browser cache so sites can ensure they'll be available offline. I have a proposal for that. It needs some work but doesn't seem to be a huge task to specify and implement. The other issues are layout and rendering. Clearly there's a big emphasis on columns; fortunately Firefox does columns. Unfortunately our columns don't make it easy to create the sort of page-based UI I see in the screenshots. I think a possible approach would be to use XUL box layout to create the header/body/footer vertical arrangement (via CSS, no XUL elements), and make the body overflow and scroll to the right. Then modify the Gecko event code so that the pageup, pagedown, space, and arrow keys do the right thing (namely, scroll left by a page, scroll right by a page, scroll right by a page, and scroll by columns). This would require just a few code tweaks and no new style properties. The page navigation bar in the footer could be easily implemented using script, onresize, and onscroll handlers, but I don't know if it's really useful. The hardest issue that I can see in the Mississippi screenshot, where the image is on the right-hand side of the first page and spans columns. One way to achieve that here would be to allow column content to flow around floats outside the column flow. Then the article title and the image could be placed in left and right floats respectively and the column content flowing around them would produce the right effect. We could also add the ability for content in columns to flow around overflowing content from previous columns, which would let people put column-spanning objects in the column flow. That still isn't enough to produce some common effects, such as figures at the top or bottom of a page. For those we will need CSS extensions. One possibility is to extend "float" with "column-top", "page-top", "column-bottom", and "page-bottom" values. Another issue mentioned in the article is fonts and typography. I can't tell much from the screenshots but they don't appear to be using widow/orphan control, so it's probably about font rendering. We do desperately need a solution to font downloading. On the bright side, our current Gecko work will let us improve our story with kerning, ligatures and other font rendering issues. Even if we can implement all these things, there's still the issue of how we get people to use them in their sites. Microsoft is very good at partnering with major companies to produce showcase applications like this NYT Reader. We need partnerships like that. You would think that certain major Web sites would be interested in pushing back... Reading between the lines, though, there is a lot of hope for the Web. The application is a 20-minute download for XP users without WPF installed, and it apparently requires a trust decision from the user, so it's not for casual surfers. You will need to leave the Reader application to follow links to other sites or content that hasn't been reformatted for the Reader yet, and links to NYT stories from other sites probably won't open in Reader. The Web's hypherlinked nature give it a lot of gravity and it's hard to see that changing in the medium term. The NYT had to develop their own application with Microsoft's help and has to deal with its content being served out in a different way. If we can produce an experience comparable to Reader in the browser --- and especially if we can make it available as a set of easy, downward-compatible changes to existing sites --- I think we'll have an overall much more compelling user experience.

Robert O'Callahan: Status@Planet Mozilla

I've been working my way through a backlog of stuff. Most noticeably, to some anyway, I've caught up on my reviews. I currently know of no outstanding review requests where the ball is still in my court. If I've missed something, let me know. Lately I've been working on the new textframe code in bug 333659, that reorganizes text layout around the new gfxTextRun abstraction. I've written all the new layout parts, almost completely replacing nsTextTransform.cpp and nsTextFrame.cpp. There's still a lot of work to do to implement gfxTextRun on all platforms. I'm starting first with the Pango-based implementation, but that's stalled while I wait for masayuki's rewrite of our existing Pango code to land. The new code feels nice to me. It handles combining characters and clusters everywhere and seems a lot simpler than the old code. Hopefully it will perform better too, now that we can retain glyph conversion and placement between layout and painting. Only testing can tell. The dependencies surrounding this code are quite complex at the moment. The new textframe depends on changes to inline layout that I have filed as a separate patch. But the inline layout changes actually break the computation of minimum width for text containing words of more than one element (e.g., Hello). Fixing that really needs the reflow branch. Turns out that the reflow branch is also broken in the same way and fixing it could use these inline layout changes! On top of all that, the new textframe code is really needed to help improve performance with cairo, so the complete cairo switchover needs this code. Sigh... Timeless prodded me to work on scrolling performance, which has regressed on trunk a bit, especially for certain sites such as Gmail. We found a few issues and I have patches to fix those that I should check in tomorrow. They're all to do with "scroll analysis", how we determine when and where it is safe to scroll a window using "bitblit" (just copying pixels from one place to another on the screen). A full explanation deserves a blog entry of its own. Next I think I'll shoot down a few random bugs. Maybe fix the file input control so that the textfield is operable again, but typing into it brings up the filechooser dialog. Soon I plan to dive into the ubrowser patches and try to get it running on Linux and ready to land in Mozilla CVS somewhere.

Dave Bottoms: The Marketing Conversation@Planet Mozilla

Tue, 28 Oct 2008 23:35:57 +0100

This post will be the first in a series about what I?ve been up to since joining Mozilla just after Download Day. Lots has happened since then? and my intent is to get better about more frequent posts. Now that I?ve worked through a quarter?s worth of projects, I?ve gotten to know the team, their areas of expertise and a bit more about how things work around here. (David, John, Alix, Jay and Tara did a great session on open source marketing, at the Summit btw). But before I get into marketing at Mozilla, I want to discuss a few thoughts on marketing in general. So what is ?marketing? anyway? It?s a relevant discussion starter because the role can vary widely from place to place, even within the same vertical industry (consider Google vs. Yahoo!). The role and tactics can also vary depending on the stage of the product life cycle or breadth of offering (think start-up vs. Fortune 100 enterprise). Marketing strategies demand a fairly fluid set of activities that should change from quarter to quarter, year over year. And the function should evolve to reflect both the maturing of products and services, as well as the audiences and potential use cases. I generally think about marketing as the functional fusion of art and science.� There?s the creative, consumer-facing stuff people often associate with marketing -? logos, taglines, t-shirts, trade shows, and in some instances, advertising. Then there?s the science ? the quantitative market research and analysis used to identify who we are talking to or should be trying to reach. This includes insights into the core user base, what they expect from the products that matter most, and how to effectively connect with them across different channels and touchpoints. It?s the combination of the art and science that generally leads to the best ?marketing.? If the objective is to deliver the right message via the right channel to the right user at the right time, the end result should be prompting some desired action (like switching to Firefox). But if you think I?m talking about advertising, think again. Mozilla is unique in that our ?right? message about why to try Firefox is much more often delivered first hand by our current users via word-of-mouth conversations than by our own web site, a Google search, a press article, or an ad. In fact, Laura Mesa just posted some of the initial results of our first quarterly customer satisfaction survey, where 55% of users responded they heard about Firefox 3 from a friend?s recommendation. Moreover, when asked to rate their likelihood to recommend Firefox ? arguably the simplest but most telling metric for how satisfied users are with a product ? the top-2 combination (adding the 4s and 5s) totaled 89%. When you factor out the negative ratings, you still wind up with a baseline� Net Promoter score of 86. Granted, this survey may reflect own most engaged users, the ones who actually took the time to take a simple survey. But still, this is really, really powerful stuff. Especially in the digital era when people are constantly bombarded with intrusive ads instead of contextual conversations that people can participate in. One of my favorite descriptions of the role of marketing is from Doc Searls in the preface to ?The Cluetrain Manifesto.? He writes: ?my brief philosophy of marketing: ?�� Markets are conversations; and ?�� Conversation is fire. Therefore, ?�� Marketing is arson. I just love that. Our job as marketers is less about launching campaigns and more about starting conversations that can impact markets. In a nutshell, we should all be thinking about how can we make our product more worthy of conversation? Seth Godin has a beautiful description of making marketing remarkable in his book called Purple Cow. This philosophy tends to play out on the creative side, but equally important is where and with whom those conversations need to happen in order to grow our share of mind and market. Which brings me back to the blend of art and science. As armchair pop culture critics can attest, the ?marketing department? often gets the called out for misguided attempts to position and promote products to audiences that have little interest, desire or incentive to engage in the conversation. (Anyone read about the Seinfeld campaign for Windows?). Often times it is less about bad creative (the art part) and more about limited insights (the science part). Marketers who have a better handle on the science?who the target is and the attitudes they exhibit?have a much better chance at delivering on really compelling art. So when I started at Mozilla back in June I went through a simple planning exercise that entailed asking questions, identifying gaps in understanding the marketplace, and assessing what we?ve been doing to move the needle. I?m pleased to say we?re doing pretty darn well by a number of performance measures, but I?ll save this discussion for another post.� For now I?ll leave this one with an open call to keep participating in the marketing of Firefox ? visit SpreadFirefox.com and start a conversation. Posted in Mozilla��Tagged: CSat, Marketing, Mozilla��

Benjamin Smedberg: Paginate the Web?@Planet Mozilla

Tue, 28 Oct 2008 22:58:20 +0100

Web pages scroll, usually vertically. Is this a good thing? I was reading an article that Deb pointed out from The Atlantic: ?Is Google Making Us Stupid?? and I noticed something: I could easily keep attention on the page when I wasn?t scrolling. But as soon as I got to the bottom of the page, it was much harder to stay focused. What if web browsers paginated articles by default, instead of laying them out in a vertical scroll view by default? Would that improve reader attention span, or just cause users to stop reading after the first page? Is it possible to write a Firefox extension to render websites as paginated entities instead of scrolling entities? I suspect not, and that would require assistance from the core Gecko layout engine, but I think it would be a very interesting UI experiment!

Jay Patel: Learning about our Mozilla Campus Reps?@Planet Mozilla

Tue, 28 Oct 2008 21:08:31 +0100

This is our second year running the Mozilla Campus Reps program and we have already signed up 550 reps?with even more on the ?waitlist? to get on our official roster.� We?ve come a long way since working with about 50-60 students last year? and the community is growing quickly!� A program that kicked off with the release of the Firefox Campus Edition and a small ?Back to School? program in 2007 is now one of the fastest growing Mozilla communities in 2008. We?re building a strong network of students and faculty around the world to help promote Firefox and educate folks about Mozilla and our mission.� In order to help me better plan campaigns and projects for them to participate in I included a short survey during the registration process that ran from August - October 2008. I?m starting a series of blog posts about our Campus Reps community to share some interesting numbers that have emerged from the responses we received.� First, I will break down where our Campus Reps are, including the countries (61 and counting) they represent and some of the colleges and universities they cover.�� Then I?ll look into what they?re doing on the Web and some of their favorite social networks (Facebook was popular) and Firefox Add-ons.� And finally, I wanted to share some of the great feedback and ideas they have shared with me about how they represent Mozilla and promote Firefox with colleagues, family, and friends.� Here?s what one rep had to say: ?Working at the computer help center on campus, dealing with students who are having severe connectivity or popup issues, it?s easy converting to something that JUST WORKS! Speed, open source, works the same as what you already have just better!? Please join me in welcoming our Mozilla Campus Reps for 2008-09 and look forward to learning more about them in my upcoming posts.� Thanks!

Robert Kaiser: The Death of the Fishcam Easter Egg?@Planet Mozilla

Tue, 28 Oct 2008 21:02:12 +0100

It looks like the legendary Netscape (later AOL) Fishcam in Mountain View has really gone away now, the last URL where one could get a live feed has been redirected to netscape.aol.com, and a still existing old page has only static content but no live camera any more. SeaMonkey still has the Ctrl-Alt-F shortcut mapped to calling a webpage for the fishcam but this has been failing recently. In theory, a live cam of maritime life would fit very well with SeaMonkey, actually (due to the creatures we're named after), and it would be even cooler if that would use an ogg stream and the HTML5 tag on trunk. It's just that we don't have such a cam available any more, from all we know. Because of that, I probably will review the patch to remove this easter egg unless someone comes up with a really appealing proposal of where it should point to nowadays.

Eric Shepherd: Even more updated reference documents@Planet Mozilla

Tue, 28 Oct 2008 20:42:56 +0100

Here?s a list of even more interfaces for which the documentation has been updated to Firefox 3.1: nsISessionStore nsIThreadPool nsIThreadPoolListener nsIXPCScriptable nsITimer Note that a couple of these (notably nsIXPCScriptable) are not very thorough documents, but are up-to-date in that they at least mention all the new stuff, which is covered in roughly the same amount of detail (or lack thereof) as anything else therein. With these, all of the interfaces already documented on MDC have been updated to cover Firefox 3.1 (as it stands today).� There are plenty of interfaces that aren?t documented yet, though.� We?ll get to them!

Robert Kaiser: Weekly Status Report, W43/2008@Planet Mozilla

Tue, 28 Oct 2008 19:42:29 +0100

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 43/2008 (October 20 - 26, 2008): Build System: The newest build system sync landed, removing more lines than it added. Some locale Makefile update could land as well, but Axel Hecht landed some rework of the browser file recently, and we should port that as well. And then, localizers complain right now about disagreement of en-US files and the installer string check tool on variable usage.Geolocation: The geolocation prompt for SeaMonkey could land now that the Firefox bug we found has been fixed as well. With this, geolocation support in SeaMonkey is the same as in Firefox 3.1 - we can plug providers of location info but right now rely on extensions to implement those, and if a website requests geolocation info, we prompt the user if we should hand it exact location, neighborhood or no information at all.Helpwanted Items: As discussions and bug fixes in other areas went along, I filed a few bugs that basically fall in the helpwanted category, i.e. we're looking for someone to work on them: breakages and followup ports related to jmita's kill-rdf work in Thunderbird, a context menu for the HTML5 element, and a fix for secure favicons (for those who switch on the related pref).Mozilla Camp Europe: This weekend, a significant part of the European Mozilla community, including myself, met in Barcelona for MozCamp Europe. It was nice to meet some of those people from the community again, and get to know a few folks I haven't met in person before, like Ian Neal or Serge Gautherie. In addition to a few quite interesting talks, a huge part the notable things was going on in personal talks between people - for example, I realized that all related people I could talk to have pretty uniform thoughts about how Thunderbird and SeaMonkey should work together regarding sharing, forking and unforking of code, which to the most parts can be summarized as "share all the backend, those dialogs that are as they are because they can't be a much different and the utility functions to access backend functionality (ideally as JS modules); fork the main frontend". We still care about each other's forked frontend code to some degree though, as we like to port parts of it back and forth and apply our own twists on each other's ideas. This is actually quite similar to a lot of the relationship we have with Firefox, with toolkit as the code sharing hub. In the mailnews case, we should just make all that interaction and structure cleaner, including for example the sharing of L10n files for shared code, which is not happening right now. This was only one of the quite interesting topics were were able to talk about, and I'm looking forward to having more of those personal talks with people at other similar events. Tristan called Mozilla, like that event, being all about "fun, work and friends" - I think I rarely heard a better summary of why our community works so well.Various Discussions: killing MOZ_XUL_APP, tabmail and Lightning, places history and location bar, etc. One of the areas I've been thinking about more and more recently and what also came up at MozCamp in Barcelona is the long-term vision for SeaMonkey. This is not about specific features we want, and this is not about SeaMonkey 2 or 3 or so - this is more about the stars shining on the horizon that give us a clear orientation of where we want to be moving to in the long term. That vision is closely related to our target audience, and is built up by high-level goals. For now, we are busy with making SeaMonkey 2 catch up to modern technology and represent where browsers and mail/new clients are supposed to be currently, but after we will have achieved that, we will need to know where to go from there, in what direction our software should develop. Is conserving historic UI our goal? Is merely throwing copies of Firefox and Thunderbird into the same process our goal? Is tight integration and breaking up borders between browser, mail, chat and maybe even web page creation our goal? Is overloading the UI with options almost nobody uses our goal? Or having everything a power-user regularly uses available as easily and fast as possible? Is a strict structure of predefined UI our goal, or as fully customizable user experience? Is SeaMonkey relevant at all in the long run? Why (not)? I'd like everyone who considers himself part of the SeaMonkey community to take a few moments in a probably otherwise unused timeframe, let you thoughts circle around this topic a bit, perhaps take notes, and try to figure out where you want SeaMonkey to go in the long term, where you see those visions and why. I'll start a thread on the development newsgroup about this soon, and I'll probably blog about it even more. It will be interesting to hear your thoughts and figure out where we all will be heading in the future!

Alice Nodelman: The Super Secret List of Graph Links@Planet Mozilla

Tue, 28 Oct 2008 19:17:20 +0100

This really shouldn?t be super secret, but it has come to my attention that some people don?t know about the compendium of Talos graph links. It?s really hard to construct graphs on the graph server that are a) meaningful and b) correct - you have to know which talos machines are testing which code and if they are configured in such a way as to generate useful comparisons.� While we are currently doing a lot of graph server infrastructure work, it is going to be a while before we can fix this overarching difficulty.� I?ve been maintaining this list of graph links for some time and keeping them organized by branch, platform and test. So, next time you are pushed to the brink of madness trying to figure out if there is a regression in Ts for mozilla-central on WinXP, please use the graph links and save your sanity.

Brendan Eich - Roadmap: TraceMonkey Update@Planet Mozilla

Wed, 03 Sep 2008 11:45:00 +0200

We have been busy, mostly fixing bugs for stability, but also winning a bit more performance, since TraceMonkey landed on mozilla-central, from which Firefox 3.1 alpha-stage nightly builds are built. Tonight's builds include a fix for the bug that ilooped a SunSpider test (my apologies to those of you who suffered that bug's bite). But what I'm sure everyone wants to know is: how do we compare to V8? Here are the results from head-to-head SunSpider on Windows XP on a Mac Mini and Windows Vista on a MacBook Pro, testing against last night's Firefox automated build and yesterday's Chrome beta: We win by 1.28x and 1.19x, respectively. Maybe we should rename TraceMonkey "V10" ;-). Ok, it's only SunSpider, one popular yet arguably non-representative benchmark suite. We are not about to be braggy. ("Don't be braggy" is our motto here at Mozilla ;-).) But it's worth digging deeper into the results. Let's look at the ratios by test: We win on the bit-banging, string, and regular expression benchmarks. We are around 4x faster at the SunSpider micro-benchmarks than V8. This graph does show V8 cleaning our clock on a couple of recursion-heavy tests. We have a plan, to trace recursion (not just tail recursion). We simply haven't had enough hours in the day to get to it, but it's "next". This reminds me: TraceMonkey is only a few months old, excluding the Tamarin Tracing Nanojit contributed by Adobe (thanks again, Ed and co.!), which we've built on and enhanced with x86-64 support and other fixes. We've developed TraceMonkey in the open the whole way. And we're as fast as V8 on SunSpider! This is not a trivial feat. As we continue to trace unrecorded bytecode and operand combinations, we will only get faster. As we add recursion, trace-wise register allocation, and other optimizations, we will eliminate the losses shown above and improve our ratios linearly across the board, probably by 2 or greater. I'll keep updating the blog every week, as we do this work. Your comments are welcome as always. V8 is great work, very well-engineered, with room to speed up too. (And Chrome looks good to great -- the multi-process architecture is righteous, but you expected no less praise from an old Unix hacker like me.) What spectators have to realize is that this contest is not a playoff where each contending VM is eliminated at any given hype-event point. We believe that Franz&Gal-style tracing has more "headroom" than less aggressively speculative approaches, due to its ability to specialize code, making variables constant and eliminating dead code and conditions at runtime, based on the latent types inherent in almost all JavaScript programs. If we are right, we'll find out over the next weeks and months, and so will you all. Anyway, we're very much in the game and moving fast -- "reports of our death are greatly exaggerated." Stay tuned!

Andreas Gal: TraceMonkey vs V8@Planet Mozilla

Wed, 03 Sep 2008 11:09:00 +0200

Brendan Eich and Mike Shaver have posted an update on our progress on TraceMonkey. There has been a lot of buzz around Google?s new Chrome browsers and its V8 JavaScript VM. Some voices have claimed that V8 is several times faster than TraceMonkey. We did some head to head comparisons and these claims don?t match our observations. We used Apple?s SunSpider benchmarks for our tests. Depending on the OS and machine configuration we are 1.18x to 1.28x faster than V8. Since V8 is only available for Windows, we didn?t perform any tests on MacOSX and Linux, both of which we support already. Our latest builds also work on ARM, by the way. I am sure you can derive different results by tweaking the benchmarks or designing entirely new custom benchmarks alltogether, but since SunSpider has been used fairly intensively in the past two years to measure the evolution of JavaScript performance in Safari, Firefox, Opera, and IE, I think SunSpider is probably the most reliable cross-platform benchmarking tool at this point (which doesn?t say that its a particularly good one, its just the best we have right now.) Talking about IE, our tests also indicate that we are about 15 times faster than IE 7, and about 5 times faster than IE 8 beta on the SunSpider aggregate scores. If you want to give TraceMonkey a try, take a look at our nightly builds. You can enable the JIT in the about:config settings. The nightly builds are certainly not ready yet for wide-spread use, but we have improved stability significantly since our initial preview release. Firefox with TraceMonkey enabled is now my default browser, and I am writing this post with it.

Alex Vincent: Replacing JSLib in Verbosio@Planet Mozilla

Wed, 03 Sep 2008 07:41:26 +0200

I came to an unpleasant decision last week. While working on reorganizing Verbosio's source code, I realized that JSLib should not survive the transition. I didn't really like this very much. JSLib has been useful to me in the past. But when I thought about it, the only thing I used JSLib for was its file I/O utilities. These utilities should be used from chrome (and I abused that in my file search components). Plus, I'm a much more experienced developer than when I first started with Abacus over four years ago. The Mozilla code base has similarly improved, and I just felt I could do the same job I was asking JSLib to do, with less (and cleaner) code. I'm not saying JSLib is a bad library or a bad idea - far from it. I'm saying what I needed from JSLib is too small to justify having it around. Libraries for Mozilla are a popular idea - FUEL, STEEL, and JavaScript modules (.jsm) come to mind. Besides, if you're going to replace a library with one of your own, you should add value (not just cut costs). I decided to write a library that, in theory, would be able to read and write to flat files, zip archives... and zip archives within zip archives. Think JAR files inside a XPI. Then, to make sure that I did it right, I decided to write a xpcshell test case for the module. (Yes, you can do that. The test harness doesn't care whether you're testing components or a .jsm file.) After a couple of days, I came up with FileCommon.jsm and test_FileCommon.js. (The key is in FileCommon.getFile(), near the end. It takes multiple arguments, beginning with the path to a zip archive in the operating system, then an entry inside the zip (which is also a zip), then an entry inside the second zip archive, and so on.) I'm sure there are bugs in this implementation. Right now no code in Verbosio uses it yet, and as I work on replacing JSLib with FileCommon.jsm, I'll continue to add to the module. Eventually, I may make it a standard components module with new interfaces. Like so much else in Verbosio, it's right now a proof-of-concept. With JSLib, the time has come to move on. XUL Widgets will also fade, as I absorb its efforts into the Verbosio project directly. XUL Widgets (and Verbosio) doesn't have any other customers, anyway, so centralizing under one roof makes sense. Thanks for getting me started, Pete.

Daniel Glazman: Webchunks progress@Planet Mozilla

Tue, 02 Sep 2008 19:06:00 +0200

Julio Ernesto Lopez, webmaster of www.criticadigital.com, sent me yesterday a very interesting bug report about webchunks. It's very interesting because it's two bugs in one really, one for my Webchunks extension and one for IE8's implementation of Webslices. On my side, I was incorrectly disabling JavaScript in weslices in some cases and that led to problems with sites populating data from Ajax queries. It took me a few hours yesterday to correctly narrow the bug and find a fix. On IE8's side, I noticed a very visible difference between Webslices' "specification" and IE8's behaviour. I have pinged Microsoft about that. I'll tell you more when I have their reply. So expect a new version of Webchunks to hit addons.mozilla.org in the coming days (addon review needed, it's not a trusted extension yet).

Mitchell Baker: Mozilla, Firefox and Google Chrome@Planet Mozilla

Tue, 02 Sep 2008 19:04:20 +0200

Mozilla exists to build portions of the Internet where individual human benefit, social benefit, and civic benefit are the most important things. We build Firefox explicitly to advance this goal. Mozilla is uniquely suited to doing this. As a non-profit organization we are organized ? legally and logistically ? to do this, and only this. We build Firefox as a first, critical step in this goal. But Firefox isn?t the end goal. The end goal is to create an Internet where all of us can participate, where all of us have the ability to build, where all of us can earn authority, responsibility and decision-making ability. Each one of us will live in a world where our online identity and experience is massive and growing. Each one of us should be able to participate in creating and defining that experience. And to participate in the ways we think are important, not just in the ways someone else offers us. Mozilla recognized long ago that an independent browser dedicated only to the public good is a necessary piece for building a healthy Internet. Many people thought this was silly ? the browser was generally treated as simply a part of the Windows desktop and not important in its own right. These days we know that?s not true. Almost 200 million people have spoken by adopting Firefox; demonstrating how much the browser does matter. Yesterday Google announced that it will release its own browser, validating once again the central idea that this tool we call the browser is fundamentally important. Our first great battle ? that of relevance and acceptance ? has been won. We build Firefox with an open development process. At Mozilla people earn respect, authority and decision-making ability by demonstrating their abilities. This allows individual people to become full, equal participants, with both authority and responsibility for building a better Internet. The development process for Firefox demonstrates the type of Internet we want to build. (Not perfectly, of course.) Firefox is our first step in building this Internet. It?s the demonstration of how to make these goals tangible in a product hundreds of millions of people can enjoy. Firefox is a terrific product and it needs to be. Clearly we need to continue to build great products, and to lead in a competitive environment. Mozilla created this competitive environment through the success of Firefox, and I?m as confident as John is about Mozilla?s future. We?ve already got great things ready for our upcoming 3.1 release, and there?s much more to come. Performance, stability, security, ease of use, features ? it?s a great time in Firefox and browser development in general. We?ll continue to compete in the browser world, and we?ll continue to do well. We?ll continue to produce a product that people choose, and trust and understand is theirs. We?ll continue to do this as part of our overall mission ? building an Internet where individual, civic and social value are paramount. Competition is seldom comfortable, but it forces us to do our best. Firefox 3 is a terrific product and there?s much more to come. We?re just beginning to touch the surface of what Mozilla can accomplish. The best is yet to come. (I?m flying back to California today after a few days of vacation and so unfortunately will be out of touch for parts of the day.)

Robert Kaiser: Weekly Status Report, W35/2008@Planet Mozilla

Tue, 02 Sep 2008 18:44:39 +0200

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 35/2008 (August 25 - 31, 2008): Build System Work: I ported a few build system fixes to comm-central and made relative l10n-base as well as the make install target work again on comm-central. The base for building the Qt port is also laid, and autoconf 2.13 detection should be improved, no need to declare the AUTOCONF environment variable with the usual binary names any more, not even on Debian or ubuntu. I also filed patches to move SeaMonkey-specific security files to comm-central.Code Cleanup: Cleaning up xpfe/ has been completed as far as it can for now, and I also could kill the old chrome registry. Additionally, I filed a patch for eliminating toolkit's mork-based history implementation and a few ones for killing MOZILLA_LOCALE_VERSION.SeaMonkey Releases: I started the release process for SeaMonkey 1.1.12, candidate builds are up, please help testing them so we can catch possible problems before the release, currently scheduled for September 16.SeaMonkey L10n Builds: I worked a long time this week on getting localized builds for SeaMonkey up on our buildbots, and I finally got them to work, see my SeaMonkey trunk L10n builds post in the L10n newsgroup, the localized nightly builds are up for download in the latest-comm-central directory - be aware that download and password managers are still broken, please read the linked post for more details.General L10n Topics: As the current MLP pages are badly outdated, I worked on a replacement page that points to current documents instead, now that we have the www archive which is pointed out in 404 error pages on the live site and will be linked for historical content.German L10n: I updated the German SeaMonkey L10n and German DOMi. Additionally, I checked in a patch for updating de help provided by Michael Opitz, thanks for this!Various Discussions: client.py improvements, compare-locales, drag and drop, SeaMonkey Status Meeting, etc. We're about a week from freezing for SeaMonkey 2 Alpha 1 as well as from the Gecko/Platform 1.9.1 feature freeze, so if you're either working on or watching for some feature that needs to go into the platform for SeaMonkey 2 or are able to work on something that blocks Alpha 1, including any preference panel migration, please try to get the work done until next Tuesday! Also, if you're spotting things in testing that we cannot ship an Alpha with, please nominate those bugs as blocking-seamonkey2.0a1. We are nearing this first Alpha release for SeaMonkey 2, let's make it a good one!

Taras Glek: Converging Elsa Strains@Planet Mozilla

Tue, 02 Sep 2008 18:39:45 +0200

One of the purposes of this blog is to inform people that while the original Elsa author is no longer actively developing it, Elsa is being used in production at Mozilla and is actively maintained within Pork. Recently two previously unknown to me Elsa forks have come to my attention via comments on my blog. Both of these are extrimely cool and something we have been wanting: ellcc C (and soon C++) compiler via Elsa + LLVM. I?ve heard of attempts to get this to work before, but this looks like it is much further along than similar efforts. Alex Telia?s souped up elsa with parser error recovery and an integrated C preprocessor among other awesomeness. See this comment for more details. Some of these tools are built on this Elsa fork. Both of these projects are interested in converging on a single codebase. It sounds like Alex?s work will be ready for merging soon. I love open source. I?m Back Some might?ve noticed that I disappeared off the net for two weeks. I have a good excuse: I was getting married.

Neil Deakin: Drag and Drop is here@Planet Mozilla

Tue, 02 Sep 2008 18:34:04 +0200

Support for the HTML5 drag and drop API is now available in Mozilla nightly builds. This is the API that IE and Safari have supported for a while. Now Firefox will support it as well so you create content in your web pages that can be dragged and dropped elsewhere. The same API is also used for Firefox extensions and XUL applications, however some additional features are available to support dragging non-textual data (such as image data and files) as well as dragging mutliple items. Here is an example of how to make something draggable: This text may be dragged. Documentation is available on how to use this new API, which include a number of examples. Specifically, there is also a guide to dragging specific types of data. This code is new and there are a few bugs reported that will be fixed soon. However, the new API is much easier to use than the old privileged only API. For Firefox extension and XUL application authors, the new drag APIs are what you want to use. Direct use of the nsIDragService or nsIDragSession interfaces is now deprecated. In addition, the nsDragAndDrop.js script is also deprecated. The next step is to implement this API for clipboard operations as well, so that cutting and pasting are just as easy. Then, the old API, and more importantly the very messy code which implements it, could be removed.

Myk Melez: Alt/Cmd+Left/RightArrow brainsprinkling@Planet Mozilla

Tue, 02 Sep 2008 18:02:29 +0200

Recently some folks have been blogging about Ctrl+Tab. It's great to see that shortcut getting love, and it reminds me that there's another one for navigating between pages that could use similar attention: Alt/Cmd+Left/RightArrow for going backwards and forwards through history within a tab.Like the old Ctrl+Tab implementation, Alt/Cmd+Left/RightArrow only lets you move one page at a time, and you can't see where you're going until you get there. And sometimes you land on a page that is the product of a POST request, which you don't know until you are forced by a modal dialog to decide whether or not to resubmit data that you don't get to see when making the decision.We could enable multi-page moves by making the shortcuts work similarly to Alt+Tab in operating systems: holding down the Alt key and pressing a horizontal arrow key would bring up a list of icons representing the pages in the history (perhaps formatted like Alt+Tab in operating systems or via the 3D effect Jono suggested for Ctrl+Tab).Each icon would be a screenshot of the page as it was when you left it, and the adjacent page to the current page would be selected by default. But as long as you held down the Alt key, the list of pages would stay on the screen, and pressing the arrow keys would let you travel back and forth through it. Once you let go of the Alt key, Firefox would switch to the page that was selected at the time.This behavior might also reduce frustrating clicks on posted pages, although the better solution, as Dan Mills recently pointed out in a conversation, would be to stop forcing users to reload pages just to go back (or forward) to them, even if they were the result of a POST.But if we can't do that for some important technical reason, we could at least display a non-interactive and suitably-dressed snapshot of the page and drop down a non-modal notification bar at the top of the tab explaining why we can't provide the page itself and allowing the user to see what they are potentially going to reload.And the list of pages could itself indicate which of its pages are POSTed, thus providing the user two levels of useful indication of what will happen when they try to go back to that page.Of course, there's more to history than the past and future of each individual tab, and pan-tabscape history navigation affordances would also be useful to think through. But there's still a place for a tab-specific interface, given that many such trails represent a specific path through the web with relevance and meaning to the user, so it'd be good to improve the way Alt/Cmd+Left/RightArrow works (or invent even better tab history traversal).Thoughts?

Mozdev: Sysadmin Meeting Minutes for 2008-09-02@Planet Mozilla

Tue, 02 Sep 2008 17:42:20 +0200

Minutes from mozdev sysadmin meeting on Tuesday, September 02, 2008 Participants: davidwboswell (David Boswell), gjm (Gerry Murphy) silfreed (Doug Warner) Community participants: JesperHansen, KaiRo Discussion was held publically in #mozdev Discussed developer priorities see status report Mozdev 8th birthday theme needs worked on; disabling for now Drupal maintenance to get done today Discussed sysadmin priorities phpmyadmin setup; needs additional configuration and lockdown Server migration sethb said to resend our request to him to be safe, but he's just been busy andhasn't gotten to them haven't looked into hardware prices yet for staging server or other rack hardware needed KaiRo said SeaMonkey was donated 2 VMs from Mozilla Cleanup Mozdev CSS JesperHansen mentioned a blog on how to consolidate and compress our CSS/JS pointed to https://www.mozdev.org/bugs/show_bug.cgi?id=18201 for documentation Next meeting September 9th, 2008 @ 15:00 UTC in #mozdev

Mozilla Developer DevNews: about:mozilla - Ubiquity, Fennec, Shredder, Firefox logo, Chrome, upcoming events, and more?@Planet Mozilla

Tue, 02 Sep 2008 17:30:14 +0200

In this issue? Introducing Ubiquity John Lilly: Thoughts on Chrome and more Mobile Firefox ?Fennec? Milestone 7 released Thunderbird ?Shredder? Alpha 2 released Mozilla and certification authorities Defining Firefox logo style Upcoming Events Developer calendar Subscribe to the email newsletter Introducing Ubiquity Mozilla Labs introduced the Ubiquity project last week, an ?experiment into connecting the Web with language in an attempt to find new user interfaces that could make it possible for everyone to do common Web tasks more quickly and easily.? Alongside the announcement, Labs also released an early experimental prototype that demonstrates some of the concepts behind Ubiquity. You can install the prototype, read the tutorial, and learn more about Ubiquity in depth. Further information is available at the Mozilla Labs announcement and Aza Raskin?s weblog. John Lilly: Thoughts on Chrome and more John Lilly, Mozilla?s CEO, writes, ?Interesting developments in the browser world lately. Between the new beta of IE8 and Google releasing the beta of their new browser (called ?Chrome?), not to mention interesting work by the Mozilla team here as well, there?s as much happening as I can ever remember. Let?s start from there: more smart people thinking about ways to make the Web good for normal human beings is good, absolutely. Competition often results in innovation of one sort of another ? in the browser you can see that this is true in spades this year, with huge JavaScript performance increases, security process advances, and user interface breakthroughs. I?d expect that to continue now that Google has thrown their hat in the ring.? Lilly goes on to discuss how the release of Google?s ?Chrome? project affects Mozilla, what this means for Mozilla?s relationship with Google, and how Mozilla continues to be unique in the browser world. ?Mozilla?s mission is to keep the Web open and participatory ? so, uniquely in this market, we?re a public-benefit, non-profit group (Mozilla Corporation is wholly owned by the Mozilla Foundation) with no other agenda or profit motive at all. We?ll continue to be that way, we?ll continue to develop our products and technology in an open, community-based, collaborative way.? Read the full post at Lilly?s blog. Mobile Firefox ?Fennec? Milestone 7 released The Mozilla Mobile team has announced their latest release. ?Fennec (Mobile Firefox) has reached milestone 7 (M7) and can be installed on a Nokia N8�0 for testing. We got some good feedback (and bug reports) from M6, so there are more than a few bug fixes in M7. Other additions include better add-on support, initial kinetic scrolling, modeless password manager, and some zooming tweaks. Please take Fennec M7 for a spin and file some bugs.? The Mobile team has posted install instructions and the M7 Readme, and you can read the full release announcement at Mark Finkle?s weblog. Thunderbird ?Shredder? Alpha 2 released Mozilla Messaging announced the release of Thunderbird ?Shredder? Alpha 2 on August 12th. ?Shredder Alpha 2 is a developer preview release for the next major version of Thunderbird that is built on top of the next generation of Mozilla?s layout engine, Gecko 1.9. Shredder Alpha 2 is being made available for testing purposes only and is intended for developers and our testing community. This release does not represent the final product. Some of the features are highly experimental and will likely change before final release. Please do not use Shredder Alpha 2 in a production environment.? For more information, including further release details, a list of features and enhancements, FAQs, and download links, please see the Shredder Alpha 2 Release Notes. Mozilla and certification authorities Frank Hecker writes, ?Johnathan Nightingale recently addressed a very common question, namely why Firefox doesn?t automatically accept self-signed SSL certificates as being valid. I don?t have much to add to Johnathan?s discussion of the issues with self-signed certificates, but speaking on behalf of the Mozilla Foundation I do want to address some of the comments that I?ve seen people make with regard to SSL certificates, certification authorities (CAs), and Mozilla.? Frank?s blog post discusses some of the misconceptions related to Mozilla and CAs, debunking some of the more commonly repeated myths that exist around this topic. Defining Firefox logo style John Slater and Tara Shahain have been working on developing a new and improved style guide for the Firefox logo. The goal is to refine the existing guidelines and to get those communicated out to the widest possible audience. As part of this project, John and Tara gave a talk at the recent Firefox Plus Summit, and have started working with the Royal Order on creating the guide. They also very much want to keep the process as open as possible, so John will be blogging about various topics for discussion over the next few weeks. Additionally, they have assembled an informal advisory panel for the project, drawing upon the expertise and experience of several veteran members of the Mozilla contributor community. For more information, including a list of the people who are on the advisory panel, see John?s blog post. Upcoming Events Barcelona, Oct 25-26, MozCamp: A large, two-day Mozilla conference being held in Barcelona on the weekend of Oct 25-26, 2008. See the Mozilla Camp Europe wiki page for more information. Paris, Sep 20, Add-ons workshop: A one-day event to bring together French-speaking XUL developers, hackers, and Web developers to discuss Mozilla technologies. See the Mozilla wiki MAOW page for more information. Toronto, Sep 15-16, MozCamp: Two-day developer event full of talks, tutorials, and workshops. See the Toronto MozCamp wiki page for more information. Developer calendar For an up-to-date list of the coming week?s Mozilla project meetings and events, please see the Mozilla Community Calendar wiki page. Subscribe to the email newsletter If you would like to get this newsletter by email, just head on over to the about:mozilla newsletter subscription form. Fresh news, every Tuesday, right to your inbox.

Gervase Markham: Old Reviews@Planet Mozilla

Tue, 02 Sep 2008 16:53:57 +0200

One project I haven't had time to get to this summer is doing something about old reviews. Having old reviews lying around is very bad, because it leads to discouraged new contributors. These are often people who don't know how to make sure the have asked the right person for review, or how to agitate to get their review done. Basically, it would run like this: Allocate a module to each Bugzilla Component Find all reviews older than a certain date in that component Email a link to that list to the module owner The module owner would then be in a position to go through the list and either cancel the reviews, poke the existing reviewer (if still involved in the project), or reassign the review to someone more likely to do it. It's not a magic bullet, but it splits a big hairy problem into smaller chunks and allocates them to the people most likely to be able to do something about them. Stage 1 is the complicated part, and that's where I got stuck (with a proposal to move the Module Owners List to a wiki in order to make it easy to add ancillary data like this). So you'd probably need to write a parser for the HTML version of the Module Owners List (because getting the data out of despot directly is hard). Fortunately, Bugzilla is more obliging for the list of Components. Anyone up for taking this on? You might need to be fairly familiar with the project, in order to do the mapping in stage 1. But perhaps that bit could be crowdsourced.

David Miller: bugzilla.mozilla.org update@Planet Mozilla

Tue, 02 Sep 2008 16:32:08 +0200

On Friday, I pushed a small update to bugzilla.mozilla.org that fixed bug 452799, where users who didn?t have ?canconfirm? privs in Bugzilla were posting bugs that had a status of NEW rather than UNCONFIRMED. This morning, I pushed an update to bugzilla.mozilla.org containing a plethora of additional fixes to address concerns raised since the Bugzilla upgrade.� This morning, we?ve picked up fixes for: Bug 452793: (The other half of the issue which was fixed Friday) The default status selected when you file a new bug and do have ?canconfirm? privs is now NEW instead of UNCONFIRMED. Bug 452810: The wording surrounding the checkbox to add youself to the CC now says ?Add me to the CC list? when you aren?t on it, instead of just ?myself.? Bug 452734: The keyword chooser has been replaced with keyword autocomplete.� NOTE: If you installed the greasemonkey script to remove the keyword chooser, you?ll probably have to remove that script to get the autocomplete, since it hooks on the same event listener. Bug 452798: The CC list is now visible again by default, and as a bonus, it?s now searchable via Firefox?s find-as-you-type feature. Bug 452733: The [Classification] is no longer shown in front of the bug summary. Bug 452746: The link to the bug in the header no longer contains an extra space. Bug 452891: The ?visually jarring? dashed border next to the line numbers in the Diff Viewer has been removed. Bug 452749: The midair page once again specifies who you midaired with. Bug 344559: Add a Commit button near the form fields at the top of the show_bug page so you don?t have to scroll to the bottom of the comments if you?re only changing a field at the top. Fixes for admins: Bug 452898: Milestones can once again be marked inactive. Bug 452914: Multiple problems were fixed in the flag editor related to the ?fixed in version? field not being dealt with correctly on a product change. Hopefully this fixes up some of the more major concerns people had.� There?s still more to come.� At this point I?m plannng on daily pushes to production as the fixes become available. UPDATE: Some people are reporting broken CSS and things looking strange?� hold the Shift key and hit Reload if that?s you.� Your browser is probably caching the old CSS.

Firefox Support Blog: The vision for SUMO ? Part 2: Understanding the bigger picture@Planet Mozilla

Tue, 02 Sep 2008 15:00:22 +0200

A critical piece in having a community-powered project run successfully is that all participants understand the bigger picture. In the case of SUMO, there are actually two pictures, and with part two of this blog series I will try to explain both of them. Picture 1: The truly big picture Looking at how SUMO relates to the rest of the Mozilla project, this could be called the macro version of the bigger picture. This picture was made for a presentation I gave at FOSSCoach (OSCON 2008, Portland, Oregon) and is intentionally a little busy, and friendly. It does highlight some very important things, though: We?re not just helping our users solve their problems with Firefox so they can keep using their favorite browser; we?re here to listen to our users as well. Past readers of this blog series know that part 1 covered exactly this. The data we can gather by looking at stats for the Knowledge Base articles combined with incoming support requests in the Support Forum, Live Chat, letters and e-mails all help painting a better picture of what our top issues in Firefox are. The support and QA teams can work together and combine their findings from channels targeting different types of users and reach a shared understanding of which bugs we should be working on first. Knowing which features and bugs to focus on will be invaluable information for the development team. It will lead to a better product, and a better understanding of what our users want. That?s the most important way support interacts with other parts of the Mozilla project, but far from the only ones. There are other aspects of the bigger picture, for example that the QA and development teams usually have information about known issues prior to releases gathered from the beta testers. This knowledge should be shared with the SUMO team prior to releases, so we can, among other things, prepare for a better support experience for our users. In some cases QA might be working hard to track the cause of a known issue down; if the SUMO community is aware of that bug, they can confirm this with the users reporting it and get a unique chance to do some direct QA testing with a user. People from the QA team could even be logged on to the Live Chat component using a Jabber client of their choice, and the SUMO team could invite a QA tester to a chat session whenever a good chance to solve a known issue comes up. Picture 2: The ?support funnel? This could also be called the micro version of the bigger picture, or the internal picture. As many people are already aware, SUMO is a support project consisting of three major components: the Knowledge Base, the Support Forum, and Live Chat. Many contributors provide support in more than one component. For example, Bo regularly helps out in the Support Forum, but occasionally he also writes Knowledge Base articles for new solutions to Firefox issues. Another example is myles7897, who regularly helps out with Live Chat. Just as Bo, he sometimes writes or edits Knowledge Base articles too. However, not everyone helping out with SUMO will be aware of how the three components relate to each other, or how the site should work for users. The ?support funnel? is a way to describe this: The Knowledge Base should contain the solutions to our most common problems. Users should start by searching for their problem here. Ideally the vast majority of our users find the solution to their problem here; it?s critical both for performance reasons and for quality of support. Using the funnel metaphor, the user would go straight through the funnel without hitting the sides. If they can?t find the solution to their problem in the Knowledge Base, the forum should show if others have already reported the problem. (We?re working on making this step simpler ? more on that later in this series.) If neither the Knowledge Base nor the forum contains the answer, the forum or Live Chat should be available to the user. These two components should be viewed as fallbacks when the Knowledge Base fails to solve the user?s problem. Which of the two fallbacks is best for the user depends on the situation. The forum has the benefit that the posted question is public and can be read by many people, thus increasing the chance of getting answered, while Live Chat offers a direct communication with a Firefox expert, if the user is willing to wait for it. Frequent or serious issues solved in the forum or Live Chat should be documented in the Knowledge Base, to ensure that the support quality and performance remain consistently high, and to allow us to get better data on which issues are the most commonly reported. It?s important that everyone contributing to SUMO has a clear understanding of how the Knowledge Base, the Support Forum, and Live Chat interact and relate to each other. That way we can ensure that the ?support funnel? works. Finally, the insights we will gain can get from this collaboration will be shared with the rest of the Mozilla project as well. A better knowledge of what our users want in our product would be incredibly powerful information to the marketing team, which SUMO is proudly a part of. Similarly, getting better information about what security issues are most commonly reported would likely be valuable for the security team. Et cetera, et cetera; I think I made my point. In other words, support is vital to the success of Mozilla, or any open source project for that matter.

Just Browsing: My Wild Guesses, Speculation and Unfounded Opinions about Google Chrome@Planet Mozilla

Tue, 02 Sep 2008 14:44:38 +0200

September is here, and I?m slipping out of a mild off-season hibernation after a relatively laidback summer (?relative? being the operative word when you?re coming off ten years of stressful startup life). In particular, this blog has been sorely neglected. I?m planning to ramp things up once again, and what better way to start than the announcement of Google Chrome which, if nothing else, heralds a new age of plenty for a browser-focused blog like this one. A Google browser has been rumored for as a long as there have been rumors. Well, not quite that long, but reckoned in internet years it?s been a near eternity since the first whisperings of a ?gBrowser?. Back in January I speculated that Gears had subsumed the role that a fully-fledged browser might have filled: Remember the rumored GBrowser? Well it looks like Google decided instead to build a stack of web application-focused services that run in a range of browsers using plugins or ActiveX. After all, why buy the cow when you can have the milk from all the cows for free? From where I?m sitting this was a very smart decision. Even Google doesn?t have the market power to impose a new browser brand on the world, so supporting third-party browsers is a reality that it has done well to embrace. Oops, I got that one wrong. Google 1, Gertner 0. That said, I retain my scepticism regarding the imposition of a new browser brand. The signature feature of the browser market is that every new personal computer comes with a pretty decent browser pre-installed, so third-party vendors are fighting over the scraps that Microsoft and Apple leave on the table. The genius of Firefox has been its ability, through high-quality engineering and equally impressive marketing, to carve out significant market share despite this. It is far from clear that ?even Google? (to echo the language of my January post) will succeed in doing the same. And if it does, I can?t help but think that this would be bad news for Firefox. This town, so to speak, ain?t big enough for the two of us, sandwiched as it is between the Microsoft and Macintosh metropolises. The good news is that the browser space, already in the throes of a Golden Age of innovation thanks to WebKit, is going to heat up even more. As Mozilla honcho John Lilly puts it: Competition often results in innovation of one sort or another ? in the browser you can see that this is true in spades this year, with huge Javascript performance increases, security process advances, and user interface breakthroughs. I?d expect that to continue now that Google has thrown their hat in the ring. Mozilla makes a lot of the fact that Firefox single-handledly forced Internet Explorer to end its years-long stagnation. Justifiably so, and now WebKit and Google appear to be returning the favor. Firefox has made great strides recently in performance and memory consumption, and a long-overdue Mozilla Mobile effort is now in full swing. Increased competition has been a significant factor in acclerating these efforts. So what about Google Chrome? It?s a no-brainer for Browser of the Week as soon as it?s available for download (later today, supposedly). In the meantime, the only source of detailed information is a sprawling technical treatise-cum-comic book. As an attempt to make dense discussion of process isolation, test-driven design, hidden class transitions and the Biba integrity model more palatable by surrounding it with fun and friendly illustrations of Google engineers, the comic is not entirely unsuccessful. Not that Joe Sixpack will be particularly impressed, I don?t suppose, but it?s a cute way to communicate the key aspects of the browser?s technical architecture and user interface. (But please, please provide a single scrolling page next time.) I didn?t see much in the Chrome technical overview that is truly new. A big deal is made of the fact that each tab is isolated in its own operating system process, but IE8 already does this. Chrome uses the location bar to provide easy access to previously visited sites, which would be more impressive if Firefox 3 hadn?t already launched with the aptly named Awesome Bar. The JavaScript virtual machine with just-in-time compilation and fancy-optimization-tricks-that-I-don?t-really-understand sounds a lot like the Tamarin virtual machine (with equally fancy and, to me, incomprehensible optimization tricks) donated to Mozilla by Adobe. Displaying something useful in newly opened tabs has long been a feature of Opera and was mooted the other day as a possible addition to Firefox by Aza Raskin No single browser has actually implemented and released all of the above-mentioned features, and Chrome could be pretty kick-ass if they pull it all off. But it?s hard to shake the feeling that it would have been a heck of a lot more ground-breaking if it had been released a year ago, before Firefox 3 and the endless string of IE8 betas. Considering the daunting challenge of getting users to switch browsers, this could prove to be of crucial importance. To me, the most interesting question is also the most fundamental: is tab process isolation the future of web browser architectures? Michael Arrington speculates that Google Chrome is a shot across Microsoft?s bow, not an entirely absurd notion. The idea of the browser user interface replacing the operating system desktop has been kicking around since the days of Netscape. I was a proponent of this approach for a long time, but since starting to work on Prism I?m come around to the view that modern desktops are unlikely to be dethroned any time. The fact of the matter is that web browsers are doing double duty nowadays, filling their traditional role of rendering textual pages while hosting applications of ever increasing complexity. Browsers are pretty great for browsing documents, and HTML/JS/Flash-based applications delivered over HTTP have proven to be a great alternative to traditional fat client software. But it?s far from obvious to me that the browser chrome is the best place to deliver web apps. Just because web standards provide an array of compelling advantages for app developers, this doesn?t mean that these apps aren?t best hosted in a modern desktop GUI. This may turn out to be the key to Chrome?s eventual success or failure. Hopefully one of the major browser manufacturers puts its full weight behind a single-site browser offering, and we will be able to witness the two approaches duke it out in the marketplace. (Gosh, I hope my agenda isn?t too transparent!) Unsurprisingly I put my money on SSBs, but either way it will be fun to watch the fireworks.

Myk Melez@Planet Mozilla

Tue, 02 Sep 2008 12:49:11 +0200

A couple weeks ago I blogged about my priorities for the next version of Snowl. I've just uploaded a preview release of the next version to addons.mozilla.org with an initial implementation of a view optimized for short messages and recent updates:The view is implemented as a sidebar that shows short messages (such as from Twitter) in their entirety and displays the subjects of long messages with links to their content. Messages are sorted in the order received, with the most recent ones on top, to make it easy to see the newest stuff at a glance.PlansThere's still plenty of functionality yet to be implemented in the sidebar, including:grouping messages by time period (this morning, yesterday, last week, etc.);making it possible to see some of the content of long messages;an easier way to open and close the sidebar (f.e. a button that toggles it on and off).I also want to improve elements of the visual design. In particular, I'd like to add a subtle but noticeable visual cue that messages have arrived (f.e. making messages slide into place from the top of the sidebar).And I'm still working on implementing message sending and conversations as first-class objects for version 0.2. This preview release is just a taste of the first of several upcoming features.Other ChangesThis release also fixes a number of bugs and makes some improvements to the architecture (there seems to be a neverending supply of such infrastructure work, but it's all necessary to prototype features on top of). And it improves access to Snowl's features via some conventional extension integration points: an item in the Tools menu, an icon on the statusbar.Get Snowl for FirefoxGet the initial prototype: Snowl for Firefox. Warning: the initial prototype is a primitive implementation with many bugs, and subsequent versions will include changes that break functionality and delete all your messages, making you start over from scratch. Get InvolvedLet us know what you think by posting in the forum, reporting bugs, or conversing with us in the #labs channel on irc.mozilla.org. Or check out the source and submit your bug fixes and enhancements.

Gervase Markham: GSoC Wrapped Up@Planet Mozilla

Tue, 02 Sep 2008 12:43:04 +0200

The Mozilla project's Google Summer of Code participation has just finished, with the completion of the last Final Mentor Survey. Nine of our eleven projects were successful, mostly very successful, and I'd like to thank all our hardworking students and mentors.

Daniel Glazman: WebKit winz@Planet Mozilla

Tue, 02 Sep 2008 11:33:00 +0200

After years of "no, no, we're not working on a browser", Google finally announced Google Chrome. And the least I can say is that it caused a little earthquake in the community. Well, not the whole community A few things come to my mind, I'm thinking at loud here. Google has an incredible marketing power. It's one of the most powerful brand on the planet and almost all web users use Google ; the spread of their browser is going to skyrocket... it's based on WebKit and WebKit is gaining market share at an impressive pace. How many iPhones sold in one year again ? WebKit on Mac, on iPhone, on Android, on Windows, on Linux of course ... Wow. mixed feelings at Apple I presume although I doubt they learned about Google Chrome only yesterday. in case you ever wondered why Google hired Ian Hickson to work full-time on HTML 5, do you still wonder ? after HTC using Android, the mobile browser market is even more a battlefield than it used to beOpera should be worried a lot... Fennec (mobile Firefox), Safari and Android. I think their niche market that is also their main market is shaken a lot... unless mobile IE inherits from IE8 and makes major investments on UI, zooming, stability and innovation, it's a dead duck. I don't exactly know where Fennec stands here. It can probably suck the mobileIE market. they have Darin and Ben. I cannot believe they don't have chrome extensibility in mind, and I hope they have it also in the code... I hope they carefully watched Hewitt's and Corey's work on Boxely. I cannot believe a Mac-lover like Ben does not have a nice Mac version with native look&feel ! day 1, Google renews its financial agreement with Mozilla, day 2 they announce their own browser competitor to Firefox and not using Firefox's rendering engine. There is something here we don't know, that's 100% sure. It can be another occurence of the "no evil" motto but it can also be something more concrete and more contractual. Probably both. We'll see, but I will not be surprised if Google and Mozilla are hand in hand here. Netbooks... Google Chrome could become the instant-on desktop for netbooks. There's a whole new market to take out there. "chrome" does matter. But "content" is what web users are looking for on the web. So HTML 5. When ? Done by Google ? The only two concerns with Google Chrome are: WebKit itself. It's now in the hands of so many fiercely competing implementors that forks are probably not avoidable. your search engine is google, your mail is google mail, your docs are on google docs, your maps are google, the ads you see are google, your system is Android, your browser is Google Chrome. Did someone hear the word "monopoly" ? Let's see it from the bright side of life: there's a new OSS and standards-compliant browser and that's good, and there's a high probability Steve Ballmer is currently breaking a few chairs and it's even better

Aza Raskin: Firefox & Google Chrome New Tabs@Planet Mozilla

Tue, 02 Sep 2008 06:24:24 +0200

A number of folks have pointed me to Scott McCloud?s comic debut of Google Chrome today. Scott is one of my personal sources for inspiration: I often peruse his books, looking for insights into creating awesome user experiences. I?m chuffed (and a bit jealous) that the Chrome team got to work with him. There was a particular part of the comic that people kept referring me to: page 21, which talks about the experience for opening a new tab. It?s interesting to see that the Chrome team has been exploring the same thoughts we?re talking about last month here in Mozilla Labs, with Contextual New-Tab Actions, Ambient News, and Auto Dial. Here?s our video and Alex Faaborg?s mockup: And here?s the comic page in question for Chrome: It?s encouraging that there is such a confluence of design?although I felt an odd jolt of d�j� vu the first time I read that panel. Let?s hear it for zero-configuration interfaces!

David Bolter: Google's Browser?@Planet Mozilla

Tue, 02 Sep 2008 05:21:07 +0200

It seems Google has an open source browser project.I believe this must be true because a comic strip on the web told me so. While I was reading this comic I wasn't sure what amazed me more, the interesting things I was learning about the technical design of Chrome (the Browser), or the fact that I was enjoying learning about the technical design of Chrome from comic characters.Is Chrome accessible? Although there was a lot of information about V8, the JavaScript VM, the comic didn't tell me if it had WAI-ARIA support for JavaScript+DOM+CSS based web applications. I was really hoping to see a T.V. Raman, or Charles Chen comic character.Seriously though, it sounds like the rendering is to be done by Webkit, so perhaps too, the exposure of ARIA semantics in the DOM to desktop Accessibility API will eventually come from Webkit. Of course Firefox has pioneered this stuff, but Aaron is helping the other browsers as much as he can. Today, ARIA is a crucial piece of pushing the web as an application platform.Thanks for reading.

Aza Raskin: Ubiquity: Thank You@Planet Mozilla

Tue, 02 Sep 2008 03:19:54 +0200

Last Tuesday, the community working on Ubiquity was five people. Half of us had never met face-to-face, we spanned three continents, and had written a couple dozen commands. Today, our community is thousands strong with contributes in every time zone. Innovation is pouring in from all directions?we?ve had thousands of commands written for Ubiquity; commands that fundamentally enhance the functionality of the browser. In under a week, we have a roughly comparable number of Ubiquity commands as there are Firefox extensions. That?s an amazing achievement. It highlights the power of enabling innovation edges and empowering such a generative community. Wow. Simply wow. And thank you, everyone in the community. We all deserve a giant glass of champagne. Mozilla Labs is a shared space for exploring future user experiences of the open Web. We don?t just have community?we are the community. A number of folks have said that the Ubiquity-style interaction heralds the beginning of Web 3.0. While that?s a bit too buzz-wordy for our tastes, with over a hundred thousand users, we do have a critical mass; one that that begins to shift the web from being site-centric to being task-centric. Update This weekend, the community was able to push out Ubiquity 0.1.1. You?ll be updated automatically if you?ve already installed Ubiquity; otherwise, you can get the latest version here. Expect some major upgrades to the the Herd?Ubiquity?s command finder and dashboard service soon. Some Links To Awesomeness There has been too much awesomeness created by everyone in the community to highlight it all. I?ll call out just a spattering: There is Lani Anglin-Rosales?s Top 35 Ubiquity Commands; Leslie Orchard?s walkthrough for creating a Delicious Ubiquity command; and Waleed Zuberi?s super-useful Ping.fm command. There?s Vladimir Prelovac?s open command, which shows how Ubiquity can be used to interact with the page?s current context; and, Robert Chen?s Xkcd command. Because, who doesn?t want the instant ability to insert obligatory Xkcd references. (Now, if it only let me insert the actually comic image instead of a link to one.) Yatrik Solanki has done some wonderful design work and has turned us onto enabling skinning support for Ubiquity. Abi Raja?s has made the excellent Keyscape which shows how Ubiquity can be used to write full-featured Firefox extensions. He?s also put out an amazing hack to enable command chaining. (Abi is one of the five original virtual team members.) Finally, Skumleren.net has made some scientific ubiquity commands. I have a soft-spot in my heart for beautifully typeset equations. It?s my math and physics background, I?m sure. But it makes me knees weak. I?m looking forward to being able to plot from inside Ubiquity. If others have contributions they?d like to call out, put them in the comments section or blog about them.

Chris Blizzard: initial thoughts on google chrome@Planet Mozilla

Tue, 02 Sep 2008 02:05:32 +0200

Google chrome is public and I thought I would write up some initial thinking on it as it affects the world that I live in. I love what google chrome represents. The work that we?ve been doing inside of the Mozilla project over the last ten years has really paid off. The fact that Google believes that they can launch a browser based on new technology means that the market is alive. Apple is making releases, Mozilla is making releases, even big slow Microsoft is making releases. The rate of browser releases is getting faster, not slower. Google?s browser beta is a sign of health. JavaScript is evolving and being seen as a general purpose language. People are already embedding SpiderMonkey into a lot of other apps. The work that Mozilla has been doing on JavaScript performance with TraceMonkey and Google has been doing with V8 means that it can reach more and more use cases. It?s also great to see the end user features flowing from browser to browser. The malware/phishing stuff mentioned in the comic is already shipping in Firefox 3. JS performance is something that everyone is working on. Inside of Mozilla we?ve been talking about the multi-process model that they have decided to use in order to get proper rights mgmt on the mac and windows. IE is including some of these random features in IE8 and we?ll be including a lot of them as well in Firefox 3.x. Two items that come to mind are worker threads and geolocation, features that are already undergoing testing as part of the Firefox 3.1 work. The fact that everyone is sharing ideas and moving along the same lines is great for users and great for the web. It?s starting to feel like a healthy economy of ideas. We haven?t seen the browser itself yet. So I?ll wait until they actually get code and downloads up to comment on any of that. Given some of the features that are featured in the comic book, it will be interesting to see what the role of data and privacy will be in the product. But more on that once they actually put up something for people to play with. As a side note, the comic is a great piece of storytelling and outbound marketing. Tells you everything you need to know to re-tell the Google Chrome story to other people without any of the drudgery of a spec or product sheet. For those of us who are interested in how things are sold and marketed, it?s a great piece of work.

John Lilly: Thoughts on Chrome & More@Planet Mozilla

Tue, 02 Sep 2008 00:45:12 +0200

Interesting developments in the browser world lately. Between the new beta of IE8 and Google releasing the beta of their new browser (called ?Chrome?), not to mention interesting work by the Mozilla team here as well, there?s as much happening as I can ever remember. Let?s start from there: more smart people thinking about ways to make the Web good for normal human beings is good, absolutely. Competition often results in innovation of one sort or another ? in the browser you can see that this is true in spades this year, with huge Javascript performance increases, security process advances, and user interface breakthroughs. I?d expect that to continue now that Google has thrown their hat in the ring. It should come as no real surprise that Google has done something here ? their business is the web, and they?ve got clear opinions on how things should be, and smart people thinking about how to make things better. Chrome will be a browser optimized for the things that they see as important, and it?ll be interesting to see how it evolves. Having said that, it?s worth addressing a couple of questions that folks will no doubt have. 1. How does this affect Mozilla? As much as anything else, it?ll mean there?s another interesting browser that users can choose. With IE, Firefox, Safari, Opera, etc ? there?s been competition for a while now, and this increases that. So it means that more than ever, we need to build software that people care about and love. Firefox is good now, and will keep on getting better. 2. What does this mean for Mozilla?s relationship with Google? Mozilla and Google have always been different organizations, with different missions, reasons for existing, and ways of doing things. I think both organizations have done much over the last few years to improve and open the Web, and we?ve had very good collaborations that include the technical, product, and financial. On the technical side of things, we?ve collaborated most recently on Breakpad, the system we use for crash reports ? stuff like that will continue. On the product front, we?ve worked with them to implement best-in-class anti-phishing and anti-malware that we?ve built into Firefox, and looks like they?re building into Chrome. On the financial front, as has been reported lately, we?ve just renewed our economic arrangement with them through November 2011, which means a lot for our ability to continue to invest in Firefox and in new things like mobile and services. So all those aligned efforts should continue. And similarly, the parts where we?re different, with different missions, will continue to be separate. Mozilla?s mission is to keep the Web open and participatory ? so, uniquely in this market, we?re a public-benefit, non-profit group (Mozilla Corporation is wholly owned by the Mozilla Foundation) with no other agenda or profit motive at all. We?ll continue to be that way, we?ll continue to develop our products & technology in an open, community-based, collaborative way. With that backdrop, it?ll be interesting to see what happens over the coming months and years. I personally think Firefox 3 is an incredibly great browser ? the best anywhere ? and we?re seeing millions of people start using it every month. It?s based on technology that shows incredible compatibility across the broad web ? technology that?s been tweaked and improved over a period of years. And we?ve got a truckload of great stuff queued up for Firefox 3.1 and beyond ? things like open video and an amazing next-generation Javascript engine (TraceMonkey) for 3.1, to name a couple. And beyond that, lots of breakthroughs like Weave, Ubiquity, and Firefox Mobile. And even more that are unpredictable ? the strength of Mozilla has always come from the community that?s built it, from core code to the thousands of extensions that are available for Firefox. So even in a more competitive environment than ever, I?m very optimistic about the future of Mozilla and the future of the open Web.

Al Billings: Google Chrome is the new black?@Planet Mozilla

Mon, 01 Sep 2008 23:51:39 +0200

Apparently, Google is going to release a web browser based on Webkit sometime in the near future. It is called ?Chrome.? While the browser is not available yet, a web comic, drawn by Scott McCloud was accidentally placed online early and then found by people (as an aside, I?ve seen this kind of thing bite a lot of projects in the ass before). You can see the entire comic at http://blogoscoped.com/google-chrome/ (if the server has come back up). I?ve also made a version of it available in a .cbz comic book file at http://www.mediafire.com/?sct1crovjdj. CBZ files are simply zip files containing images for use in reading comic books on computers. If you don?t have a computer comic book reader program, you can just unzip the file and look at the numbered images in order in the file. This page details some of the promised features mentioned in the comic but you can read it for yourself. TechCrunch also has a post on this Google browser as well. Not having seen this browser yet (no one outside Google has, I would guess), it is hard to give an opinion on it. Generally, as long as things are standards based so we don?t have to write some specialized version of web pages for a browser, I?m in the ?the more, the merrier? camp, especially if it turns out to be entirely open source. Since they are using WebKit as the rendering engine for it, I expect that it will render pages as well (or as badly) as Safari does. Once I actually get a chance to play with it, I expect that I will have opinions about the specific Chrome features and whether they live up to their promises. I am kind of surprised that they used a web comic to explain the browser though. Most people would just write a simple web page or something. I?m not sure if this is a cool idea or just kind of a dumb one. Reactions will obviously vary. :-) Update: Just as I posted this, the Google Blog put up a post on their new browser. They are launching a Windows-only beta for it on September 2 (tomorrow). This work is licensed under a Creative Commons License..

Robert Accettura: Google Browser Is Now Google Chrome@Planet Mozilla

Mon, 01 Sep 2008 21:47:31 +0200

I?ve mentioned the long fabled Google browser for ages now ?googlefox? as it began. Some more interesting news came today regarding ?Google Chrome?. Some of the features touted by the comic include: faster - mentioned throughout via new js virtual machine (might be SquirrelFish) that?s potentially embeddable into other applications and using WebKit. Also multi-threaded. More Stable - Separate process for each tab means one page doesn?t crash the browser. Also more memory efficient in the long run since you?ll kill tabs that hog memory at some point. UI - UI is minimal, tabs contain the controls (tabs on outside), are detachable from the window, and similar to Prism can be minimal enough to make a web application feel like it?s not in a browser. Omnibox (awsomebar equivalent), auto complete only to what you?ve explicitly typed before, improved new tab screen (similar to others proposed and implemented). Secure - Sandboxes processes (sounds like the work from GreenBorder), plugins running in their own processes, phishing protection. Also has porn privacy mode. Compatible - Based on WebKit, automated testing via ?chrome bot? browsing pages, unit tested, fuzz tested. Google Gears Included - Includes Google Gears, which is downloadable for other browsers already. Also interesting were some of the names mentioned in the comic. While long known a few Mozilla hackers went to Google, here?s a list that are mentioned in the comic: Darin Fisher, Ben Goodger, Brett Wilson (various Mozilla contributions via Google), Arnaud Weber (Netscape). Check the comic for more details. This is pretty much the main info in there for those who don?t have the time to sift through it all.

Robert Accettura: Google Browser Redux II@Planet Mozilla

Mon, 01 Sep 2008 21:40:59 +0200

Majken "Lucy" Connor: It was a very good year@Planet Mozilla

Mon, 01 Sep 2008 19:31:22 +0200

I?ve very much enjoyed this past year and my role as the Live Chat community lead. It?s been a very cool experience helping establish a new project with a new team, especially one that so directly impacts users. We saw incredible turn out and some really great feedback when we launched last December. Since then we?ve made several changes to improve the process. The software that we?re using which was partially open source when we chose it has no been fully opened and now the possibilities for making the improvements we?ve wanted to are very exciting. We?ve also been through a release and a major update and it was really great working with other contributors to help so many people experience Firefox 3 properly. I can?t wait to see what will happen with Live Chat in the coming year! Working on Live Chat has also given me a chance to develop my skills and get a feel for what types of tasks I really love. I really love helping people and interacting with them. Being able to help someone do what they?re trying to do is always a great feeling. I think my favorite project though was organizing the June Support Firefox Day. All in all I think my favorite parts have all been the ones that involved working with other people to do some awesome things. Working with Jason, Chris and David has been a great experience. While support is very dear to my heart, that?s been my major role in the Mozilla community to date. I have some opportunities to pursue projects that involve doing some other things that I love and hone some skills that I?ve had fewer chances to use in my current role. I?m definitely going to stay as involved with support as I can, but I?m also going to enjoy letting someone else take the leadership role with Live Chat and seeing what they can do with it. Look for an announcement soon on who?s taking over!

John Resig: Google Chrome Process Manager@Planet Mozilla

Mon, 01 Sep 2008 19:27:22 +0200

About the just-leaked Google Chrome browser: Google also say they?re using a ?multi-process design? which they say means ?a bit more memory up front? but over time also ?less memory bloat.? When web pages or plug-ins do use a lot of memory, you can spot them in Chrome?s task manager, ?placing blame where blame belongs.? If this is true and there's a process manager which allows you to see how many resources are being consumed by a particular browser tab (including plugins!) this will be a 100% killer browser feature. It simply isn't possible to implement with current browser architectures which brings up two points: 1) Browsers haven't tackled it due to the extreme amount of code rewrite that it would cause and 2) that there's a general consensus that this architecture will actually consume more resources than the current architectures. This is important. Since there's no sharing going on between the tabs of the browser it's not possible to easily reduce the amount of duplicate resources. For example, within the Mozilla Gecko engine there's a lot of code reuse occurring, which allows for significantly reduced memory consumption (and optimized memory collection and defragmentation). But here's the rub. The blame of bad performance or memory consumption no longer lies with the browser but with the site. By implementing this feature a browser is completely deflecting all memory or performance criticism off to individual site owners ("Yikes, my browser is using 300MB of memory! Actually it's just youtube.com consuming 290MB of it, they should fix their web site!"). This is going to be a monumental shift in the responsibilities of web developers - and one that will serve the web better, as a whole. Of course there will still be overhead associated with the core browser - but, presumably, this will be marginalized. This is an incredibly devious (in the best sense of the word) tactic and it's one that browser vendors will be forced to respond to. How the response will occur is another matter entirely. Once the response occurs, though, two things will happen: Browsers will begin to compete on reducing specific memory/performance numbers for specific sites (it happens now - but with the numbers made obvious users will beg for it) and browsers will be enticed to lie. Since the browser is the new harbinger of the de-facto "accurate performance metrics" (it's no longer the Window Process Manager, for example) they'll have to take every opportunity to exaggerate those number to their benefit. On so many levels this new feature will change the way browsers are constructed and how they communicate to the user. Even if Google Chrome launch does nothing but fall off the end of the runway in a fiery explosion, users will be intrigued, and the seed will be planted: Browsers must find a way to respond.

Brian King: Firefox Extensions to Save the World@Planet Mozilla

Mon, 01 Sep 2008 16:45:03 +0200

Image by carf via Flickr A dramatic title for a post I know, but Joe Solomon and other folks think that Add-ons have enormous potential for social change. A recent example is the KnowMore extension whick alerts you when you visit corporate sites to inform you of their environmental and social record. Quite frankly, every time I visit apple.com it makes me feel guilty about having their products! You can show your support, here?s how: Vote for Joe?s panel at SXSW 09 Join the Firefox Extensions for Social Change Facebook group Write your own extension I?m interested in the broader discussion on how Firefox as a whole and the Mozilla project can be an agent for change. This is something that was brought up quite a bit at the Firefox Summit. Mozilla, with it?s roots deep in the Open Source ethos, and not being controlled by a traditional corporate entity like the other major browsers, has a unique opportunity to lead the way here. Please let me know of any other add-ons you think fit into this category. Related articles by Zemanta How to Start a Movement in 7 Easy Steps

European Mozilla Community Blog: Interviewing Mozilla@Planet Mozilla

Mon, 01 Sep 2008 14:37:00 +0200

Last FOSDEM, Mozilla Hispano's members decided to interview in video some Mozilla members to show Spanish users the face of Mozilla. Because our community is focused on non-English speakers, we had to subtitle all the interviews in Spanish, a work that was delayed because of the Firefox 3 release and other Mozilla related stuff. Fortunately, the Mozilla Europe interns Andr� and Delphine worked with us correcting our transcription and doing the subtitle synchronization. Finally we have created and uploaded these video-interviews to our portal. You can see them in English with Spanish subtitles, but they are open to other communities. Andr� and Delphine were doing the French subtitles. We'll try not to delay this kind of things in the future Watch the interviews.

Gervase Markham: Expiry Canary@Planet Mozilla

Mon, 01 Sep 2008 13:41:40 +0200

Expiry Canary is a Firefox 3 or SeaMonkey 2 add-on to warn you about certificates which are about to expire. You can alter the warning period and the sites on which it activates, allowing site admins to have a backstop warning about certificate expiry and prevent embarrassing accidents (Google, Yahoo, LinkedIn). You can find it in the sandbox on addons.mozilla.org for Firefox 3 or Seamonkey 2. Please add feedback :-)

Gervase Markham: Thoughts On Bug Volume@Planet Mozilla

Mon, 01 Sep 2008 11:48:06 +0200

The Mozilla project is groaning under the load of incoming bugs (see this thread in the newsgroups for some info and stats). Firefox is, I assert, not getting any more buggy (if anything, it's getting less so), and yet the number of bugs filed is going up and up. It may well therefore be that a greater percentage of bugs filed are not actually useful to us. There's a good chance that any one particular filed bug is actually a bad thing - that is, its existence has a negative impact on the project. Each filed bug takes valuable contributor and/or developer time to triage and assess. If a layout developer spends 20 minutes looking into bug A and finding it's a duplicate of bug B, he's just acquired a small bit of information ("bug B may be more common than I thought") at a very high cost. The time of layout developers is very valuable - there aren't many of them. More bugs is not necessarily a good thing. Bugs reduce bugzilla.mozilla.org performance, they clog up searches, they inflate numbers (which depresses people) and they tempt people to spend time looking at them. So as a first step, let's move away from the idea that every incoming bug report is valuable in and of itself, and we have to feel guilty if we don't do anything with it. After all, we've already done this for broken website reports and crashes - all the reports go into Reporter and the crashes into Breakpad, but we aggregate them and look at the most frequent. That means that the reports of some people with rare crashes or with problems on not-popular websites will never be considered at all. No-one suggests that we are telling the reporters of such problems that they are not valuable because we do nothing with their information. So why should this be true of other bug types? Ignoring a bug is not a statement about the personal worth of the person who filed it. We need to figure out where the greatest concentration of value is and focus on extracting it, rather than trying to answer the question "how do we extract all the value?" Trying to get everything is a Herculean task which will result in miserable and burned-out QA people. So how do we extract the most value for the least effort? Firstly, we need to make sure that everyone with a problem ends up in the right place. There are lots of different places they might need to be: Bugzilla Hendrix Broken Website Reporter SUMO MozillaZine Forums Support Newsgroups/Mailing Lists We need to figure out what the right places are and who needs to go to them when. E.g. when should someone be sent to SUMO, and when to the MozillaZine Forums, and when to the support newsgroups? Do we need to close or deprecate one or more of these support mechanisms in order to pool resources and have a consistent story? Or do they in fact serve different constituencies? If so, what words will direct people to the right one? One suggestion would be have a well-known URL which explains what options there are, and why you might want each of them, and make sure everyone always links to that rather than any of the individual tools. The top of the front page of Hendrix or of b.m.o. actually looks a little bit like what such a page might be. This not only benefits the people with a problem, but it benefits us, because we won't get support requests in Bugzilla or bug reports in SUMO. Once we've done that, there are several things we could do to cut down the flow of incoming bugs: Reduce the number of people who turn up to file (make the bug reporting mechanism harder to find, or direct people elsewhere) Reduce the conversion rate (i.e. scare people off during the process) Get more aggressive about resolving bugs INCOMPLETE Find a way to aggregate general bugs automatically Ignore more bugs (sort of what we are doing now) I'm sure there are more things than that. The question is: which of these will be most effective at retaining the valuable and discarding the less valuable? Different options will bias the bug filing process so that different sorts of people are more likely to be successful. For example, option 1) favours the inquisitive. Here's an important observation. Option 2) favours the persistent. If there is a correlation between that personality trait and bug quality - i.e. persistent people make better bug filers - then making the bug filing process easier to understand might actually be a bad move for the project. This seems counter-intuitive, but I think we need to grasp the idea that if there's one resource that's plentiful here, it's the time of bug filers. And so optimising the process for their time, rather than QA time or developer time, is counter-productive. If it turns out that we can make all bug reports 10% better by adding another five compulsory questions to the Bugzilla Helper (for example) then that would be a good thing. Fewer bugs, better quality. (I'm not saying this is actually true - it's a hypothetical.) These are only some initial thoughts for discussion. This issue really needs a champion - someone who can look at all the possibilities, do some research and come up with a well-justified plan. Such a person would, I'm sure, be showered with thanks and praises by the whole community. I'm afraid I don't have time. Do you?