November 07, 2009
Vladimir Vukicevic -- CanvasArrayBuffer and Canvas*Array
WebGL introduces two interesting concepts that I think have application outside of WebGL, the CanvasArrayBuffer and CanvasArray. This is all subject to change, of course, though this is what the current Gecko (and others') implementation looks like. In particular, the Canvas prefix in the names might change soon.
It became clear that pure JS arrays are not a useful way of shoveling around lots of 3D data; their very flexibility makes them impractical for performance-critical uses. In particular, WebGL often wants to deal with arrays of a specific type -- an array of integers, an array of floats, etc. Even more complicated is the need to manage multiple types within a single memory region; for performance, it's often preferable to allocate one chunk of video memory, and place coordinates, colors, and other types in there, replacing them as necessary.
There are two portions to the solution: the CanvasArrayBuffer and a set of typed CanvasArray views. A CanvasArrayBuffer represents chunk of data. It can be allocated with a size in bytes, but it can't be accessed in any way. To actually manipulate the data inside a CanvasArrayBuffer, a CanvasArray has to be created that references it. An example:
var buf = new CanvasArrayBuffer(3*4); var floats = new CanvasFloatArray(buf); floats[0] = 12.3; floats[1] = 23.4; floats[2] = 34.5;
The above chunk of code allocates a 12-byte CanvasArrayBuffer, and then creates a float-typed view onto the buffer which can then be manipulated (almost) like a normal array. Of course, the above is cumbersome to write, so there are shorthands that will allocate a CanvasArrayBuffer, and optionally fill it with data from a JS array:
var f1 = new CanvasFloatArray(3); var f2 = new CanvasFloatArray([12.3, 23.4, 34.5]);
The size of each CanvasArrayBuffer is fixed; there is currently no way to change its size once allocated.
Multiple CanvasArrays can reference the same CanvasArrayBuffer. For example:
var buf = new CanvasArrayBuffer(12*3*4+12*4); var points = new CanvasFloatArray(buf, 0, 12*3); var colors = new CanvasUnsignedByteArray(buf, 12*3*4, 12*4);
This creates a buffer of 192 bytes, which is enough room for 12 3-coordinate float points followed by 12 RGBA colors, with each component represented as an unsigned byte. The arguments to the CanvasArray constructors are the offset from the start of the buffer (in bytes), and the length (in elements). The offset must always be a multiple of the element size (to preserve alignment), and the buffer must obviously be large enough for the given offset and length. If length is not given, the length is assumed to be "from offset until the end of the array buffer"; that value must be a multiple of the element size. If offset is not given, it's assumed to be zero.
For extra complex use cases, CanvasArrays can reference overlapping regions of a CanvasArrayBuffer:
var buf = new CanvasArrayBuffer(192); // same value from above var points = new CanvasFloatArray(buf); var colors = new CanvasUnsignedByteArray(buf); points[0] = 12.3; points[1] = 23.4; points[2] = 34.5; colors[12] = 0xff; colors[13] = 0xaa; colors[14] = 0x00; colors[15] = 0x00;
In the buffer, this writes 3 float values followed by 4 byte values. You'll note that this use is significantly more complex, and requires the user to keep track of the current position in terms of whatever element they're modifying (thus setting array elements 12, 13, 14, and 15 for the color).
If an attempt is made to store data in a CanvasArray that doesn't fit within the right type, a C-style cast is performed. If the data is an entirely wrong type (e.g. trying to store a string or an object), Gecko currently throws an exception, but this might become a silent 0 or similar in the future.
Where does this fit in WebGL? Any API function that needs an array of data takes a CanvasArrayBuffer. This avoids placing costly JS array type conversion in a potential critical performance path, and simplifies a number of aspects of the API. So, VBOs, texture data (if not loaded from a DOM image element or from a CanvasImageData object), index array, etc. all use CanvasArrayBuffers/CanvasArrays for pulling data in and out. CanvasArrays also help manage memory usage -- an array of byte color data now takes up exactly as much memory as needed, instead of getting expanded out to 4 bytes. Also, critically, floating point data can be stored as 32-bit single-precision floats instead of 64-bit doubles, taking up half as much space when the underlying graphics system can't support 64-bit values.
This API is overall lacking in developer niceties, since the focus was on providing the necessary functionality. Higher level wrappers can be written in JS to simplify usage. In addition, by keeping it as bare-bones as it is, it allows for fast implementation on native hardware via the JITs in all the current-generation JS engines. The web currently fudges around the problem of binary data by passing it around either in strings (because JS strings are UCS2, therefore all 8-bit elements are valid, but with a performance and memeory cost), or often encoding as base64 (again going back to strings). I can see this type of dense/native type access being useful for both the File and WebSockets APIs as a way to exchange and deal with binary data.
November 07, 2009 12:30 AM
November 06, 2009
Asa Dotzler -- firefox and facebook users
Just an observation: Firefox and Facebook have pretty much the same number of users.
November 06, 2009 06:05 PM
Gervase Markham -- Gerv Status 2009-11-06
For those of you waiting for the official release of Bugzilla API 0.2: it's still blocked on getting some small support patches on to bugzilla-stage-tip.mozilla.org or bugzilla.mozilla.org. Despite my begging and pleading, it's looking like this won't happen until the upgrade to Bugzilla 3.4, which keeps getting postponed :-(
November 06, 2009 05:24 PM
November 05, 2009
L. David Baron -- Distributed Extensibility
There's been a debate in the HTML Working Group on distributed extensibility; this led to a session at the Technical Plenary yesterday (and, for me, an interesting lunch discussion afterwards that led me to think about issues I hadn't before thought much about). One issue in that debate is that some people see the debate as a debate specifically about whether to use XML namespaces and some see it as a debate about extensibility in general.
I've come to accept that extensibility has positive value, and that the risk of open platforms having proprietary extensions is outweighed by the risk of stagnation and the benefits of adopting extensions into the platform. The value of openness just needs to stand on its own: people can choose open extensions over proprietary ones, just like they can choose an open core over a proprietary one. (This has similarities to the open source vs. free software debate.)
However, I think XML namespaces have some problems as an extension mechanism. One of the reasons I don't like them is that they're hard to use: people have to remember obscure namespace URIs, which makes markup harder to write. Another is that namespaces can encourage not-invented-here syndrome: they encourage extensions to be complete pieces rather than reusing as many pieces of the core as possible, since once you're writing a subtree in a different namespace, it's easier to use elements in that namespace and it's extra work to switch back into the core namespace. Thus they can encourage extensions to extend more than necessary.
Accepting that extension mechanisms are good doesn't necessarily mean their value exceeds their costs; extension mechanisms, especially in software, can be quite costly. In software, large portions of the cost of extensibility is borne by the core, but it's not clear that's also the case for standards.
November 05, 2009 08:05 PM
Gervase Markham -- Pongo: Guerilla Usability Lab
Someone added a comment to a previous blog post about this, but I think it deserves some wider publicity - particularly as I commented on the need for this sort of thing in mpt's usability talk at LUGRadio Live.
Pongo is a poor man's usability lab - it records the screen, the mic and the webcam and wraps them all up into an Ogg file for review. Here's the original blog post from the author (the original was in Python, but it got ported to C).
If there are usability people who could pick this up and take it a bit further, e.g. to the stage of being packaged for Debian and Ubuntu, that would be amazing.
November 05, 2009 03:00 PM
SeaMonkey Team -- SeaMonkey 2 contributor interviews: InvisibleSmiley
It's Wednesday, and with that, time for another post in the ongoing series of SeaMonkey 2 contributor intereviews! This time, we'll continue with a guy who's known on IRC as InvisibleSmiley:
Who are you?
I'm Jens Hatlak, German/Austrian, single, located in Frankfurt, Germany, and still on the better side of 30. :-) I've been working as a PHP web developer for a large logistics company since I left university (computer science, TU Darmstadt) in 2007.
I chose my nickname, InvisibleSmiley, because I think it's funny to tell people that's what they missed when someone made a statement with hidden irony. ;-)
I like to play the piano, although I'm not especially good at it. I'm a good swimmer, though, a science fiction fan, and a grammar guru (avoiding the more popular alternative term here for hopefully obvious reasons).
How did you become a SeaMonkey contributor?
I started using Mozilla when it was still in the Milestone phase (around 2000), so I was a beta tester almost from the beginning, but only watching the game back then.
In 2001 I made my first Bugzilla comment and filed an enhancement bug (still open!). I also started university that year where I joined a group of system administrators responsible for the computers of the computer science department (some thousand students). After some time I took over the responsibility of not only the web server but also parts of the software installation, including Mozilla (later also Firefox, Thunderbird, and SeaMonkey), all on Sparc/Solaris. During that time I learned how to compile software from source under difficult conditions and how to write patches. However I was still not actively contributing code. Even when I worked on MozPETs I sticked to what I knew (compiling ) instead of diving into extension development and trying to understand the basic principles like XUL.
I kept using SeaMonkey when Mozilla decided to drop the suite, staying on the bleeding edge (nightly builds). When MozillaNews went on hiatus (and with it its Bonsai Watch bug tracker) I started to track SeaMonkey-affecting bugs myself, just out of interest. At some point in time I decided to push the results to a place where I (and others) could find and search them: The SeaMonkey Trunk Tracker was born. I learned how to build SeaMonkey on Windows and updated my public build instructions, but other than that I just watched development progress.
My active participation in SeaMonkey development started only last year, in October 2008 (funnily by posting a patch one minute after another developer submitted almost exactly the same), when the code had already moved to Mercurial. I was surprised by the fact that simple changes and corrections were much easier to accomplish than I had thought, so I continued to contribute small patches. The rest is history . :-)
What notable contribution did you make to SeaMonkey 2.0?
I must have touched almost all parts of the UI by now... Let's see.
- fixing Get All Messages (my only trip to C++ land)
- improving the Cookie Manager (making it searchable, among other things)
- adding the ability to delete bookmarks from search results (and working with Neil to make sure deleted bookmarks do not show up there anymore)
- writing several new or updated Help articles
- adding support for more Firefox-compatible command-line options
- adding UI for the MailNews Archive functionality
- supporting standard key and double click events in the new Download Manager
- adding support for multimedia keyboards to MailNews
- porting the Master Password workaround in time for SeaMonkey 2.0
This may look like much (and it's certainly not few) but it's nothing compared to what people like Neil contributed in the same period of time: just think of all the reviews he made! Respect.
Beyond that I looked into making some popular extensions compatible with SeaMonkey 2, i.e. ones that need more than just a version bump. So far I have been successful with Nostalgy, Flat Bookmark Editing, Download Statusbar, and Firebug (yes, that's right!). I hope the latter can be fixed at the source, the others should appear at the xSidebar site sooner or later.
How can users give something back to you?
I don't know, maybe a bar of good chocolate? :-)
Seriously, my personal needs aside I'd like to see more people getting involved in the project. If you are maintaining an add-on (extension or theme), now would be a fine time to make it SeaMonkey 2.0 compatible. But coding is only part of it, so if you feel like you should give something back, you could help with marketing, quality assurance (e.g. organizing bug days), design (especially icons!), featured articles (e.g. blog posts with screen shots or videos) or even usability considerations. Helping other people in fora and newsgroups is also appreciated, of course. :-)
Oh, and if people would stop mistaking "it's" for "its" that would be nice, it hurts my eyes. :-P
Why, in your eyes, should people use SeaMonkey 2.0?
Because it has everything you need in one place. I think it's the combination of browser and MailNews that I like best but I've learned that people have different reasons for using SeaMonkey, and all of them are valid. I'm not saying that everyone should use SeaMonkey, though; in fact I tell people who really want to use just a browser to use Firefox instead if they feel comfortable with it. In the end it's just a matter of personal preference.
What next step do you see for SeaMonkey, and what would you like to happen in the Mozilla and SeaMonkey projects?
In the imminent future I think we need to concentrate on getting it right, i.e. fixing the most evident problems people have with SeaMonkey 2.0 (like the recurring high CPU load issue). The next step is to make use of more Toolkit features like the Places back-end for bookmarks which will enable syncing bookmarks with Weave, and to foster integration (Lightning, KompoZer; maybe instant messaging?). In the more distant future we'll have to keep an eye on what people expect from a modern Internet application and cautiously make the necessary adjustments.
What I would like to see is an evolution of usability (supporting the user's work flow), and an improved collaboration of Mozilla projects. The comm projects (Thunderbird, SeaMonkey and Calendar) are already cooperating quite nicely but I think there's room for improvement elsewhere.
November 05, 2009 12:20 AM
November 03, 2009
Asa Dotzler -- i have a beard again
A couple of people who see me regularly in person noted that my profile photo and other photos of me around the Web are a bit misleading because I've been sporting a full beard for the better part of this year. It probably won't survive 2009, but that's no reason not to share, so here's a quick iPhone snapshot that my friend Rey took.

It's getting a little bit (some might say that's not emphatic enough) out of control but I'm kinda digging it.
November 03, 2009 10:36 PM
Eric Meyer -- Pseudo-Phantoms
In the course of a recent debugging session, I discovered a limitation of web inspectors (Firebug, Dragonfly, Safari’s Web Inspector, et al.) that I hadn’t quite grasped before: they don’t show pseudo-elements and they’re not so great with pseudo-classes. There’s one semi-exception to this rule, which is Internet Explorer 8’s built-in Developer Tool. It shows pseudo-elements just fine.
Here’s an example of what I’m talking about:
p::after {content: " -\2761-"; font-size: smaller;}
Drop that style into any document that has paragraphs. Load it up in your favorite development browser. Now inspect a paragraph. You will not see the generated content in the DOM view, and you won’t see the pseudo-element rule in the Styles tab (except in IE, where you get the latter, though not the former).
The problem isn’t that I used an escaped Unicode reference; take that out and you’ll still see the same results, as on the test page I threw together. It isn’t the double-colon syntax, either, which all modern browsers handle just fine; and anyway, I can take it back to a single colon and still see the same results. ::first-letter, ::first-line, ::before, and ::after are all basically invisible in most inspectors.
This can be a problem when developing, especially in cases such as having a forgotten, runaway generated-content clearfix making hash of the layout. No matter how many times you inspect the elements that are behaving strangely, you aren’t going to see anything in the inspector that tells you why the weirdness is happening.
The same is largely true for dynamic pseudo-classes. If you style all five link states, only two will show up in most inspectors—either :link or :visited, depending on whether you’ve visited the link’s target; and :focus. (You can sometimes also get :hover in Dragonfly, though I’ve not been able to do so reliably. IE8’s Developer Tool always shows a:link even when the link is visited, and doesn’t appear to show any other link states. …yes, this is getting complicated.)
The more static pseudo-classes, like :first-child, do show up pretty well across the board (except in IE, which doesn’t support all the advanced static pseudo-classes; e.g., :last-child).
I can appreciate that inspectors face an interesting challenge here. Pseudo-elements are just that, and aren’t part of the actual structure. And yet Internet Explorer’s Developer Tool manages to find those rules and display them without any fuss, even if it doesn’t show generated content in its DOM view. Some inspectors do better than others with dynamic pseudo-classes, but the fact remains that you basically can’t see some of them even though they will potentially apply to the inspected link at some point.
I’d be very interested to know what inspector teams encountered in trying to solve this problem, or if they’ve never tried. I’d be especially interested to know why IE shows pseudo-elements when the others don’t—is it made simple by their rendering engine’s internals, or did someone on the Developer Tool team go to the extra effort of special-casing those rules?
For me, however, the overriding question is this: what will it take for the various inspectors to behave more like IE’s does, and show pseudo-element and pseudo-class rules that are associated with the element currently being inspected? And as a bonus, to get them to show in the DOM view where the pseudo-elements actually live, so to speak?
(Addendum: when I talk about IE and the Developer Tool in this post, I mean the tool built into IE8. I did not test the Developer Toolbar that was available for IE6 and IE7. Thanks to Jeff L for pointing out the need to be clear about that.)
November 03, 2009 05:41 PM
Gervase Markham -- Stars In The Internet Firmament
I get mail on a number of contact email addresses @mozilla.org. Sometimes, people wrongly use these addresses to send support requests (for which I have a canned reply) or praise. Most of the praise is just "Wow, thanks!" but occasionally something comes in which is a bit out of the ordinary:
Dear dear guys and gals of Firefox s/w and bug fixes...THANK YOU, THANK YOU, THANK YOU !!!!!
Thank you all for releasing me from the handcuffs, tyranny, vile and cat-o'-nine-tails of Microsoft Explorer and all its attendant BS, hype and unimaginable insane (and foreseeable!) problems!
In my heart and soul you are ALL heros (and hero-esses?!) and stars in the internet firmament !!!
May your light shine forever in the integalactic realm of truth, righteousness and ALL that is GOOD!
More power to your keyboarding souls and fingertips! :o)
Give yourselves (and/or each other [more fun, that!] :oD ) a great big hug!!!
(...or 'high-fives' if you're not yet that close! LOL )Bless you all - may your souls forever surf the infinite with brightness with freedom of spirit and goodness!
Cheers,
<name removed>
I'm off to shine a bit more light into the integalactic realm of truth and righteousness...
November 03, 2009 04:26 PM
Robert O'Callahan -- CSS Gradient Syntax
We landed support for a form of CSS gradients on trunk a while ago, but we got considerable feedback that our syntax --- which was an incremental improvement of Webkit's syntax, which basically exposes a standard gradient API in the most direct possible way --- sucked. A bunch of people on www-style got talking and Tab Atkins produced a much better proposal. Since we haven't shipped our syntax anywhere yet, dropping it and implementing Tab's syntax instead was a no-brainer. So Zack Weinberg, David Baron and I did that (using a -moz prefix of course), and today it landed on trunk. It should land on the Firefox 3.6 branch shortly. It's unfortunate to land something new like this after the last beta, but in this case, it seems like the right thing to do instead of shipping CSS gradient syntax that we know nobody wants.
This does mean that anyone who's currently using -moz-linear-gradient or -moz-radial-gradient on pages is going to find that their syntax doesn't work anymore. Hopefully that's not too many people yet.
November 03, 2009 11:21 AM
Asa Dotzler -- is google playing dirty with logos?
November 03, 2009 02:46 AM
security response time - mozilla kills it
The Zero Day Initiative has reported that Mozilla leads the industry with the fastest vendor response time to security bugs. Scroll down to Vendor Patch Time Statistics.
No surprise here, but nice to see it documented.
November 03, 2009 12:30 AM
November 02, 2009
Asa Dotzler -- chrome has 30 million active users
Today the Google folks disclosed that they have 30 million active users.
Chrome shipped its first public release 14 months ago and has managed to achieve a pretty large number of users in that time.
(For comparison, it took Firefox a full 8 weeks to add its most recent 30 million new users).
I've said this before, but really does deserve repeating that Google should go back to providing browser usage statistics for Google Search. They have a very large and globally distributed user base and that data would really help us all get a better picture of the global browser breakdown.
Remember when the Google Zeitgeist rocked?!
When the two primary sources disagree as much as Net Applications and StatCounter do, (Net Applications says Firefox has 24% of usage and StatCounter says it's almost 32%) adding a third big source seems like it could have nothing but a positive impact on understanding this world a little better.
Google, if you're reading this, please return to providing browser usage share in your Zeitgeist reports like you did before you started the Chrome project.
update: Wow. "Larry and Sergey recently gave the Chrome team a Founders Award, a multimillion-dollar stock bonus" That's pretty sweet. Lest anyone forget, Google has LOTS of money.
update2: Awesome tweet from @joedrew
November 02, 2009 10:59 PM
Postbox Team -- Postbox 1.1 Beta 1 Now Available
We’re pleased to announce the availability of Postbox 1.1 BETA 1, which contains the latest and greatest improvements gained from our move to the Mozilla Firefox 3.5 platform. Here’s what’s new and exciting about this release:
- Faster Performance - Postbox is now faster and more responsive than ever, so give it a spin!
- Better Looking Images - Postbox contains an improved graphics engine that produces sharper images with more accurate color.
- Improved UI Elements - For our Mac OS X users, Postbox now has more native looking UI elements, so it will fit right in with your Mac.
- More Reliable - 1.1 BETA 1 contains a number of reliability and stability fixes. Please see our release notes for the full set of changes.
- Localizations - Postbox localizations are now under way! If you would like to help localize Postbox, or just want to stay up-to-date with the latest localization news, please sign-up for our Localization Newsletter, or help us test a Language Pack.
Testing Postbox 1.1 BETA 1
Note: This BETA is available for testing purposes only. For increased stability and reliability, please use the latest production version, which is currently Postbox 1.0.2.
1) Download the Postbox 1.1 BETA 1 Release
2) Tell us what you think!
We’re excited to hear your thoughts on Postbox 1.1, so please use our feedback site to report issues or ask questions about this release.
- The Postbox Team
November 02, 2009 08:15 PM
Robert O'Callahan -- Challenges In Software Research
One of the greatest errors I see in computer science research is a tendency to view research as a spectrum with "applied" at one end and "basic" at the other, with attached assumptions that "applied" is incremental, boring, and engineering-oriented, but "basic" is crisp, radical, and intellectually satisfying. This is a false dichotomy, and I like to debunk false dichotomies.
I think the most principled way to construct such a spectrum is to classify research projects according to the degree of simplifying assumption they make to reach a crisp problem statement. So "applied" research adopts most of the relevant "real world constraints" into its problem statements, and "basic" research throws most of them out. The error is to assume that "real world constraints" make a problem boring, intellectually unsatisfying, and non-conducive to finding real breakthroughs [1]. This may be true "on average", but when choosing a research project one is not constrained by averages. In my experience, interesting research topics are abundant, and there are problems whose solution can be immediately applicable to the world while also being intellectually satisfying and potentially breakthrough science. (The current frenzy over combined symbolic and concrete execution is a good example.)
Let me suggest several such problems in the area of software development technology that I feel aren't yet getting the attention they deserve.
Verifying Refactorings
We know that verifying real software against full specifications is prohibitively expensive in most cases. However, I hypothesize that one could cheaply verify most changes that land in mozilla-central. The secret is that most patches are refactorings --- changes that should not alter observable behaviour --- or can be split into refactorings plus a smaller change that actually alters behaviour. "Should not alter observable behaviour" is very simple to state and understand, but still very tight. It would be huge win if we could prove that most such patches meet that specification. It's unclear how difficult this would be in general, but clearly patches that are the output of refactoring tools should be tractable to verify, and there is a lot of unexplored territory beyond that.
Improved Record And Replay Debugging
I don't have time to work on Chronomancer, but someone should be working out how to expose omniscience to the programmer to optimize the debugging experience.
Testing Fixes For Non-Reproducible Bugs
Record and replay technology is more or less here. (I'll post more about VMWare's solution later, but suffice to say it's working quite well so far!) Suppose you have recording of a bug which isn't reproducible. Now you can replay that recording one or more times and understand the bug and write a patch that should fix it. The problem you immediately run into is: how do you check that the patch really fixes the bug? You somehow need to inject the fix into the code and replay; that's tricky, and the fix may disturb the replay and cause the bug not to occur on that run for reasons unrelated to the bug actually being fixed.
Performance Measurement And Variation
Measuring performance is hard. One huge problem is that you want to measure effects that are much smaller than the random noise in the tests. I don't really know where this noise comes from. I would love to see research that analyzes the sources of run-to-run performance variation and describes techniques for reducing the variation.
I believe all these problems are reasonably easy to get into, have been little investigated in the past, have lots of room for exploration by multiple groups, are intellectually stimulating, and are likely amenable to solutions that could be immediately applied to the needs of software developers.
[1] The converse error --- assuming that "basic" research must not be boring or incremental --- is also widely held, but more easily falsified. Consider the endless stream of esoteric type theories that are both boring and completely incremental, such as my POPL '99 paper!
November 02, 2009 08:11 PM
October 30, 2009
Asa Dotzler -- tour of firefox
I narrated a tour of Firefox. Check it out.
October 30, 2009 08:46 PM
call for design/illustrator help
Hey friends. I need some help. As many of you know, we're coming up on the 5 year anniversary of Firefox 1.0 and as part of the celebration, I'm trying to get together the evolution of the Firefox brand (from way back in the Phoenix days through Firefox 3.5).
For the Firefox logos, we've got vector art, but unfortunately the Phoenix original art was lost long ago.
So, I'm hoping that someone reading this, with decent Illustrator skills, would be willing to re-create the old Phoenix logo for me.

update: Yeah, I tried Illustrator's live trace but there's just not enough data in this small bitmap to produce something that looks solid.
We're on a bit of a tight schedule so if this is something you'd be able to get to this weekend, I'd be eternally grateful. (my gratitude comes with a free classic mozilla "Hack" t-shirt if you're interested.)
October 30, 2009 08:25 PM
Gervase Markham -- Gerv Status 2009-10-30
October 30, 2009 05:46 PM
October 28, 2009
Gervase Markham -- Ubuntu Crash Reporter Fail

This could get recursive...
October 28, 2009 01:59 PM
SeaMonkey Team -- SeaMonkey 2 contributor interviews: Mnyromyr
It's time for the third in a series of interviews with SeaMonkey 2.0 contributors, obviously nicknames around here can be somewhat cryptic - our mail/news owner shows that off pretty well and goes by "Mnyromyr" on IRC:
Who are you?
My real name is Karsten Düsterloh.
Since nobody without a German language background can pronounce that properly, I'm usually known as Mnyromyr, though. (Which noone pronounces correctly either - there's true parity here! *g*).
I'm living in the outskirts of the Ruhr Area, Germany, where I was also born in the early '70s. Technically speaking I'm a mathematician, but in reality I'm working as software developer at a small ISP. Occasionally, I write articles on Mozilla topics.
When time permits, I'm an active carom billiards player, albeit of limited success (average of about 3.0, for Those Who Know™). I'm also fan and collector of science fiction novels. Yes, real, printed *books*, thousands of them. ;-)
How did you become a SeaMonkey contributor?
When I entered university in the early '90s, the internet wasn't that compelling. WAIS wasn't any more interesting than your usual text adventure, and you were content getting a mail every other week. And beating up emacs to deal with newsgroups isn't much fun either.
A while later, the chair in mathematics got shiny new Sun SPARC workstations, with Netscape 1.1 ... Done, end of story. ;-)
Well, actually, I followed the Netscape trail up until the end, this time on Windows (Trumpet Winsock, anyone?), but in parallel watched Mozilla's early steps until I made it my primary browser with milestone M<some_two_digits>. Sadly, Mozilla mail part wasn't usable until about Mozilla 0.6, hence Netscape 4.x had lots of time for pouting - .snm is pronounced c-r-a-s-h-i-n-g-_-h-e-l-l!
Mozilla became stable, but MailNews still stalled. Filed my first bug (96623) which got duped almost instantly. People were writing extensions to patch up the shortcomings, notably the Message ID Finder, so why can't I? Thus, at the end of 2002, I published the first beta of Mnenhy to customize a mail's header display.
When Mozilla began waffling about letting the suite die in favour of some boring browser-only thingy, I was *really* irked, so I took part in saving the lizard...
What notable contribution did you make to SeaMonkey 2.0?
The most *visible* one for sure is tabmail, the new-old tabbed MailNews user interface. Stuff like the preferences dialog backend or the SeaMonkey/Thunderbird source code disentanglement should be virtually invisible to users anyway, just as many patches and reviews ...
How can users give something back to you?
You could send me postcards, especially if you're not from Germany. The Mnenhy contact page has details. ;-)
Why, in your eyes, should people use SeaMonkey 2.0?
Well, it's the best SeaMonkey ever, of course!
Seriously, if you like to handle all your daily internet life - mail, news, RSS, browsing, IRC - in a smooth, integrated workflow with today's technology, SeaMonkey 2.0 is for you!
Even more, if you're a (web) developer, SeaMonkey comes with useful tools like a JavaScript debugger and DOM inspector already installed...
Not to mention that you don't need to learn your whereabouts in a gazillion different programs, it's all under the same hood.
And it's free. And open. Customizable. Get involved! Now! *jingle* ;-)
What next step do you see for SeaMonkey, and what would you like to happen in the Mozilla and SeaMonkey projects?
SeaMonkey's main strength is its integrated nature, we should boost that even more. The upcoming collaboration with the KompoZer project is a good example.
Personally, I see MailNews as the key component here, the communication heart of future internet live. Here you stay in touch with family, friends, peers and collegues, leisure and business. Write mails, read news, chat, plan your schedule, browse the net.
In other words: We need a calendar (again). We need widespread mail encryption. We need MailNews bookmarks. We need instant messaging and other ways of communication as they come along.
All these aren't bloaty killer features, most of the technical backend stuff is there already anyway, waiting to be exploited ...
October 28, 2009 01:00 PM
October 27, 2009
Gervase Markham -- Gerv Status 2009-10-23
October 27, 2009 01:05 PM
SeaMonkey Team -- SeaMonkey 2.0 - The Modern Internet Suite is Here!
The SeaMonkey project at Mozilla is excited to release its completely refurbished next generation of the all-in one Internet suite today: SeaMonkey 2.0, now available for free download, melds the ideas behind Netscape Communicator with the modern platform of Firefox 3.5 to create one of the most compelling open source products for advanced Internet users.
The combination of an Internet browser, email & newsgroup client, HTML editor, IRC chat and web development tools, that has already established a wide user base in its previous incarnations, has been rebuilt on top of the modern Mozilla platform, featuring world-class add-on management among other things. In addition, it has been improved with feed support (including an RSS and Atom feed reader in the mail component), a modern look, restoration of browser tabs and windows after crashes or restarts, tabbed mail, automated updates, smart history search from the location bar, faster JavaScript, HTML5 features (for example video and downloadable fonts), and even support for the Lightning calendar add-on (which will issue a beta for installation on SeaMonkey 2.0 in the next few weeks).
The Release Notes feature more in-depth lists of the improvements and known issues with the new version as well as installation requirements and instructions. Find even more information on SeaMonkey 2.0 and the SeaMonkey project at seamonkey-project.org!
October 27, 2009 10:45 AM
Postbox Team -- Postbox 1.0.2 Now Available
We strive to make every new Postbox release better than previous one.
In addition to listening to the great feedback we get from our users, we also analyze the crash reports that our users privately and securely submit to us.
In Postbox 1.0.2, we’re happy to announce that we’ve fixed several of our “top crashers”, making this release the most “rock solid” to date!
For the full list of changes, please see the release notes.
October 27, 2009 01:18 AM
October 26, 2009
Gervase Markham -- Sometimes Ranting Is Constructive
Three years after my 2006 rant about the fact that you can't reorder folders in Thunderbird, the excellent Jonathan Protzenko has written an extension to allow you to arrange them in whatever order you like.
Now all I need to do is figure out how to reduce that 3-year lead time...
October 26, 2009 09:46 PM
October 24, 2009
Postbox Team -- Postbox is Windows 7 Ready!
Windows 7 is a terrific new OS, but since it doesn’t include an email client by default, now is a great time for new Windows 7 users to try Postbox!
Postbox is ready for Windows 7! We’ve been testing Postbox with beta builds of Windows 7 for several months, and we’re pleased to report that it works amazing and searches your email at blazingly fast speeds. We even styled the interface to complement the new look and feel of Windows 7.
If you’re already using Postbox, you don’t have to do anything special when upgrading from Vista to Windows 7.
If you plan to move from Windows XP directly to Windows 7, we suggest you use the MozBackup application listed on our Extensions page. Simply back up your Postbox profile from Windows XP, save it to an external drive, and then restore it after installing Windows 7 and Postbox.
You can also use MozBackup to migrate from Thunderbird to Postbox.
For more setup tips and tricks, please visit our Support page.
- The Postbox Team
October 24, 2009 12:21 AM
Boris Zbarsky -- Sane way to return arrays to JS from XPCOM methods
With bug 523817 fixed, you can now write an interface like this:
void getSomething([optional] out unsigned long count,
[retval, array, size_is(count)] out whatever outArray);
and js consumers can do:
var myArr = foo.getSomething();
to get an array without having to have a dummy argument for the length. Word of warning: this only works if the length has no required non-retval arguments after it, so put that length at the end, right before the retval array.
October 24, 2009 12:19 AM
October 23, 2009
Asa Dotzler -- net neutrality wtf of the day
October 23, 2009 11:02 PM
Vladimir Vukicevic -- Firefox Application Directory Lockdown
Starting with Firefox 3.6, only well-known components shipped with Firefox will be loaded from the application components directory. Any other components (both binary and script) will be ignored. This work might also be backported to the 3.5 branch, but that decision has not been made yet. There are a number of reasons why this decision was made.
Firefox, through Gecko, has always had a flexible component-based architecture. In particular, creating binary components to interface with the OS or with other applications is fairly straightforward, though ultimately dangerous. Binary components have full access to the application and OS, and so can impact stability, security, and performance. What's worse, in a binary component, the line between supported/frozen and completely unfrozen internal Gecko interfaces is blurred, making it easy to create a binary component that works well against one very specific version of Firefox (potentially as specific as a minor security release), but causes serious problems with any other version.
As we've seen the popularity of Firefox increase, more and more binary components have been written to interface between Firefox and other applications. However, we haven't provided great guidance about the appropriate way to do so.
The only supported way of adding functionality to Firefox (whether a binary component is required or not) is through an add-on. This has many advantages for users: they can see that additional functionality is installed in the Add-ons Manager, and from there they can easily enable or disable it, as well as check for and receive updates. We're working on improving the user experience when third-party addons are installed in system-wide locations. Also, critically, add-ons include information indicating their compatibility with specific versions of Firefox. Having this version information allows for safe upgrades, especially when binary components are present.
Currently, third-party applications can drop binary components into the Firefox application's components directory and expect them to be loaded as part of our normal startup. This causes a number of problems, not the least of which is the removal of the user control that add-ons provide. Unfortunately, a number of third-party applications are using this approach to integration, and are currently causing Firefox 3.5 users stability problems. Many of these components were written for Firefox 3.0, and have not been updated for Firefox 3.5; a situation that we have no way of detecting because of the lack of versioning information on these "bare" components. Because a number of internal interfaces changed between the two versions, this leads to crashes or other problems when these components are used.
In order to simplify future integration with native code, Firefox 3.6 will include support for JSCtypes for add-on developers. This approach is greatly preferred over writing binary components. For example, a third-party component that would like to perform some action implemented in native code when an event is received can write the integration pieces in Javascript (capturing the event and so on), and use JSCtypes to make function calls to regular non-XPCOM component native code. Keeping as much of add-on code in Javascript reduces the impact of internal changes to Firefox, and allows for much easier maintainability.
(If you are a third-party application developer and have questions about integration in Firefox, please contact me -- I'd be happy to put you in touch with the right people who can answer questions and provide guidance.)
October 23, 2009 07:08 PM
Ian Hickson -- Zarro Boogs
We'll see how long that lasts...
October 23, 2009 08:00 AM
October 22, 2009
Chris Cooper -- Nomenclature
Recognizing some existing internal group dynamics and the need for the entire Mozilla release engineering (RelEng) team to grow in a more sustainable manner, we recently started an internal reorganization of the RelEng group. John will likely blog about the new structure of the group at some point, but I’ll relate the bits that are pertinent to me.
Armen and I have been working together on projects for about a year now, and that’s been working out pretty well, so we’ve formalized that arrangement. Armen will begin “officially” reporting to me immediately, and we’ll be looking to hire some more teammates to fill out our sub-group of about 4 people.
Our focus will remain the same: look for large-ish sections of RelEng-related project work, whether existing or new, and drive them to completion. Some things we’ve worked on previously include properly integrating l10n builds into our buildbot infrastructure, and enabling nightly updates for localized builds. We are currently working on standardizing on one set of update tools and getting localized builds put together for mobile.
John has affectionately dubbed our sub-group “Big Chunks” in reference to the scope of work we take on. That’s a terrible name, and that’s where you come in. I’m soliciting alternate naming ideas for our new group. The leading candidate so far was proposed by Armen: “Chunk Norris”. I have faith in the collective wisdom of the internet to come up with something better (perhaps not even referencing “chunks” at all) or at the very least to entertain me with your attempts.
And….GO!
October 22, 2009 03:03 PM
Gervase Markham -- "Where I Am" in Firefox
Firefox's Geolocation feature uses wireless access points. However, not all computers have wireless, and even for those which do, not all APs are in the database. It falls back to IP-based geolocation, but that is far less accurate. Also, it's worth noting that many computers - particularly those without wireless - are not laptops and therefore don't move around.
So what would be cool is if, if there's no fix from the wireless, Firefox gave you an information bar saying the following:
foo.bar.com wants to know your location, but Firefox doesn't know it very accurately. ( Find Myself On A Map ) ( Share Approximate Location ) ( Don't Share ) [x] Remember for this site
If you clicked "Find Myself On A Map", Firefox would bring up a map from Google, OpenStreetMap or another provider, zoomed and scrolled to the approximate location it knows, and would invite the user to place a marker where they were. At the bottom, there would be the following UI:
[x] This computer is always at this location ( Share This Location ) ( Cancel )
If you left the checkbox checked, Firefox would remember the coordinates you chose and then in future you'd get a slightly modified version of the normal infobar:
foo.bar.com wants to know your <saved location>. ( Share Location ) ( Don't Share ) [x] Remember for this site
Clicking on "saved location" would give you the opportunity to update it, if for example you'd moved house.
A UI like this would bring the benefits of accurate geolocation to a much wider range of machines. Anyone feel like implementing this for Firefox 3.7? :-)
October 22, 2009 08:19 AM
Alex Vincent -- "Why are you doing this?"
One of the hardest questions for me to answer is, "Why are you doing this?" It's also an excellent question, one that checks what I am working on. I recently found myself asking this question when trying to use something I've never tried to use before: weak references to DOM elements.
What are weak references?
For those of you coming from JavaScript-land, you know that once you hold a DOM element as a property, it will last as long as the object you attached that property to. (Depending on the usage, longer.) This is because XPConnect generates a "strong" reference to the element, which through the magic of XPCOM reference counting, requires the element not be deleted until all strong references are gone - including yours. Weak references are different. They are objects which hold a pointer to your real target, but they don't require the real target "stay alive". In JavaScript pseudo-code, it looks a little like this:
function getWeakReference(obj) {
var weakPtr = {
_realPtr: obj,
QueryReferent: function(aIID)
{
if (this._realPtr)
return this._realPtr.QueryInterface(aIID);
return null;
},
QueryInterface: function(aIID)
{
if (aIID.equals(Components.interfaces.nsIWeakReference) ||
aIID.equals(Components.interfaces.nsISupports))
return this;
throw Components.results.NS_ERROR_NO_INTERFACE;
}
};
return weakPtr;
}
There's one thing this code can't show you: Some time in the future,
weakPtr._realPtr could be destroyed, and set to null. That
doesn't happen in normal code (thank heaven!). But with weak references, it
can happen at any time.
Why are you doing this?
There's a long list of sub-projects and sub-sub-projects, etc., each of which seems to require I look at something I hadn't tried yet. Here's the current list, and how I started thinking (wrongly) I needed weak references.
(Continued on the next page...)
October 22, 2009 08:07 AM
Asa Dotzler -- videopress supporting open video
This is good news. VideoPress supports Ogg.
October 22, 2009 12:40 AM
October 21, 2009
Mike Shaver -- updating the update, as it were
I made an update to my WPF timeline post, but I wanted to make sure that the correction was seen by people who may not revisit that post.
The SRD blog post which revealed that Firefox users were also exposed to the IE vulnerability was published on Tuesday, not Monday. The post is labelled as having been published Monday, and the timeline including that survived review by Microsoft, but nonetheless it was an error that I published, so I’ll own it. To the best of my knowledge, the SRD post which informed us and the world of the Firefox exposure was published on Tuesday after the patch and bulletins were first made available to Windows users.
You guys all about ready to have this thing entirely behind us? Yeah, me too. Me too.
October 21, 2009 01:27 PM
SeaMonkey Team -- SeaMonkey 2 contributor interviews: Ratty
Here's the second installment of a series of interviews with SeaMonkey 2.0 contributors, let's hand over the stage to someone known as "Ratty" on IRC:
Who are you?
James Bolivar DiGriz, aka "Slippery Jim", aka The Stainless Steel Rat. Criminal Mastermind.
Or perhaps not. Let's try again.
Name: Philip Chee.
Where from: I live in Ipoh, Malaysia.
Daytime work: Currently I'm a self-unemployed IT consultant but previously I was the head of the IT department of a manufacturing company. I have ten years experience installing and managing Netware and Solaris servers, Oracle databases, and Oracle Financials. The most notable thing I did as part of that job I think was writing a two way interface between an Oracle Financials installation and an instance of the Maximo plant maintenence system entirely in PL/SQL.
Other notable things: I've been involved in science fiction fandom since the early 1980s and have been to several worldcons including Conspiracy '87 held at the Brighton Metropole (which at that time was run by the "Manager from Hell"). I plan to be at the Melbourne worldcon in 2010. See you there Sander!
How did you become a SeaMonkey contributor?
I started as a Flashblock contributor at the time when the current developers had given up support for the then Mozilla Suite. I revived support for the Suite and then continued making sure that Flashblock ran on the latest versions of SeaMonkey. Eventually I became the project owner.
As time progressed more and more extension developers were abandoning support for the Mozilla Suite or just writing extensions solely for Firefox. I became increasingly irritated that extensions that I really wanted to use only ran on Firefox. In particular there were two extensions that I wanted to use, Dev Boi and Scrapbook, but I had to start Firefox everytime I wanted to use them. So I set out to port the extensions I needed to SeaMonkey. Early on I wrote xSidebar for SeaMonkey to implement a minimal Firefox API compatibility layer to make it easier for me to port Firefox extensions. At first I was only doing extensions that I personally wanted but early on I started an extension porting service whereby SeaMonkey users would request extensions to be ported and this proved amazingly popular. To date I've ported more than a hundred Firefox and Thunderbird extensions to SeaMonkey. This gave me a unique insight into the API differences between Firefox and SeaMonkey and led Chris Thomas (CTho) to invite me to join #seamonkey. Incidentally CTho was convinced that "Jim diGriz" was my real identity and that "Phil Chee" was just an online pseudonym. He took some unconvincing :D .
What notable contribution did you make to SeaMonkey 2.0?
Implementing customizable toolbars in SeaMonkey which at that time was one of the major UI advantages that Firefox had over SeaMonkey.
How can users give something back to you?
I've turned on the "Contributions" button on the Flashblock page at addons.mozilla.org. Contributions happily accepted.
Why, in your eyes, should people use SeaMonkey 2.0?
SeaMonkey 2.0 is the latest iteration of the internet suite and contains the latest advances in Mozilla technologies. Unlike Firefox, SeaMonkey is aimed at power users and as such is more configurable out of the box in comparison.
What next step do you see for SeaMonkey, and what would you like to happen in the Mozilla and SeaMonkey projects?
To quote Buzz Lightyear: To Infinity and Beyond!
October 21, 2009 01:00 PM
October 20, 2009
Chris Cooper -- No problems
The Mozilla release engineering (RelEng) team has grown substantially over the past two years. Some members of the team have certain domain-specific focuses (e.g. talos, mobile), but one of our primary team goals has been to get our release automation to the point where anyone on our team can handle a release. Given the emerging branch picture for Mozilla code where we might see simultaneous releases on 3+ code branches (a.k.a release-apalooza), this is becoming increasingly important.
I’ve done my share of releases over the past few quarters, and until the current release (3.5.4, still in progress as of writing), I would have said that I understood the process pretty well.
The RelEng team has a convention when documenting our release procedures. When a given step completes successfully, we mark it with ‘No problems’ in the build notes. The problem with ‘No problems’ is that it isn’t instructive.
The current 3.5.4 release, for which I’m responsible on the RelEng side, has been about as far from ‘No problems’ as I can reasonably imagine. The in-progress build notes are available here for the rubberneckers and/or morbidly curious. We’ve had respins, we’ve had aborted betas, we’ve had automation interrupted at the very first step by tagging collisions, we’ve had single-locale rebuilds. I’ve cursed each and every one of these things as they’ve happened, but I’ve muddled through them with the help of others on my team. In the process, I’ve learned far more about the underlying processes than I ever would have if our release automation had simply chugged along to completion.
It turns out what I understood about our release procedure was how to follow a recipe. As long as I didn’t run out of ingredients and had all the right pots and pans, the recipe came out just as expected. Fortunately (and yes, I am going to say fortunately here because that’s the whole point), this current release has enabled me to ad-lib in the release kitchen a lot more when things are not perfect. Now if only I could find the release automation equivalent of bacon so I can declare culinary victory much earlier in the release process…but perhaps that’s where this metaphor breaks down.
Don’t get me wrong, every time I do a release, I’ll still be praying to anyone that will listen for build steps to complete with ‘No problems,’ but I no longer fear the occasional and inevitable problems that will crop up in a system of this complexity.
October 20, 2009 03:05 PM
Gervase Markham -- A Tour Of A "Pay to Download Firefox" Site
In the discussion about the best way to manage the Mozilla trademarks, the problem of sites charging people to download Firefox is often mentioned. However, not everyone has come across such a site. For your ediification, I present 'A Tour Of A "Pay to Download Firefox" Site', with detailed analysis and screenshots.
You'll be pleased to hear we have recently been having some success using trademark law with preliminary injunctions and domain name disputes against such sites.
October 20, 2009 02:35 PM
October 19, 2009
Mike Shaver -- update on the .NET Framework Assistant and Windows Presentation Foundation plugin blocking from this weekend
There’s a fair bit of confusion circulating about what happened, and what’s going to happen next, which is understandable — it’s been confusing! I’ll summarize here what happened, and what’s next.
Timeline
The add-on and plugin in question have a long and storied history, but for the events of this weekend the timeline basically starts this summer:
July 2009: Mark Dowd, Ryan Smith, and David Dewey present a paper at Black Hat detailing vulnerabilities in Internet Explorer and other software (including some Firefox plugins, such as Google’s Native Client, but not including Firefox itself or the Windows Presentation Foundation plugin).
Tuesday, October 13: Microsoft’s Security Research & Development team posts on their blog revealing that one of the Internet Explorer vulnerabilities in the Dowd and co. paper can be used to attack Firefox users through the use of this IE component in the Windows Presentation Foundation plugin. This plugin was and is distributed as part of Windows .NET Framework 3.5. As part of Patch Tuesday, Microsoft releases MS09-054 and its associated cumulative update, labeled as an Internet Explorer patch. (The bulletin has subsequently been updated to mention Firefox, see below.)
Friday, October 16: Mozilla contacted Microsoft to learn more about the exposure of our shared users. We discussed the nature of the vulnerability as well as the difficulty of uninstalling the plugin and add-on, and agreed that Mozilla should blocklist the add-on and plugin while we sorted out how best to ensure that Firefox users on Windows were protected. The SRP blog post was updated to indicate that Firefox users who applied the patch were protected from the vulnerability.
Saturday, October 17: Based on feedback from users (chiefly enterprise users), our web team began work on mechanisms for an overridable block (”soft block”) capability for Firefox 3.5 users. Discussions with Microsoft indicated that the add-on was a possible vector for the exploit, so it remained blocked.
Sunday, October 18: Microsoft informed us that the add-on (.NET Framework Assistant) was NOT a means for exploiting the vulnerability, and we removed it from the blocklist. The Windows Presentation Foundation plugin was confirmed to be exploitable unless the patch was applied, and remained on the blocklist. The MS09-054 bulletin was updated by Microsoft to include text about Firefox users.
Monday, October 19: We updated our blocklist management system to permit “soft blocks”, and adjusted the blocklist entry for the Windows Presentation Foundation plugin so that users who know they have the appropriate IE patch installed can re-enable the plugin.
Next Steps
Microsoft is monitoring patch adoption rates for the relevant patch, and when it reaches a high level of deployment we will remove the remaining blocklist item. I expect that will be in the next 48 hours at the outside.
Users of Windows 7 RTM are not affected, as the add-on and plugin are not distributed as part of Windows 7. Microsoft is working with Mozilla to make the functionality available to Firefox users in a user-controlled way for all operating systems in the future.
Stephanie Boesch, Director of Program Management at Microsoft, coordinated with Mozilla on this issue, and I want to thank her for her responsiveness and help throughout. She says: “Security is a top priority for all Microsoft customers, and we jointly decided the best course of action was to temporarily block the plugin and add-on while Firefox customers applied the Internet Explorer Security Update. We appreciate Mozilla’s shared commitment to protecting our mutual customers and look forward to working more closely with them in the future on such issues.”
Updated (Wed, Oct 21): fixed a timeline error caused by the SRD blog post having an incorrect publishing date on it, which even survived MSFT review of the timeline. The SRD post was published on Tuesday, not Monday.
[Comments are closed on my blog, but you can leave comments at the Mozilla Security Blog post on the topic if you'd like.]
October 19, 2009 10:36 PM
update: .NET Framework Assistant (ClickOnce support) unblocked
We received confirmation from Microsoft this evening that the Framework Assistant add-on is not a mechanism for exploiting the vulnerabilities detailed in the earlier post, so we’ve removed it from the blocklist. As the blocklist update propagates to clients, the add-on should be re-enabled for users who had it previously enabled.
We’re hard at work on improving the experience for (especially enterprise) users who wish to override the blocking of the WPF plugin before we remove it from the blocklist, and I’m working on a post to clarify the events of the past few days. We (especially I) appreciate your patience and support as we work to keep our users safe and comfortable with all the tools at our disposal.
October 19, 2009 01:10 AM
October 18, 2009
Boris Zbarsky -- It's snowing!
October 18, 2009 09:10 PM
Performance vs correctness tradeoffs
I've recently been running into a number of "benchmarks" where some rendering engines achieve better performance by simply doing the wrong thing because the right one would be "too slow". Here's a good example:
// FIXME: This check is good enough for :hover + foo, but it is not good enough for :hover + foo + bar.
// For now we will just worry about the common case, since it's a lot trickier to get the second case right
// without doing way too much re-resolution.
and here's a testcase demonstrating that in this particular open-source rendering engine performance in selector matching and dynamic change handling is achieved at the expense of correctness:
<style>
div { color: red; }
.foo + div + div { color: green; }
</style>
<body onload="document.getElementsByTagName('div')[0].className = 'foo'">
<div></div>
<div></div>
<div>Text</div>
This is not exactly an isolated incident; a number of the performance issues I've run into recently in Gecko have had to do with correctly handling edge cases that this particular open-source engine happens to just not handle. I guess it's easier to do well on tests if you cheat.
More interestingly, Opera's performance on this sort of thing is still quite good, and I have yet to discover them cheating...
October 18, 2009 06:39 PM
SeaMonkey Team -- Tabby!
Ladies and Gentlemen,
SeaMonkey has tabs now!
Wait, you'll say, but it already had since the very beginning?
Well, not quite. SeaMonkey had some tabs, but only in the browser and in certain dialogs. Now, you can let your productivity run free in MailNews as well!
Wait again, but I don't see any tabs there?
Currently, MailNews tabs (mostly) adhere to their browser counterpart's settings¹, hence the tabstrip is hidden if there's just one tab. And this first tab is just your default MailNews layout.
Now, let's do a little carpet ride, nosing under the new hood.
Imagine we're in your Inbox and we find some new mails by your granddad and your new girl friend. Certainly, you'll want to read them both, but like other strange people you're weak in reading two letters at the very same time, hence you open granddad in a background tab and start business with the serious stuff.
I do what? How?
Everywhere, where you could open a new message window in older versions of SeaMonkey, you can now open the message in a new tab. For instance, right-click an entry in the thread pane and choose "Open in New Tab". Or just do a middleclick, if you have your browser tabs configured to open new tabs on that. If you also have chosen to open new browser tabs in the background, new MailNews tabs will adhere to it as well, else the new tab will come up in front.
The most visible change with such "message tabs" is their layout, which basically resembles the standalone message window. No folderpane, no threadpane, just the pure message for your enjoyment. ;-)
Hm, your girl friend is relating to something she wrote a while ago. That mail should still be in the Inbox, you say? Just hit Shift-F8 to make the threadpane appear again, type her name into the search field, and open the old mail via the thread pane context menu! F8 (toggle messagepane) and F9 (toggle folderpane) will work as they used to, as does the "View → Layout" menu or clicking the splitter grippies. In fact, the only difference between "message tabs" and normal "folder tabs" is the initial ad-hoc layout change. And of course, switching between tabs will remember your last layout state.
Anyway, that girl deserves a reply, but first let's print the picture she sent. So, wait, huh, the printer button is gone from the main window and the preference panel hasn't it anymore either?
Introducing customizable toolbars:
If you right-click toolbars in MailNews, you can open a customization dialog now. Drag the printer button from the palette back onto the toolbar and that's it!
For some obscure reason, the Compose button is still on the main toolbar by default, but now, like many of his colleagues, it has a dropdown menu as well, so you can choose between the HTML and the plaintext editor.
Okay, printing done, reply written, what's next? Ah, yes, granddad's still waiting to be read in tab one. And he has news to tell — he's found the SeaMonkey blog RSS feed! Let's just add that feed URL to your MailNews feed account and move on.
Good joke, but MailNews is just, huh, mail and newsgroups ...
Ah, wrong again, dear reader!
From the main menu, choose "Edit → MailNews Account Settings" and click the "Add Account" button. Select "Blogs & News Feeds" as the account type and choose a suitable account name. Back in the main window, you'll find a new account with the standard RSS symbol. Open the subscribe dialog from the new account's context menu and add <http://weblogs.mozillazine.org/seamonkey/index.rdf> as your new feed.
Done!
Mmh, the Great Old One relates to a newsgroup thread, thus we're in need of a second folder tab: right-click the newsgroup and choose "Open in New Tab" ... And given that this is one of your most read newsgroups, it's time to drag it into the pole position of that account.
Although ... As you remember (I hope!), there was another post in another newsgroup, which would answer granddad's question profoundly. Thus, we clone the current folder tab by hitting Ctrl+T (or "File → New → Duplicate Tab" or doubleclicking the folder, if browser.tabs.opentabfor.doubleclick is set to true).
But Ctrl+T is Get New Messages!
Sorry, but no. For consistency's sake, we made Ctrl+T open new tabs both in browser and MailNews. Downloading new mail is now Ctrl+D/Ctrl+Shift+D.
Phew, please, just close the window, I'm done...
"This messenger window has 4 tabs open. Do you want to close it and all its tabs?" ;-)
So much for now from SeaMonkey MailNews 2.0 land; stay tuned² ...
¹ This will change, see bug 514476.
² Thou Shalt Smite Lightning Onto The Unbelievers?
October 18, 2009 08:00 AM
Eric Meyer -- A Matter of Conscience
So Louisiana Justice of the Peace Keith Bardwell has gained national notoriety for refusing to issue a marriage license to an interracial couple, referring them instead to another justice to have the marriage performed. His action has, of course, provoked a great deal of condemnation. Pretty much every elected Louisiana official above Mr. Bardwell (and plenty of them to either side) in the administrative hierarchy has called for his removal from his position. That goes all the way up to Republican Governor Bobby Jindal, who said:
“This is a clear violation of constitutional rights and federal and state law. Mr. Bardwell’s actions should be fully reviewed by the Judiciary Commission and disciplinary action should be taken immediately – including the revoking of his license.”
As for Mr. Bardwell himself, he has claimed not to be racist, but instead concerned for the biracial children that result from mixed-race marriage. Of all that he’s said, though, I was particularly interested by the following:
“I didn’t tell this couple they couldn’t get married. I just told them I wouldn’t do it.”
It interested me because it’s exactly the kind of reasoning that underlies “conscience protection” laws that exempt medical professionals who wish to refuse participation in abortion, or dispensation of contraception.
So now I’m very curious to know whether what pro-life groups have to say about what this man has done and how he’s done it. Or, for that matter, what Governor Jindal himself now thinks of the bill he recently signed into law.
October 18, 2009 01:51 AM
October 17, 2009
Gervase Markham -- Gerv Status 2009-10-16 and previous
My last three weeks of statuses are now linked from my User page on the wiki. Highlights of the current week:
- API 0.2 release imminent, blocked only on installation of a small patch on the two target Bugzillas
- New features: read and write support for flags and custom fields, and read support for groups
- I'm speaking at LUGRadio Live 2009 at the end of the week; if you are in the UK and free, come - it rocks!
October 17, 2009 08:00 PM
Mike Shaver -- .NET Framework Assistant blocked to disarm security vulnerability
I’ve previously posted about the .NET Framework Assistant add-on that was delivered via Windows Update earlier this year. It’s recently surfaced that it has a serious security vulnerability, and Microsoft is recommending that users disable the add-on if they have not installed IE patch MS09-054.
Because of the difficulties some users have had entirely removing the add-on, and because of the severity of the risk it represents if not disabled, we contacted Microsoft today to indicate that we were looking to disable the extension and plugin for all users via our blocklisting mechanism. Microsoft agreed with the plan, and we put the blocklist entry live immediately. (Some users are already seeing it disabled, less than an hour after we added it!)
Updated to reflect updates to Microsoft blog post. Also, the add-on was confirmed to not be a vector for the vulnerabilites, so it was removed from the blocklist. The plugin is still blocked pending more information about patch deployment rates; work is underway to make the blocking overridable to accommodate enterprises and sophisticated users who know they have installed the IE patch.
October 17, 2009 03:48 AM
Asa Dotzler -- children are stronger
Brilliant.
Reporter: "What do you say to parents who think the Wild Things film may be too scary?"Sendak: "I would tell them to go to hell. That's a question I will not tolerate."
:D
I love Maurice Sendak.
October 17, 2009 03:44 AM
October 16, 2009
Asa Dotzler -- remember that microsoft silent add-on install?
Microsoft silently installed a security vulnerability in Firefox. Not only was the install not requested by users (malware) but it opened Firefox users to a critical remote exploit flaw. Thanks, Microsoft. Appreciate that.
update Read more about this:
Microsoft exposes Firefox users to drive-by malware downloads by Ryan Naraine
Microsoft Plug-In Makes Firefox Vulnerable by Robert Evans
Microsoft plug-in for Firefox patched byPaul Mah
Sneaky Microsoft plug-in puts Firefox users at risk by Gregg Keizer
October 16, 2009 05:37 PM
Robert O'Callahan -- Removing The Media Element 'load' Event
Yesterday I checked in a patch that removes support for the 'load' event on <video> and <audio> elements. We simply never fire it. Also, the networkState attribute is now never NETWORK_LOADED. When we've read to the end of the media resource, networkState changes to NETWORK_IDLE. We plan to ship this change for Firefox 3.6.
There are several reasons we're doing this, even though it will break some Web content. One reason is that the spec says that 'load' should only fire when/if we guarantee that we will never again hit the network for data for that media resource. We never guarantee this, because our cache may always discard data. For example if you play through a large media file that doesn't fit in the cache, we'll read from the network again if you seek back to the beginning. If you play through a resource that does fit in the cache, and then play another large resource we might evict blocks from the first resource to make room for the second resource. So we never followed the spec here, and if we do follow the spec then we can never fire the 'load' event.
Another reason is that 'load' is a dangerous and fairly useless event. Web authors expect that every media element will eventually receive a 'load' event, because documents and images do, right? But that expectation is in vain, in many situations a 'load' event will never be fired. Furthermore authors cannot predict those situations because they depend on client cache size and policy. It is quite likely that the author will always get 'load' events during testing but some clients won't get a 'load' event and the site will be broken for those clients. So since the 'load' event won't ever fire in some browsers, and in other browsers will fail to fire in unpredictable situations, authors should never use it. In practice we see authors inappropriately using 'load' when they should be using another event like 'canplaythrough' or 'suspend'.
In fact, this argument is persuasive enough that 'load' for media elements and the NETWORK_LOADED state have been removed from the spec. There was consensus from Mozilla, Google, Apple and Opera developers that this is the right thing to do. I expect that other browsers will be following suit soon; in fact, apparently Chrome has never fired a 'load' event on media elements.
If you have been using 'load' on your <video> or <audio> elements, you should use a different event. There are several to choose from depending on what you actually want:
- If you want to do something when the video metadata is available (e.g. duration or size), use 'loadedmetadata'.
- If you want to do something when the first frame of video can be displayed, use 'loadeddata'.
- If you want to do something when the browser has stopped downloading the resource, use 'suspend'. Note however that the browser might stop before reaching the end of the resource, e.g. if its cache fills up, or the element doesn't have 'autobuffer' set.
- If you want to do something when there's enough data loaded to start playing, use 'canplay'.
- If you want to do something when there's enough data loaded to start playing and playback should be able to make it to the end without stalling on the network, use 'canplaythrough'. Note however that 'canplaythrough' might not fire because the browser's cache fills up, in which case you'll get a 'suspend'.
- If you want to do something when the video has finished playing, use 'ended'.
October 16, 2009 04:59 AM
Asa Dotzler -- a thumb on the scale
"Nothing in the design and implementation of the Ballot Screen and the presentation of competing web browsers will express a bias for a Microsoft web browser or any other web browser...."
That's the text of of the first sentence of the tenth paragraph of Microsoft's proposed settlement with the European Commission over its illegal tying of Internet Explorer with Windows.
The same proposal specifies the actual layout and design of the "ballot screen" that will be presented to approximately 170 million European Windows PC users sometime in the next few months and probably another 200-300 million users over the next 5 years.
Unfortunately, the proposed design of the ballot expresses a huge bias for one of the 5 browsers listed. The ballot, as described, will list the browsers in a static and alphabetical order.
And. It is common knowledge among usability experts, explained in quite solid detail and well cited by our very own Jennifer Boriss, that the first item in a list of choices will receive very disproportionate attention.
It is for this reason that the ballot cannot be static, regardless of criteria for ordering, and also be unbiased. The ordering of the choices on the ballot must be randomized. Failing to randomize those choices expresses a clear and strong bias to the first item on the list leading hundreds of millions of users to favor that item over all others.
There is simply no other way to eliminate bias. Anything short of randomizing is just shifting from one bias to another.
October 16, 2009 12:04 AM
October 14, 2009
L. David Baron -- Broadening crash analysis
In my last blog entry I discussed tools to help us analyze the reports we get for a particular crash signature. While we don't yet have all the tools we want in order to do that analysis, we have a bunch of them, and a pretty good idea of what other things we need. As I mentioned there, I was looking at the relationship between libraries that are loaded and crash signatures to show the case where the cause of the crash is one of the libraries that was loaded. Since then, I've also looked at the relationship between addons installed and crash signatures: this shows many of the same relationships (but also loses a few and gains a few), but with a much cleaner and easier-to-interpret source of data. I've also been looking at the relationship between crash signatures and number of CPU cores, since crashes that happen disproportionately on multi-core machines tend to be caused by threading problems. Other things, per signature, that we need to look at more in the future, include change-over-time, where time refers both to the build that the user is using (for crashes caused by our code) and wall clock time (for crashes caused by other code). Which type of time the appearance of a crash correlates better with can even be a sign of its cause.
However, analyzing crashes per signature has significant weaknesses. In particular, there are a lot of crash signatures. We tend to look at the most common ones. When doing that, we end up gaining a reasonably good understanding of the 25 most common crash signatures. However, since there's a long tail of less frequent crash signatures, understanding the 25 most common crash signatures only gives us an understanding of about 20%-25% of our crashes. (Though if we claim to understand all the different crashes that happen inside the Flash plugin, which is probably a number slighly smaller than the number of crashes caused by that plugin, then we can quickly "understand" an additional 18% of our crashes on Windows and 31% on Mac. Hopefully the multi-process work will make those crashes no longer crash Firefox in a Firefox release not too far in the future.)
I'd like to be able to get a better understanding of our crashes by looking at all the crash data in aggregate, rather than grouped by signature. This would help us answer questions like which extensions cause the most Firefox crashes (which in turn tells us what the most important things to fix are), or what portion of our crashes are caused by extensions vs. plugins vs. our own code (which can help us allocate crash-fighting resources correctly). However, I haven't figured out how to do this, and I think it's reasonably hard.
I think it's hard because in the data we're looking at, there are a lot of correlations. From looking at a group of related crash reports, it's somewhat difficult to distinguish a crash that is caused by visiting pages with Japanese text from a crash caused by a particular piece of software that Japanese users use to input text from a crash caused by a piece of software installed by default on many computers shipped in Japan in the past year, and perhaps even harder to distinguish if we actually have some of each and we want to know their proportions.
Analysis of all the crashes in aggregate might not be the only way forward, though. For example, we might be able to get significant benefits from tools that detect that a group of crash signatures are related, thus effectively reducing the number that we have to look at.
October 14, 2009 11:00 PM
Asa Dotzler -- are you safe? are your friends?
The tech savvy among you know that web browsers are no longer the number one target for malware and other online scams. Browsers are all getting much safer much faster since Firefox entered the market so the bad guys are targeting the less frequently updated and often times far less secure browser plug-ins. Most browser vendors don't control those plug-in so your browser can't completely cover that aspect of your Web safety. (Some browser vendors even knowingly ship insecure plug-ins.)
Well, at Firefox, we're not just punting and telling our users to contact their plug-in vendors. We're going that extra mile to try to help you keep those plug-ins secure.
The first step was our Flash Plug-in check that we rolled out with a recent Firefox 3.5 update.
Today, we're helping you take the second step with a much more comprehensive plug-in check.
Right now this page only works with Firefox, but we care about all of you and we're working to support those of you on other browsers as well. We're also working on integrating these checks directly into Firefox.
Outdated plug-ins are the number one source of crashes on the Web and leave more users open to security exploits than any program. Please tell your friends, family members, and co-workers about this new Plug-in Check service from Mozilla. The Web thanks you.
October 14, 2009 08:57 PM
SeaMonkey Team -- SeaMonkey 2 contributor interviews: Neil
Starting with this post, the SeaMonkey blog will run a weekly series of interviews with SeaMonkey 2.0 contributors - and yes, we have enough people in our team to be running one interview every week for a few months!
This series should highlight our great team of contributors and our very vivid community - and get you to know them a bit better. Our source code module owner, Neil Rashbrook gets the privilege to start this off today:
Who are you? (Name? Where from? Roughly how old? Daytime work? Other notable things?)
I'm Neil, I'm from Stevenage in England, and I'm the wrong side of 40. My job mainly involves supporting small business networks. Outside of my job I enjoy playing chess, but I only have a BCF rating of 132, so no international matches for me (yet)! I can play the viola and piano (not simultaneously obviously) and I'm also a keen church bell-ringer (but again, not as keen as some!)
How did you become a SeaMonkey contributor?
Back in the good old days of Netscape 4.5, I was looking for an upgrade, and I'd vaguely heard about the Mozilla project, so I looked it up and downloaded M14. Soon I had filed my first duplicate, bug 35000; not a good start, but my bug reporting karma has improved so that now a little over 50% of bugs I reported have been fixed, and that's also less than the number of bugs I've fixed too. At first I stuck to milestones, but then when my then employer upgraded to broadband I would start downloading nightlies. I even had a script to migrate all my local patches from one nightly build to the next. I started contributing using Gerv's PatchMaker, which at the time worked well with nightlies because they didn't mess around with all that preprocessing nonsense. Later on I gained access to a Linux workstation and started making my own builds, then when I got my first home desktop PC (sorry, but my old ZX Spectrum doesn't count) I started building natively on Windows as well as in a Linux VM. Nowadays I cross-compile from SFU to Windows, originally because it used to be faster than MSYS (I've since discovered that extra RAM helps MSYS more than SFU), but still because I can hard-link my chrome, so that I get instant results from edits (obviously my Linux VM uses symlinked chrome, which is even better).
What notable contribution did you make to SeaMonkey 2.0?
Hmm, well by patch size that appears to be bug 484484 (and that's not even a binary diff). Of course I've patched shared backend files too; bug 436051 wins there. But on the UI side, my most notable contribution would be making XPFE autocomplete work with satchel (form fill) and Places. And then there are the reviews... I've apparently reviewed over 3000 bugs in total; I don't know how many of those are just for SeaMonkey 2.
How can users give something back to you? (perhaps Amazon wishlist, etc.?)
I'd love to have a girlfriend, but no used ones, please!
Why, in your eyes, should people use SeaMonkey 2.0?
Because it's even better than SeaMonkey 1.1.18!
What next step do you see for SeaMonkey, and what would you like to happen in the Mozilla and SeaMonkey projects?
I think the next step for SeaMonkey is to try and pull in some features that sadly missed 2.0 as well as pick up on the new Gecko features that are landing. As for the future, it's unfortunate that Editor is showing its age and could really do with some updates.
October 14, 2009 01:00 PM
October 10, 2009
SeaMonkey Team -- SeaMonkey 2.0 Release Candidate 1
SeaMonkey 2.0 Release Candidate 1 is now available for free download on the SeaMonkey website. We encourage testers to get involved in discussing and reporting problems as well as further improving the product.
October 10, 2009 05:48 PM
October 07, 2009
Postbox Team -- Postbox Licensing Detail and Benefits
We receive lots of licensing questions, so here’s an overview of our licensing model and its many benefits.
Postbox 1.0 License
Many people have more than one computer, so a single-user license lets you run Postbox on any computer you personally use (e.g. your work computer, laptop, and home computer).
Your Postbox license will work on both Windows and Mac.
The Postbox 1.0 license is valid for all current and future releases in the 1.0 product line, including maintenance releases (1.0.1, 1.0.2, etc.) and minor upgrades (1.1, 1.2, etc.).
The Postbox 1.0 license does not expire. Once purchased, you can use Postbox 1.x for as long as you like.
Once localized versions of Postbox are made available, your Postbox license will transfer over seamlessly.
Family Pack Option
The Family Pack option allows up to five family members within the same household to use your Postbox license on their computers. All of the benefits outlined above for single-user licenses are extended to other household members.
Lifetime Upgrades Option
This one-time purchase option provides you with automatic access to all future versions of Postbox, including 2.0, 3.0, etc. This option also covers Family Pack licenses!
This unique option was developed to reward early adopters of Postbox 1.0. As such, it will only be available for a limited time.
More Info
For additional information, please see our FAQ.
Note: the Lifetime Upgrades Option was inspired by the good people at Spanning Sync and Spectacular Apps. Thank you Charlie and David for your help and advice!
October 07, 2009 10:51 PM
Gervase Markham -- Open Source Canteen Booking?
Does anyone know of any open source software for managing bookings in a canteen, say at a university? So each student can say e.g. "I'm in on Monday, Wednesday and Friday lunchtimes, and I'm a vegetarian", and a report comes out of the back end telling the kitchen how much food to cook? I've searched, but I can't find anything - and yet I'd expect it to be a fairly common problem.
October 07, 2009 09:23 AM
October 06, 2009
Gervase Markham -- Möbius Strip e-Scroll
I saw the Infinite Book on O'Reilly Radar, and that got me thinking: when we have flexible electronic paper, how about an eBook reader that either is, or can be clipped together as, a möbius strip, the width of a bit of A4? So you just keep moving it through your fingers as you read and the book goes on and on and on. Like an infinite scroll (the paper sort).
Someone else can come up with the concept art :-) I publish the idea here to make sure no-one can patent it.
October 06, 2009 03:30 PM
Postbox Team -- New Postbox Release, and What’s Next
Postbox 1.0.1 Now Available
A new version of Postbox is now available! This release contains a number of features and improvements requested by Postbox users, and represents the first of many rapid releases to come.
Here’s what’s new and improved in 1.0.1:
- You can now Archive to any folder within any account - even across accounts and to local folders too! This makes it possible to do things like archive mail from your Yahoo! account to a folder on Gmail.
- Conversation views can now be customized to display in chronological or reverse chronological order.
- Message headers within conversation views will now display contact photos, making it easier to scan for and identify participants in a conversation.
- Favorite topics can now be assigned to the selected message using 1-9 on your keyboard.
- The color of a topic can now be applied to the entire row in the message list.
- A larger font size can now be used within the message list (Mac only).
- Quick Look is now supported on Snow Leopard (Mac OS X 10.6).
- For power users, Postbox can be configured to no longer insert the “- -” before signatures (see the release notes for details)
- Support for the popular Enigmail add-on, which will allow you to sign and encrypt messages using PGP.
- Fixed a problem some users have been having with having to re-enter their License code for Postbox after an update or restarting.
- Several reliability fixes and security updates from the latest Mozilla Firefox 3.0.14 release.
For the full list of changes, please see the release notes.
What’s Next?
Lot’s of exciting things will be happening over the next few months. We’re now gearing up our localization efforts for Postbox starting with the most highly requested languages. Current Postbox users will be able to switch to localized versions as they become available. If you would like to participate in our localization efforts or be informed of developments as they arise, please sign-up for our localization newsletter.
We’re also evaluating all the terrific feedback we’ve received over the beta period and since we shipped 1.0, and are currently prioritizing these features and scheduling them into our release roadmap. Some features will be familiar to our Get Satisfaction community, but we will also have some surprises in store as well.
And staying true to our rapid release model (we had 16 betas!), the next version of Postbox is just around the corner, so stay tuned to see what comes next.
October 06, 2009 04:47 AM
October 04, 2009
Gervase Markham -- The Most Under-Appreciated Skill
The most under-appreciated skill in the modern world is someone who can explain the complex in simple terms without trivializing it.
-- Scott Berkun
Anyone want to suggest other contenders for the title?
October 04, 2009 08:32 PM
Henrik Gemal -- about:memory landed
I'm here at EU MozCamp 2009 in wonderful Prague, and just saw that the about:memory feature landed on trunk.
I had the chance to talk to Vladimir Vukicevic, how implemented the infrastructure for it, and he told him that this is just an initial landing. The about:memory is not yet finished and it can and will be improved in loads of way.
The final/ultimate implementation will include data for how much memory JavaScript, images, etc takes up.
October 04, 2009 03:30 PM
Robert O'Callahan -- Melbourne
We had a great time visiting relatives in Melbourne. During the week we took a three-day road trip along the Great Ocean Road southwest to the Twelve Apostles rock formations, then north to Hall's Gap in the Grampian mountains before returning to Melbourne. We did a lot of short walks --- at Anglesea, Marriner's Lookout, Maits Rest, the Cape Otway lighthouse, the Gibson Steps, the Loch Ard gorge, Chautauqua Peak, and McKenzie Falls. Along the way we saw wild koalas, kangaroos and wallabies. The Great Ocean Road reminded me of Big Sur. The stories of shipwrecks, settlers, hardship and survival were inspiring. A great trip.
One tip: a brochure claimed the return trip to the base of McKenzie Falls takes one hour and twenty minutes, so I almost skipped it, but we did it in twenty-five minutes, with two five-year-old kids. It's well worth it!




October 04, 2009 01:12 AM
Last updated: November 07, 2009 02:00 PM




