Planet Mozilla

For a side project, I needed a simple rhyming web service. Pass in a word, and have it spit out that word’s rhymes. A quick scan of the internet showed the impossible — it didn’t exist! 30 minutes of Python hacking later and the problem was rectified.

http://azarask.in/services/rhyme

The service can take two paramaters: q and callback. The former specifies the word to be rhymed with (self-rhymes excluded), and the later wraps the results in a function callback in JSONP-style. Data is returned in JSON format.

Here are two examples to get you started:

http://azarask.in/services/rhyme/?q=world

["curled", "hurled", "swirled", "twirled", "neworld", "transworld", "unfurled"]

http://azarask.in/services/rhyme/?q=world&callback=hello

hello(["curled", "hurled", "swirled", "twirled", "neworld", "transworld", "unfurled"])

The results are ordered by number of syllables and then alphabetically. If you make something cool, let me know! (I’m thinking about uses for the new canvas-based text APIs).

Easter egg: If you don’t specify any arguments then the service returns the rhymes of a very special word.

December 29, 2008 03:40 AM

Every so often (okay, ALL THE TIME) someone (Linux users, of course ) wonders why Mozilla doesn’t use platform libraries for things like networking code. One commonly-argued reason is that it gives us the flexibility to fix security problems without waiting on those upstream libraries to make the fix themselves — we control the code, and we can make the fixes ourselves.

Another reason not to use platform libraries occurred to me while reading Planet WebKit today, specifically the recent WebKit’s week - #7 post. Quoting from that post, added emphasis mine:

HttpOnly Cookie (38566)

An Internet Explorer extension (added in Firefox and Opera since) will soon be supported by WebKit based browsers. This restricts the access to certain cookies. They are only available for an HTTP request and so not from JavaScript. This is an important functionality to restrict the damages of an XSS vulnerability. This is not available in the nightlies because you need some updated Apple proprietary libraries (CFNetwork).

As noted, Firefox supports HTTPOnly cookies; after the patch to add this support was committed, you could download nightly builds which included the fix, and HTTPOnly would Just Work. No mess of upgrading platform libraries to make it happen, no separate-package updating, no waiting on Apple to update their platform libraries. (Incidentally, will Apple make those updates for 10.4 users as well, assuming they even decide to release a browser upgrade for a, er, “dying” OS release? Maybe, maybe not, who can say; “Apple does not comment on future products.”) Just download the build, build it from source yourself if you like building from source or if you’re a Gentoo ricer, and you have a working browser with the fix.

There are tradeoffs to be made rolling your own code when you could use something provided by the OS or by a third-party library. However, it should be equally clear that there are tradeoffs to be made going the other way, at least if you truly care about being cross-platform.

(On an almost entirely unrelated note, I was pleased to discover while writing this post that HTML5’s outline-generation algorithm properly handles headings inside blockquote elements. Yay for specs anticipating my concerns! )

December 28, 2008 10:02 PM

December 28, 2008 09:26 AM

Brent Simmons: Here’s the thing, though: it’s not a free market. It’s owned and operated by Apple, and there is no alternative…

It is a free market. It’s just not a free market for Apple sharecroppers.

I would point out that Apple is something akin to Standard Oil for iPhone developers, but that overstates their plight, since they deal in cellphone ornaments for rich people. Morons.

December 28, 2008 06:17 AM

If you are using a beta version of Firefox or even a nightly build, to help in testing brand-new features and verifying fixed bugs, it’s sometimes necessary to identify a regression. Normally you will start in narrowing down the regression range by dividing the possible time frame in smaller chunks. It will take some time but finally you will end-up with two identified builds. One build with the feature working and another one with the regression starts happening.

The next step will be to get the list of patches, which have been checked-in between these builds. Until now I did that by taking the build id from each build and entering it in the date fields on the pushlog page on hg.mozilla.org. The problem here is, that you have to remember to add the time difference from PST to UTC or even your local time. I forgot this a couple of times and wondered why none of the listed check-ins were related in any way to the regression I’ve found.

But today I got a nice hint from Ted Mielczarek how to get the correct list of check-ins more easily. With his comment on Bugzilla he pointed out that recent builds offer the changeset information on the “about:buildconfig ” page:

The only thing you have to do now is to copy the changeset id for both versions and to create an URL like this one which will show you the list of check-ins.

For the moment it seems like that there is no UI for such a query but it would be great to have one in the future. But even in the current stage it will boost your work flow to finish any regression test.

Update: I’ve filed bug 471321 which covers the missing ui issue.

December 28, 2008 12:01 AM

« Post 1 | This is the 2nd post in my MoFo Futures 2009 blog series.

"When a job went wrong, you went back to the beginning. And this is where we got the job. So it's the beginning, and I'm staying till Vizzini comes." — Inigo Montoya, The Princess Bride Screenplay by William Goldman

Being a part of Mozilla over the last three years has been a humbling experience.

When I started with the project, I imagined great personal success. Like a happy little worker bee flitting from Free Software flower to Free Software flower, I would cross-pollinate Mozilla with PHP's community savvy and pragmatism, MySQL's  disruptive innovation canny, and the Free Software Foundation's dedication to their mission and service ethic to Free Software developers. Mozilla would be better, stronger, faster (and, by happy side-effect, I would be a hero.)

Instead, I've experienced a mix of tepid success and equally tepid failure in my Mozilla Foundation work - the sparks I strike never seem to make it into full flame. While I'm proud of my Age of Literate Machines work, it's still just a spark.

If you had asked me why this was a year ago, I probably would have told you that it was because I worked with world-changers - people who've helped build the foundations of the net, people who've stood up to powerful governments, people who've helped build things that are the foundations of parts of my life - and that it is difficult to be a peer in this group.

Reflecting on this after the last three months of personal and organizational soul-searching, I think that the key reason being a part of Mozilla is uniquely humbling is that we have a massive constituency and want to effect global change across the breathtaking complexity of the net. To make meaningful positive change at this scale requires deep clarity of thought, a singular purpose and a lot of luck. I've had the luck, but to get to where I must be I need to go back to the beginning.

Next post soon.

« Post 1 | This is the 2nd post in my MoFo Futures 2009 blog series.

December 27, 2008 08:12 PM

An amusing video via my favorite economist, even if it’s obviously not true to real life:

As a computer scientist my first thought is that it’s a very good thing there are only twelve days; imagine the cost if it were O(n²) rather than O(1)! (There’s a very large constant in this video’s case, of course, but as it’s not intended to accurately reflect reality there’s no reason to optimize. )

December 27, 2008 12:45 PM

Our Mozilla Campus Reps wrapped up the “On the Street” Interviews project in December and produced some very cool videos.  There were 12 submissions from our reps in the US and in India… and I hope that future projects like this will allow us to see more of the world as reps in other countries get involved.

I wanted to share all of the great videos with the Mozilla community…and congratulate Mauricio, Fazulul, and Galen on their videos, which were voted the “Top 3 Favorites”  by the Mozilla marketing team.

Here are the 2008 Campus Reps “On the Street” videos with some comments from our reps about their experience:

Mauricio Zepeda, Florida Institute of Technology, Melbourne, FL

http://www.youtube.com/watch?v=61TICB-YbPY

By knowing how much time of our life is spent online, the purpose of this video was to capture people’s feelings and preferences  regarding Internet Browsers. We received a lot of help from different people who supported Firefox and believed that making this video was a good cause. Among this people are the Camera Man and Editor, “Kleber Garcia”, who managed to borrow a professional camera from his job; The people behind ACM Florida Tech Chapter, who provided us with their time and support; And the Christian / Emo / Happy Hardcore artists from Solo, Norway “Shari Vari” who granted us permission for using their music.

Fazulul Rahman, Sri Sakthi College of Engineering and Technology, Coimbatore, Tamil Nadu

http://www.youtube.com/watch?v=Q9Dk-42V0e8

It was really an awesome experience hearing the exceptional usefulness of Firefox from the public.It made me to think that people are very much aware of the world’s most fastest,safe and useful browser “Mozilla Firefox”.  In this on the street experience, i met loads of people.  They find Firefox as their best companion when it comes to surfing or searching…while there are only few who have little knowledge of just loading web pages through firefox.  And there are even few who haven’t heard of Firefox and still stick on to the old default Windows browser “Internet Explorer”.  I took  this opportunity to teach and show them that there is Firefox for them to lead.  I also helped them come out of that little knowledge and made them use the world’s fastest browser “Mozilla Firefox”.  I helped installing them the recent firefox and showed them the difference in speed for loading webpages between Firefox and IE.  Also I explained them of the useful features like add-ons, private data clearing, player integration, download manager integration, popup blockers, etc…

Galen Weld, The Evergreen School, Shoreline (Seattle), WA

http://video.google.com/videoplay?docid=-7380881017562287512

I really enjoyed interviewing my teachers to create this video. For me, it was interesting to hear about all my teachers experiences with Firefox. I never really thought about their opinions on the subject. I was surprised to learn that a lot of my interviewees preferred Firefox over IE. I had always thought of my self as one of the lone Firefox users, trying heard to convert the others. Creating this video really helped me think about the fact that some of my teachers really care about open source software. Also, it was a great opportunity to have a much needed laugh.

Vishal Jalan, Indian Institute of Management, Indore, India

http://www.youtube.com/watch?v=j2LsXOa3HGQ

The interview were mostly conducted amongst MBA students who are normally not that “Tech” savvy. Quite a bunch of them still use internet explorer.
It was a wonderful experience talking to people about firefox and mozilla in general. I got to meet some die hard firefox fans to some who had absolutely no idea what mozilla was. It was amazing to see some of them belonging to the same campus but such a vast difference in the awareness about mozilla. One thing which was common across people was that all of them who used Firefox were very proud of the fact.

Abhishek Suresh & Sheriff Mirza, Sri Shakthi Institute of Engineering and Technology, Tamil Nadu, India

http://www.youtube.com/watch?v=M8pKFblbDoo

We visited a couple of places, and it was an amazing experience speaking to many people. It was embarrassing and funny in the beginning, eventually we got a hang of it and it was fun indeed. We made a compilation of the funniest and best interviews which would of course make the video a bit interesting to watch.

From our Statistics, this is what we obtained:
Google Chrome - 20 Users
Mozilla Firefox - 16 Users
Safari - 15 Users
Opera - 15 Users
Internet Explorer - 8 Users
Maxthon - 1 User
Ares? - 1 User

Udit Sharma, Kautilya Institute of Technology & Engineering and Apex Institute of Engineering & Technology, Jaipur, India

http://video.google.com/videoplay?docid=-8205491573763344876

I am Udit Sharma & I am Campus REP of Kautilya Institute of Technology & Engineering, Jaipur. While shooting this interview, I enjoyed a lot, it was amazing experience. While shooting the videos, I concluded that 4 out of 10 people don’t know about Mozilla and don’t know about Firefox…. I am shocked!! to observe this in my city Jaipur. Even the lecturers & professors of my neighborhood campus i.e. Apex Institute of Engineering & Technology, Jaipur don’t know about Firefox, if they would.. than they don’t know that Firefox is Free, open source etc. They are still using boring, slow, MS Internet Explorer…. I interviewed the professors of my neighborhood campus and included in my On the Street Interview. I told many people about Mozilla Firefox and its features and most of them promised me to use Firefox as there default browser. I observed many people saying that they know about Firefox but they don’t bother to download Firefox and than using it…….as…Firefox doesn’t come default with the MS Windows…as 75% users are still using Windows….. Some people comments are funny & crazy and some people are really have knowledge about Mozilla, Mozilla Firefox, Open Source etc… I think this “On the Street” project helped me a lot to understand people minds for WEB etc. I am always ready for these kind of projects and I can do anything to promote Mozilla products….. MOZILLA ROCKS!!!!!!

Ahana Datta, Springdales School, New Delhi, India

http://video.google.com/videoplay?docid=-8741311080588966700

I was amazed at the response that students were ready to give, even though many of them were not aware of Firefox or Open Source or the difference between Mozilla and Firefox. But I was glad to know that all of them have at least heard of Firefox, may they not be using it. Anyhow, I had a fun session making them aware of the browser and trying to convert them to it!

Gracelyne Fernando, Suburbs of Tuticorin, Tamil Nadu, South India

http://www.youtube.com/watch?v=kAV1lRxzSjg

My on the street experience was good.. I met people who weren’t really all that computer literate.  I wish I could have done a more professional campus sorta footage.  i had some hilarious incidents too.. like when I told people to try out firefox for mobiles when its released,one girl joked by showing her nokia 1100 set and said nothing could be used on her mobile…! on the whole it was a fun-filled session.

Anil Pai, Bangalore, India

http://video.google.com/videoplay?docid=1932687697551041735

The campaign was started in the first week on November. Initially I started alone capturing videos in my home locality, at my campus asking questions to my classmates and neighbours. In the second week, I went to shopping mall (Big Bazaar) after buying a mini DV video cassette along with two of my friends in the evening and asked questions to everyone around the mall. The mall security persons and policemen did ask some questions to us to know what we were doing, and we answered that its a marketing project for our college exams… Thankfully they dint ask us to show our mozilla ids.. ( i had ur letter ready in my bag which u had sent the other day,  to show them in case they ask)… We gave them mozilla goodies and they thanked us.. The very next day there was Abode Boot camp goin on in the other part of the city.. I went there with my friend and questioned two guys there, and they answered really well… We thought marketing mozilla in abode boot camp may lead to problems, so we just listened to some demos there and returned back… Some video coverage was also done by me  in the parking lot of my campus asking questions to 1st, 2nd, 3rd and final year students , to check their Mozilla Knowledge..  Finally, it was a great experience for me and my friends. All the speakers of the On the Street campaign video were given a set of Mozilla goodies containing stickers, hats, lanyards, badges etc.. Hope you and Mozilla team will love watching this video and also the other Mozilla Campus Reps who havnt started with the campaign yet will get some idea

Shreyank Gupta, Kolkata, West Bengal, India

http://www.youtube.com/watch?v=4i73_8fR0wo

Vishnu S., VIT University, Vellore, Tamil Nadu, India

http://video.google.com/videoplay?docid=7843314387379868398

Vineel Reddy, Hyderabad, India

http://www.youtube.com/watch?v=WE2YfbIaSJM

Thanks to all the reps that participated and for everyone that helped review the videos.   I am working to put together the best clips from all the submissions into one highlight reel that we will be showcasing on Air Mozilla and YouTube in early 2009… so keep an eye out for that.

December 27, 2008 04:19 AM

A friend told me she was unable to login to hotmail using Firefox anymore, getting some warning about not being a supported browser. She also had similar problems with Netflix. We’d recently released new updates on both Firefox 2.x and Firefox 3.0.x, so I stopped by her house to figure out what was going on, just in case…

Sure enough, we could easily reproduce the problems, so I started investigating. “hmmm… wonder what version she is using?

Ahhhhhhh!! A few minutes later I had installed FF3.0.5 over her existing FF1.0.7 installation.
Lessons learnt:

• Firefox1.0.7 works just fine on PPC based Mac OSX 10.5.5. It had never crashed for her, not once.
• A pave-over install of FF3.0.5 over FF1.0.7 works just fine; history and home page were correctly handled in the pave-over install and worked perfectly. I didn’t check bookmarks, because she never uses them, preferring to use URLbar history instead.
• The amount of websites that still work with really old browsers is quite impressive. Obviously, new functionality might not be visible/usable, but having a website gracefully fallback in functionality so it still does *something* reasonable on older browsers is tricky to do, and I was impressed by the number of sites that made that effort.

“Oh, thanks for fixing that - but whats changed in this new version?”. Oh boy - whats changed between FF1.0.7 and FF3.0.5? Honestly, I didn’t know where to start. Tabs? Memory improvements? JS performance improvements? Awesome bar? Phishing protection? …? After a brief hesitation, I decided to only describe one improvement: how the browser can now check for new updates automatically, and showed her where this was set in preferences, so she should never be out-of-date like this again.

Heading home, thinking about it further, I still think that was a good choice, but it got me wondering what other people would choose. So, I’m curious - if you had to list just one “best new feature” since FF1.0.7, what would you choose?

December 27, 2008 12:54 AM

The grounds of Mansion House are have a lot of a fairly tame wekas and peacocks.

Beehive Island seen from Kawau with the storm gathering behind it.

Taken from Sullivan's Bay in the evening of Christmas Day, Castle Rock is the peak jutting out above the horizon to the right of Pudding Island in the foreground.

Sullivan's Bay on Boxing Day --- there were lots of day trippers on Christmas Day, but it was a lot quieter the next day, although there were still a lot of campers about.

December 26, 2008 08:48 PM

Joe Drew (feed) - Joe Drew has been involved in the Mozilla community as a tester and occasional bug reporter since the project began, but became much more involved upon being hired by the Mozilla Corporation in February of 2008. He currently works in the graphics group, and is Gecko’s imagelib maintainer. \o/

Jeff Muizelaar (feed) - works on the graphics team from the Mozilla Toronto offices, and will be blogging about Cairo perf, image scaling, and non-prescriptive etymology. Mike Beltzner has described his work as a “Must Read” and Johnathan Nightingale has called him “A paragon of the modern world; a titanic force.” (Jeff had no part in the writing of this bio.)

Aki Sasaki (feed) - Aki Sasaki is a new Mozilla employee, but was at Netscape from Feb ‘01 to July ‘03. Aki is currently on the Firefox build/release team and focusing on getting Fennec performance and unit tests automated on Nokia N8×0’s.

Nick Nguyen (feed) - Nick Nguyen is the new Add-ons Lead for Mozilla. A lifelong nerd, Nick likes giant robots, video games, and keeping the internet open and free. Before his dream job at Mozilla, his most relevant gig to date was as the product lead for browser extensions, platform, and community on del.icio.us.

Zach Lym (feed) - Zachary Lym is lead grunt of Usability research for Mozilla’s Ubiquity. He is currently working on an undergrad major of Psychology with a minor Graphic Design, and eventually a masters in Usability. He lives in Seattle, right next to the Troll.

December 26, 2008 06:47 PM

We’ll be taking advantage of the holiday lull and performing scheduled maintenance tonight from 7:00pm to 11:00pm PST. The following changes will take place:

• 7:00pm PST (0300 UTC) mozilla.org MX change.  We’ll be updating mozilla.org MX records.  No downtime is expected.
• 7:00pm PST (0300 UTC) duration 4 hours: Kernel upgrades.  We’ll be doing kernel security updates on various machines affecting the following services for approximately 10 minutes each:

build graphs / pageload tests
CVS, cvs-mirror, SVN, Hg
LXR/MXR
Despot, Doctor
ftp.mozilla.org
quality.mozilla.org
videos.mozilla.org
stage.mozilla.org
people.mozilla.com
Buildbot Try Server
MDC Search
Internet-facing mail relays, list servers, and outbound mail (mail will be queued)
Any sites using LDAP for authentication
DNS/DHCP/wifi/telephone services in all Mozilla offices (except Beijing)
support.mozilla.com chat server
irc.mozilla.org
All database-backed websites and services, including but not limited to: Bugzilla, Breakpad, Bonsai, SUMO, SpreadFirefox, Addons, bouncer/download, Blogs, QMO, Litmus

Please let me know if you have any reason why we should not proceed with this planned maintenance. As always, we aim to keep downtime to as little as possible, but unexpected complications can arise causing longer downtime periods than expected. All systems should be operational by the end of the maintenance window.

Feel free to comment directly in this blog if you see issues past the planned downtime.

December 25, 2008 11:09 PM

As everyone knows, today is Fetivus. So happy Festivus.

For those who need some background, they can read my previous post from 2006.

Hopefully we can get bug 394616 fixed so Firefox doesn’t mark Festivus as a misspelled word. It’s getting annoying (I know I can add the word, but I periodically clean things up and that goes away). That said, a spell checker’s ability to correct my amazingly wrong spelling of Hanukkah is amazing. No matter how badly I misspell it, and I can assure you I do a great job of it, Firefox always knows what I want. If you haven’t tried that before, give it a go. Someone told me a long time ago Hanukkah is one of the best words to test the abilities of a spell checker with. This is true either because spell spell checkers require skill to fix it, or because it’s so easy to misspell. Next time you need to review spell checkers, this is a test you can use. you’re welcome.

While I’m on the topic of holidays, here’s a Christmas message from a monkey as the queen typically does. It’s pretty well done for a YouTube video.

December 25, 2008 04:19 PM

Happy Holidays!

I will use this moment to introduce you the first release of my latest project. Over two months ago I presented the revision version of Mozilla Community Theme.

MCT is an element of a wider project - Mozilla Community Sites (MCS) that will help start a new community and maintain a website without much effort.

The Theme and its implementation are major part of the project and for last two months I have been working on creating a powerful, generic implementation of the theme, several small tools for making the theme easier to use and many tiny updates that should result in the higher quality of the theme.

On Monday we finalized the draft of the licensing guidelines which was the final step to release the theme to public.

Today, I’m proud to present you all the first revision of Mozilla Community Theme (click to test a mockup live):

From today I’m starting a serie of blog posts about various aspects of Mozilla Community Theme, but for those of you who want to dig on your own you can just start reading wiki.mozilla.org/MCS documentation.

Logo

The very first element of the new theme is a Mozilla Community logo. The logo is a new element that we hope will become a unifying element of all community building efforts. We spent a lot of time thinking about how to license it and I believe the result is a very relaxed policy that allows you to do whatever you want with the logo, while leaving us ability to block malicious use.

The logo may be used by any community that wants to express its relationship with Mozilla project. We do not try to create a new brand out of it, we try to give you ability to show what you stand for. In result the logo can even be modified (!) to adjust it to your website, but please, try not to overuse this power. The logo means something and I believe its extremely cute, but can be easily devaluated by misuse.

Theme

Mozilla Community Theme is an open source theme (the sources will be provided soon) that provides polished and high quality solution for anyone willing to start a new community website but lacking designer skills.

We provide highly customizable theme that can be used in different color palettes, with different backgrounds, layouts and widgets. The theme was created basing on dozen of current community websites with an intention to match all major components of those websites. It is possible to take the theme as it stands and use it for your website without changing a single line, but if you want you can modify everything. Its up to you and the further you go from the original design, the more you’re on your own in terms of quality

Example implementation

The theme itself is a huge step forward, but the real benefit only starts there. As a part of MCT we provide ready to use implementations of the Theme in several forms.

The very first form is a clean XHTML/CSS/JS mockup which presents the semantic structure of the website and its style documents.

Another is a PHP version, which may look similar but provides an example of how to use several tools and deploy the theme into PHP application.

At the moment Builder is pretty rough, but it already allows to create tens of versions of the theme. Ability to generate custom color palette (select custom and type any HEX RGB color) makes the amount of possible result infinite. In the future Builder should be able to provide more features and layout options.

App implementations

In a few days I will release first Theme implementations - wordpress and mediawiki, and drupal should follow shortly. The app implementations will not only contain the theme itself but also set of extensions that will provide unified set of features across multiple applications (think: OpenID, Single Sign On). We will also work on adding unique Mozilla related extensions that will allow your website to present the data directly from websites like QMO, SUMO or MDC.

MCS Admin Panel

The last step will be to provide single admin panel for installing/updating Mozilla Community Theme powered applications to run a complete website. The panel should allow someone with no prior experience in running a website to painlessly install and maintain his website, learning with no rush how the whole thing works.

Now it is YOUR time!

Working on such project inside Mozilla has, among others, one more benefit. I’m surrounded by web experts. Every single person who is reading this blog post has some unique knowledge and experience with coding HTML/CSS/JS or usability or accessibility or cross-culture design. Everyone can take a look at the sources provided with the whole implementation and find all the bugs I made and all those stupid mistakes. You can help make this project better.

My dream is to have this theme be a pure example of excellence in HTML/CSS/JS website development. Clean, modern code, flexible beyond recognition. During those two months I probably missed many opportunities to get nearer to my goal. Many elements may be not polished or may require some patience and love. If you think you found something like this, you probably did. So please, take a moment to share the feedback.
If you find the project interesting, and have some experience with web development, themes/extensions for Wordpress/Drupal/phpBB/punBB/MediaWiki and want to help, email me (zbraniecki _a_t_ mozilla dot com) please. I could use some help

Credits

I would like to thank people who have helped me with this project. Especially Seth for an incredible patience and support in removing road-blockers, and The Royal Order of Design for a great design they prepared

Also, Szymon Piłkowski contributed first round of reviews, Wojciech Szczęsny provided initial insight into IE6 compatibility (not ready yet) and Szymon Błaszczyk contributed first usability review.

Plans

After getting the first round of feedback, I will remove “beta” from the release status, tag it and call it official. You can take it today and start using right away, but there may be some changes in the CSS basing on the volume of bugs discovered by peers.

During next days (after some christmas rest with my family)  I will be working on finalizing wordpress implementation (you can take a look at the current status) and mediawiki. I will also shed some light on the PHP code I wrote for this project and present you CSSLib and Style class.

Finally, I hope to spend some time discussing with you your feedback and implementing fixes to the code and helping first brave souls implement it for their new community websites!

So… how do you like it?

p.s. if you have ideas you would like to see, or you would like to work on, contact me or list them on the MCS:Brainstorm page.

December 25, 2008 12:46 PM

The Comodo fiasco is pretty depressing. We have a CA Policy that states we’ll might do something in situations like this, but Mozilla’s hands are pretty tied unless all browser vendors agree to remove Comodo. This inability to act is also the reality with EV certs, there’s just more flare in the UI.

Having to depend on coordinated action by competitors and certificate authorities is not a good situation to be in. Maybe we’ll learn some day.

December 25, 2008 01:11 AM

I don't know what's happened, but for some reason, but in just the last month or so, we've fixed almost every single long-term performance problem, security issue, and common support issue in Bugzilla. All of the sudden we've been really productive on attacking things that have been sitting around for just too long.

I suppose here's what happened:

1. We got out the Bugzilla 3.2 release, so we didn't have all our attention on that anymore.
2. Our architecture is finally at a point where it doesn't occupy all our attention just to maintain Bugzilla, and we're also not spending all our time fixing the architecture. So now we can actually focus on cleaning up all of this old "dirty laundry".
3. I finally started applying The Feature Acceptance Test to Bugzilla, which woke me up and suddenly made it really easy to prioritize things and realize what I need to focus on fixing. "Oh, what blocks Bugzilla from helping people fix bugs?", "Which of these features will most help people fix bugs?"--just asking these questions made it really easy for me to suddenly have a workable priority list.

Anyhow, whatever the reasons are, I'm really happy that we're doing it and I hope it keeps up! :-)

-Max

December 24, 2008 07:31 PM

Slashdot is a-buzz (and rightly so!) with news that people have been able to obtain an SSL certificate for a domain they don’t own, by applying with one of Comodo’s certificate resellers. It is clear that there has been a major breach of trust, but we’re not sure of the best general solution. There has been a discussion in the mozilla.dev.tech.crypto newsgroup about what steps Mozilla should take for this breach.

In the meantime, I recommend disabling the root certificate used by this certificate authority, to avoid the possibility that other fraudulent certificates are floating around in the wild. Here’s how to disable the relevant CA root in Firefox:

1. Open the preferences window
2. Select the “Advanced” tab
3. Select the “Encryption” sub-tab
4. Choose “View Certificates”
   

5. Find and select the “AddTrust AB / AddTrust External CA Root” item
6. Choose the “Edit’ button
   

7. Remove all trust setting check-boxes.
   

Note: disabling this root certificate will SSL websites validated by this Comodo reseller to stop working. That’s why you’re doing it, but if it’s your favorite website that stops working, please don’t blame me! If you’re really paranoid, you could also disable all Comodo roots: these include all the certificates with names like “AddTrust”, “Comodo CA Limited”, and “The UserTrust Network”.

Thanks to Eddy Nigg for first providing these instructions.

December 24, 2008 06:27 PM

December 24, 2008 12:22 PM

To all my readers a very merry Christmas! Enjoy the time off, your loved ones’ company, the good food, and everything else there’s to enjoy about Christmas!

December 24, 2008 10:55 AM

December 24, 2008 04:00 AM

December 24, 2008 04:00 AM

I gave my new fuzzer a break from testing TraceMonkey by asking it to look for differences between SpiderMonkey and JavaScriptCore. I have listed them below, with SpiderMonkey output above JavaScriptCore output.

I have no idea how many of these are bugs (in SpiderMonkey or JavaScriptCore) and how many are ambiguous in the spec (intentionally or unintentionally).

Early error reporting

SpiderMonkey reports some errors at compile time that JavaScriptCore only reports at run time, if the code is actually hit. The difference is most obvious (and most likely to cause compatibility problems) if the code is skipped.

> if (false) { --1; }
S: SyntaxError: invalid decrement operand
J: (no error)

> if (false) { return; }
S: SyntaxError: return not in function
J: (no error)

instanceof

The two engines disagree about what objects are reasonable operands for the 'instanceof' operator.

> ({} instanceof {a:2})
S: typein:3: TypeError: invalid 'instanceof' operand ({a:2})
J: false

> ({} instanceof eval)
S: false
J: Exception: TypeError: instanceof called on an object with an invalid prototype property.

new with native functions

SpiderMonkey allows the "new" operator to be used with some native functions that JavaScriptCore considers non-constructors.

> new Math.sqrt(16)
S: 4
J: Exception: TypeError: Result of expression 'Math.sqrt' ... is not a constructor.

> new ({}.toString)
S: [object Object]
J: Exception: TypeError: Result of expression '({}.toString)' ... is not a constructor.

> new eval
S: typein:9: EvalError: function eval must be called directly, and not by way of a function of another name
J: Exception: TypeError: Result of expression 'eval' ... is not a constructor.

Converting between numbers and strings

> print(+'\00000027')
S: NaN
J: 0

> (1e-10).toString(16)
S: 0.000000006df37f675ef6ec
J: 0

const

There are subtle differences in handling of this new keyword.

> const d; const d;
S: TypeError: redeclaration of const d
J: (no error)

> const c = 0; print(++c);
S: 0
J: 1

Other differences

> print((function(){return arguments;})());
S: [object Object]
J: [object Arguments]

> typeof /x/
S: object
J: function

See Mozilla bug 61911, which changed this in SpiderMonkey in 2007.

December 24, 2008 03:57 AM

As an early holiday-season gift, here is a video and working version of an experiment in making Ubiquity usable with only the mouse. It draws heavy inspiration from our work on Firefox Mobile, with sliding, light-weight controls accessible to the side of the page.

There’s a lot of work left to be done, and a number of explicit open questions that we’d love help brainstorming on. More on that after the video.

Mouse-Based Ubiquity

One thing to keep in mind while you watch the movie is that these moused-based Ubiquity commands are exactly the same as the linguistic versions of the Ubiquity commands. Not even a single code tweak was required to get them running!

Thoughts

The Badge Action: Selecting a block of text causes the Ubiquity action badge to be displayed. As Jethro Larson mentioned in the comments of a previous mouse-based Ubiquity post, the downfall of most select-and-badge interfaces is that they are remarkably distracting. To combat this problem, we made the badge transparent enough to be neither distracting nor annoying (this has the benefit of enabling the text beneath the badge to be easily readable). At the same time, the badge is opaque enough to be noticeable. When you hover the mouse over the badge, it becomes fully opaque.

We played with various methods of making the badge feel less in-you-face: We tried having the badge fade in after a short time, as well as decreasing the opacity the further the mouse went away from the badge. Both ended up being more distracting than the simple roll-over. There was simply more animation cluttering the visual landscape — and that inevitably attracted the eye.

Open question: How to invoke mouse-based Ubiquity without first making a selection? (This is especially needed for commands like Twitter, Weather, etc.)

The Slide: Clicking the badge slides the entire page over, revealing the Ubiquity area. It’s a fast, context-keeping interaction: It’s immediately obvious how to get back. The slide time also gives enough time to make a quick network call, so that the browser feels clairvoyant and super-speedy as you rarely feel like you are waiting. (In the future, it makes sense to prefetch results as soon as a selection is made.)

This gets us to the Open Question: Should the pane be on the left side or right side? Top or bottom? Also: How should we handle scrolling while the pane is open?

The Ubiquity Pane: The layout is entirely in-flux. We’ll need a command form area, a preview area, and command-selection area. Besides that, it’s blue sky thinking. My hunch is that a mix of a grid menu, tabbed toolbar menu, and a search/filter is the right way to go (see picture below). Open Question: How to lay out the Ubiquity pane?

Play With It

You can subscribe to the experimental mouse-based Ubiquity just like every other Ubiquity command. That’s because it is just a Ubiquity feed.

Usage: Use the “setup” command on any page where you’d like to try out the experimental mouse-based Ubiquity. Then just select some text, and click the badge.

Update: As many folks pointed out (in particular David and Amad), I forgot to include the badge image, which meant nothing would happen when text was selected. I’ve fixed the problem — many apologies!

December 24, 2008 02:04 AM

Making JavaScript faster is important for the future of computer security. Faster scripts will allow computationally intensive applications to move to the Web. As messy as the Web's security model is, it beats the most popular alternative, which is to give hundreds of native applications access to your files. Faster scripts will also allow large parts of Firefox to be written in JavaScript, a memory-safe programming language, rather than C++, a statically typed footgun.

Mozilla's ambitious TraceMonkey project adds a just-in-time compiler to Firefox's JavaScript engine, making many scripts 3 to 30 times faster. TraceMonkey takes a non-traditional approach to JIT compilation: instead of compiling a function at a time, it compiles only a path (such as the body of a loop) at a time. This makes it possible to optimize the native code based on the actual type of each variable, which is important for dynamic languages like JavaScript.

My existing JavaScript fuzzer, jsfunfuzz, found a decent number of crash and assertion bugs in early versions of TraceMonkey. I made several changes to jsfunfuzz to help it generate code to test the JIT infrastructure heavily. For example, it now generates mixed-type arrays in order to test how the JIT deals with unexpected type changes.

Andreas Gal commented that each fuzz-generated testcase saved him nearly a day of debugging: otherwise, he'd probably have to tease a testcase out of a misbehaving complex web page. Encouraged by his comment, I looked for additional ways to help the TraceMonkey team.

JIT correctness

Last month, I wrote a new fuzzer designed to find correctness bugs. It runs a randomly-generated script in two JavaScript engines (in this case, SpiderMonkey with and without the JIT) and complains if the output is different.

It quickly found 13 bugs where the JIT caused JavaScript code to produce incorrect results. These bugs range from obvious to obscure to evil.

It even found two security bugs that jsfunfuzz had missed. One was a crash that involved a combination of language features that jsfunfuzz doesn't test heavily. The other was an uninitialized-memory-read bug, which caused the output to be random when it should have been consistent. jsfunfuzz missed the bug because it ignores most output, but the new fuzzer interpreted it as a difference between non-JIT and JIT output and brought the bug to my attention.

JIT speed

I set up the new fuzzer to compare the time needed to execute scripts and complain whenever enabling the JIT made a script run more slowly. It measures speed by letting the script run for 500ms and reporting the number of loop iterations completed in that time.

So far, it has found 4 serious bugs where the JIT makes scripts several times slower. Two of these have already been fixed, but the other two may be difficult to fix.

It has also found 10 cases where the JIT makes scripts about 10% slower. Most of these minor slowdowns are due to "trace aborts", where a piece of JavaScript is not converted to native code and stays in the interpreter. Some trace aborts are due to bugs, while others are design decisions or cases for which conversion to native code simply hasn't been implemented yet.

There is some disagreement over which trace aborts are most likely to affect real web pages. I asked members of Mozilla's QA team to scan the web in a way that can answer this question.

Interpreter speed

Mostly for fun, I also looked to see which code the JIT speeds up the most. Here's a simplified version of its answer:

for (var i = 0; i < 0x02000000; ++i) {
  d = 0x55555555;
  d++; d++; d++; d++; d++;
}

This code runs 250 times faster when the JIT is enabled. The JIT is able to achieve this gigantic speedup due to the interpreter being inefficient in dealing with undeclared variables and numbers that can't be represented as 30-bit ints.

Assertions

The JavaScript engine team has documented many of their assumptions as assertions in the code. Many of these assertions make it easier to spot dangerous bugs, because the script generated by the fuzzer doesn't have to be clever enough to actually cause a crash, only strange enough to violate an assumption. This is similar to my experience with other parts of Gecko that use assertions well.

Other JavaScript engine assertions make it easier to find severe performance bugs. Without these assertions, I'd only find these bugs when I measure speed directly, which requires drastically slowing down the tests.

More ideas

One testcase generated by my fuzzer demonstrated a combination of a JIT performance bug with a minor bytecode generation bug. I might be able to search for similar bytecode generation bugs the same way I searched for decompiler bugs: by ensuring that a function does not change when round-tripping through the decompiler. In order to do that, I'll need a new patch for making dis() return the disassembly instead of printing it.

I should be able to find some performance bugs by looking at which aborts and side exits are taken. This strategy would make some performance bugs (such as repeatedly taking a side exit) easier to spot.

December 24, 2008 01:48 AM

After uploading a 2.0 Alpha 2 version of LCARStrek about 10 days ago, I now could also update my EarlyBlue theme for SeaMonkey 2.0 Alpha 2 a few minutes ago, at the right time to hand them to the Mozilla community as Christmas presents.

On AMO, you need to log in to get those versions from the sandbox - alternatively, my KaiRo.at theme downloads page offers them without login.

As said before, the tri-licensed source of the themes is available from my public git repos.

December 23, 2008 11:29 PM

This is the 1st post in my MoFo Futures 2009 blog series. | Post 2 »

Christmas is nearly upon the Christian and Consumerist parts of the globe. Along much of my latitude, snow is piling up in record quantities and weather warnings abound. Even in oft-green Vancouver, there is a foot or so of the white stuff accumulated in my yard and the parking lot outside my window often echos with the sounds of snow-beached cars helplessly spinning their wheels.

Usually all these things taken together would mean a series of harrowing drives to visit family, followed by lovely hours staying warm indoors, eating comfort food, retelling old stories and enjoying the company of loved ones as the year draws to its close.

However, this year our family time is coming after the holidays and I'm left with the unexpected gift of a week or so of free time.

Another unexpected thing is the current state of the Mozilla Foundation. Over the last few months of the year, we've worked particularly hard to be good little Mozilla folks. We've planned, plotted and schemed; brainstormed, drafted and designed; tacticated, calculated and strategized. We've been thinking so hard that we've had to conjugate verbs in ways you've never even heard of. From all of this, I expected Mozillaclaus to deliver some mighty fine presents: namely, a Mozilla Foundation 2009 roadmap and vision that our board approves and that all MoFo staff subscribe to. Instead, we got the early surprise of an IRS audit during the worst global financial crisis since the Great Depression. (For more commentary here, see Mitchell Baker's Sustainability in Uncertain Times blog post.)

Early surprises aside, I'm still totally jazzed about the work of the last few months. Rather than be focused on the lump of coal in our stocking and mope through the holidays, I'm going to instead spent the time blogging about some of the thinking that's been going on at the Mozilla Foundation and in my head over the last three months. Much of my blogging will focus on the ideas that I've been developing or championing, as I can't easily speak for the rest of the team when it comes to matters such as this. Also, some of these ideas are more half-baked than others - think of the posts as thought experiments or brainstorms. If you like an idea, let me know. If you hate an idea, let me know. If you can give constructive input, that is best of all.

Happy holidays folks (and remember, only two shopping days left till Christmas. ;)

This is the 1st post in my MoFo Futures 2009 blog series. | Post 2 »

December 23, 2008 11:09 PM

Hi,

i will attend the 25c3 Congress in Berlin next week, so let me know when you are around!
and also Happy Holidays everybody!!

- Tomcat

December 23, 2008 11:06 PM

Hi,

about a week ago we pushed the new Quality.mozilla.org (QMO) live !

Its the new and improved home of Mozilla QA, where you can get information how get involved into QA, about our Events like Testdays and Bugdays and also about the Tools we use.

We are working on creating more content and doc’s.

I hope you like the new QMO !

- Tomcat

December 23, 2008 09:53 PM

Axel Hecht already wrote about it, and herein is another reminder that there will be a big Mozilla presence again in Brussels on February 7-8 for the Free and Open Source Software Developers European Meeting (FOSDEM). Bonus points

if you can say that mouthful 10 times in a row. If you have never been, believe me when I say it a unique experience and highly eventful and enjoyable.

But my real motivation is to solicit session proposals for the Mozilla room. We’re leaning towards more dev talks and less l10n this year, but that by no means rules out a super hot l10n proposal. We are open to all aspects of the community, technical or otherwise. For example, John Slater has put forward a great proposal on ‘Building Mozilla’s visual design community’. We have still not chosen the speaker/topic list, so you still have time to put forward your proposal. To do so, go over the wiki proposals page and add in your idea, and the main FOSDEM page has more general information. If you have any questions, you can contact me via the comments or from this page.

Enjoy the holidays, over and out.

Related articles by Zemanta

• The annoyances of proprietary Firefox extensions

December 23, 2008 09:26 PM

…and they’ve chosen Moises Lara as the winner of Mozilla México’s logo design contest. In addition to being a very cool logo (I love the Aztec-ish interpretation of the Mozilla dino), it’s a great example of what’s possible when we harness the power of our design community. Kudos to Moises, Mozilla México and everyone who voted for making it happen.

December 23, 2008 09:13 PM

Fennec Alpha 2 is out! The emphasis for this release was on performance and responsiveness, and that focus has resulted in much faster and more natural-feeling interactions.

You can get instructions and a download via the release notes. If you don't have a Nokia n810, desktop versions are available too (Windows, OS X, Linux).

For a quick introduction, I've recorded a short video walkthrough of alpha 2:

Fennec Alpha 2 Overview from Madhava Enros on Vimeo.

For more information on what's new and what's underway, there are a number of other blog posts related to alpha 2:

• Taras Glek on Alpha 2 performance
  
• Mark Finkle on what's new in the front end
  
• Jono DiCarlo on Weave in Fennec
  
• Stuart Parmenter announcing the release
  

Please tell us what you think, or, better yet, get involved!

December 23, 2008 08:31 PM

December 23, 2008 07:45 PM

Static Analysis vs Performance

Two months ago I got the feeling that I gotta take a break from static analysis and do something that obviously affects Firefox at runtime. Luckily that coincided with ramp-up on Fennec performance work.

I find that I enjoy fixing existing code a lot more than other sorts of programming, so I was extremely happy to switch focus from the static analysis way of fixing code to my other favourite: optimization. Both are peculiar programming endeavours because after a bunch of gruntwork the program ends up doing the exact same thing as before, but better.

In static analysis I focus more on how different pieces fit together, whereas in an optimization I get to focus on what various pieces are trying to achieve so I learned a lot more random Mozilla mysteries.

Fennec

Fennec is pure joy to optimize because it runs in such a constrained Linux environment (compared to desktop Linux). Things seem to happen roughly 10x slower on the arm processor than on my core2duo laptop. Thus performance details that are hard to spot on the desktop almost trivial to discover.

There is no hard drive seeks to introduce unpleasant surprise latency. This simplifies things a lot - there is a lot less variance between hot and cold start on n810 than on hard drived desktop.

Unfortunately the N810 linux environment also leaves a lot to be desired. Compiling stuff is a chore. It turns out the oprofile produces nonsense results when a compiler of recent vintage is used (ancient one cant really compile Mozilla).

I had a lot of fun digging deep into Mozilla code and dealing with mischievous timestamps, misbehaving caches and rude GC interruptions. All this was done using stone-age instrumentation techniques on N810.

Mark Finkle blogged some details on Fennec Alpha2 performance. Alpha2 is magnitudes faster than Alpha1, I expect more of the same in subsequent releases.

Software Improvements That  Santa Claus Should Get Me

Even though oprofile is useless on N810, one can get a pretty good idea of what the performance issues are from running it on x86. OProfile is a little rough to use, but I’ve learned to love it when sugared with gprof2dot and xdot. It’s great for locating places in the code to stick printf()s into.

OProfile has taught me that what I really want is Dtrace (or some knockoff) running on n810.

Also, I really hate how embedded Linux takes away one of coolest things about Desktop Linux: ability to compile own kernel. I haven’t been able to get a more modern kernel to run on N810 which means I can’t try a newer version of oprofile or the new omap high res timers. I would also like to get a working image of N810 under qemu, but success has avoided me there too.

Static Stuff

Unfortunately I found that can’t effectively work on static analysis stuff without giving it my full and undivided attention. Right now I’m hoping to set aside time to focus on writing a more general dead code finder and catch up on other misc things sometime in Janurary or February.

December 23, 2008 07:23 PM

In this issue…

• Mobile Firefox (Fennec) alpha 2 released
• Firefox 3.0.5 and 2.0.0.20 now available
• “Fox For All” wins Impact Mozilla
• Camino 1.6.6 released
• Fireunit, testing in the Firebug world
• Firebug in Firefox 3.1b2 and beyond
• JSON explorer for Firebug
• New Mozilla design community mailing list
• Localization Testing and QA survey
• Interview: Mozilla Weave project lead
• Quality Assurance community site now in beta
• Automatic project creation coming to Mozdev
• New Firefox feature videos on mozilla.com
• Last issue of 2008!
• Developer calendar
• Subscribe to the email newsletter

Mobile Firefox (Fennec) alpha 2 released

Stuart Parmenter writes, “We’re happy to announce that our second alpha release of Fennec has come together. While we focused much of the previous alpha on getting the user experience how we wanted, we’ve spent much of the time since focused on improving performance. We’ve made major strides improving startup performance, panning and zooming performance, and responsiveness while pages are loading. We’ve refactored a significant amount of the front end code resulting in substantial speed improvements as well as providing a much better base for extension authors to build upon.”

Additionally, the Fennec team has released desktop versions of mobile browser as they did with Fennec alpha 1, which you can download for Windows, OS X, and Linux. These builds allow content and extension authors to experiment with the mobile browser on their desktop. Release notes are available for Fennec alpha 2, with information on how to install the browser, what’s new, known issues, and how to provide feedback. Further information can be found in Stuart’s original announcement.

Firefox 3.0.5 and 2.0.0.20 now available

As part of Mozilla Corporation’s ongoing stability and security update process, Firefox 3.0.5 and Firefox 2.0.0.20 are now available for Windows, Mac, and Linux. Mozilla is not planning any further security and stability updates for Firefox 2, and we recommend that you upgrade to Firefox 3 as soon as possible. Additionally, the Phishing Protection service will no longer be available for Firefox 2 users. Firefox 3 offers a new and improved Phishing and Malware Protection service, so again, we strongly urge you to upgrade to Firefox 3. You can download Firefox 3 at GetFirefox.com

“Fox For All” wins Impact Mozilla

Mozilla is proud to announce “Fox For All” as the grand prize winner of Impact Mozilla. “Fox For All” was authored by Phani Kumar Vadrevu and Uttam Byragoni of India. “We’re extremely grateful to all ten finalists. The degree of hard work and the diversity of ideas contributed by the teams far exceeded all expectations. Impact Mozilla also succeeded in reaching out to groups not traditionally part of the Mozilla community (e.g., MBA students).” More information about the wrapping up of Impact Mozilla can be found at the Mozilla Blog.

Camino 1.6.6 released

The Camino Browser team has just released Camino 1.6.6, a maintenance release which contains various security and stability updates. All Camino users are urged to update. In addition, Camino 1.6.6 is now available in the following languages: Catalan, Czech, Dutch, English (US), French, German, Italian, Japanese, Norwegian (Bokmal), Polish, Portuguese (Brazillian), Russian, Spanish (Castellano), and Swedish. You can download Camino at CaminoBrowser.org.

Fireunit, testing in the Firebug world

Jan Odvarko and John Resig have been working hard on a new Firebug extension called Fireunit. Fireunit provides a simple JavaScript API for doing test logging and viewing within a new tab of Firebug. Jan writes, “This very promising extension is intended as an automated testing framework for Firefox extensions and it should also be useful for testing web pages in the future. It’s still at the beginning, but growing and starting to be very useful for testing Firebug itself.” For more information, you can read Jan’s blog post and John’s blog post, and the extension itself is available at Fireunit.org.

Firebug in Firefox 3.1b2 and beyond

Rob Campbell has written a blog post where he clarifies some of the confusion that has been recently surrounding Firebug and its compatibility with Firefox 3.1. Not only is Firebug 1.2.1 not compatible with Firefox 3.1, neither is Firebug 1.3. “If you want to use Firebug with Firefox 3.1, you will need to use Firebug 1.4. Get the latest version from the releases directory and install it. No compatibility override required. Don’t let the alpha version tag frighten you, it’s really quite decent.” Details about the different versions are available on GetFirebug.com’s releases page.

JSON explorer for Firebug

In another bit of Firebug-related news, Jan Odvarko writes, “Thanks to Ashish Datta, Firebug has fresh new support for inspecting JSON in net responses. This feature allows you to see JSON formatted as an expandable tree of items and also explore them using Firebug’s Dom tab. The view is available within the Net panel and is visible as soon as a JSON request is expanded. This feature should be part of Firebug 1.4a11. Ashish is a senior at Tufts University and he did this work as part of his class focusing on open source development. It’s great to see how community around Firebug is growing and willing to contribute to this indispensible tool!” For more information see Jan’s blog post, and find out more about Firebug at GetFirebug.com.

New Mozilla design community mailing list

John Slater, part of Mozilla’s super fun marketing team, writes, “Following the successful examples of our developers, localizers, marketers, QA testers, etc we’re going to be making a major push to organize and grow our visual design community. I’ll share more details soon — including our plans to create a new site for posting and sharing your artwork — but if you’re curious to learn more the first thing to do is sign up for our new design mailing list.”

“Of course, there already is a Mozilla design community — just look at the 3,500+ people who participated in our Firefox 3 t-shirt design contest or Google around for Firefox art — but there’s so much more that can be done. This is an entirely new way we can put our greatest advantage to good use, and we should get a lot of cool stuff to look at, too. The possibilities are incredibly exciting.” For more information, see John’s post and sign up for the mailing list.

Localization Testing and QA survey

The l10n-drivers team recently launched a Testing and QA survey targeted at the localization community. The survey will remain open until December 26th. Stas Malolepszy writes, “Many localization teams have worked out their own practices and procedures regarding testing. So it’s natural that when Mozilla starts thinking about localization testing plans, we first look at what’s been already invented and proved to work well. There are many localization teams, each with their own way to test the localization, suited for their needs and resulting from their approach and past experience. What if we could share these practices between the localization teams and help other teams adopt them? This briefly summarizes the objectives of the survey.” If you are part of the Mozilla localization community and would like to help, you are strongly encouraged to take the survey. For more information, see Stas’ blog post.

Interview: Mozilla Weave project lead

Dan Mills, Lead Engineer of Mozilla Labs’ Weave project sat down with Aza Raskin for a brief chat. In this video he talks about what Weave is, what it’s good for, how it ties in with Firefox Mobile, when it will be in users’ hands, and what you can do to help. View the full video interview.

Quality Assurance community site now in beta

Jay Patel writes, “After over a year and a half of experimentation, discussion, design, development, and testing…I am proud to announce the launch of the ‘official’ QMO beta. While we used to rely on our team mailing list and the QA blog on mozillaZine, we now have a robust community website that I believe will help bring the Mozilla QA team and our growing community of volutneers together. We will be able to better collaborate to improve the quality of all Mozilla products and services, and QMO will provide a place for others to join us and learn more about Mozilla QA.” For more info, see Jay’s blog post, or head right on over to the new QMO website.

Automatic project creation coming to Mozdev

silfreed writes, “It’s been a long time coming, but your requests to speed up the project creation process are coming to fruition. Over the past couple of years there have been two major pain points in setting up new projects: tracking the requests to make sure they’re handled properly and actually creating projects. We finally have the tools in place to handle tracking the project requests and creating projects which should dramatically increase the response time of setting up new projects. We still have some work to do, but we’re well on our way to making those things happen.” Further details are available at silfreed’s weblog, and you can request a project at the Mozdev site itself.

New Firefox feature videos on mozilla.com

The Mozilla Blog reports, “We’ve launched a new video section on mozilla.com to help bring some of the many great features of Firefox alive. The feature-specific videos are narrated by the people who helped bring them to Firefox. The new video section even includes a walk through on how to install Firefox — perfect to help people make the switch.” The videos currently include: Firefox 3 overview, How to switch to Firefox with Asa Dotzler, Security features in Firefox 3 with Johnathan Nightingale, Bookmarks and tags with Alex Faaborg, and the Awesomebar with Seth Spitzer.

Last issue of 2008!

Just a quick reminder that this is the last issue of about:mozilla for 2008. We will resume our regular weekly schedule after the holidays, either January 6th or January 13th depending on how much news there is to report the first week back. Happy holidays to everyone, and a have a safe and happy new year.

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.

December 23, 2008 06:44 PM

What I did on the client side:

1. hg clone http://localhost:8000/af
2. make some changes on the checked out repo
3. add "default-push = http://localhost:8000/af" under [paths] in my checked out repo's .hg/hgrc file
4. hg commit -m "message"
5. hg push

To check the web interface and/or the pushlog of that repo browse to:

• http://localhost:8000/af
• http://localhost:8000/af/pushlog

My wish list:

I would like to be able to have the URL to look like:

• http://localhost:8000/l10n-central/af

so I could have things like:

• http://localhost:8000/releases/l10n-mozilla-1.9.1/af
  

but for now I believe that I am in good shape and that this improvement might actually require me to setup an apache server which I am trying to avoid.

December 23, 2008 06:18 PM

Just a note that I’ll be generally offline or away from the computers for the duration of the holidays. I’ll still check email and may even do a little coding for fun but IRC response may be sluggish, delayed and possibly drunk.

Happy Holidays everybody!

PS, to all my bearded brothers and sisters out there. Good work on the NSID. Peace.

December 23, 2008 05:40 PM

Fennec Alpha 2 is now available for download! Desktop versions are available too (Windows, OS X, Linux). While we added some good features in this alpha, the primary focus was performance. Faster startup. Faster page loading. Faster panning and UI interactions.

Faster, faster, faster!

Madhava made a nice video showing off Alpha 2. Even from the video, anyone who tried Alpha 1 can see that Alpha 2 is noticeably faster.

I thought I’d focus a bit on what we did to squeeze more speed out of Fennec, and the Mozilla platform in general. First, a big shout out to Taras Glek for finding slow spots and filing bugs to get them fixed. Taras worked tirelessly to find as many problem areas as he could.

Panning

Alpha 1 used a two layer system to implement panning. One layer panned the UI chrome - the URLbar, the tab sidebar and the browser control sidebar. Another layer, implemented in a XBL component, panned the web content. Both layers were children of a XUL <stack>, which allowed us to position and float elements relative to each other. The “hand-off” between the two systems - when UI panning transitioned to content panning - was sloppy and chrome panning was not very smooth.

Alpha 2 combines the panning layers into a single system, still contained in a <stack>. We removed the XBL component and now chrome and content pan together as a single unit. The result is much smoother panning. Also, the chrome UI parts are now located relative to the web content much better - in Alpha 1, the sidebars panned into view sooner than they should have.

I plan to cover more details of the Fennec architecture soon.

URL Autocomplete (Awesomebar)

We found that using <panel> elements to float chrome UI over the main window was a performance problem. In fact, any XUL element that creates a native OS window under the covers slows things down. The awesomebar autocomplete list uses a <panel>. We re-wrote the autocomplete list such that it was a <vbox> in the main <stack> and the results were dramatic. The list displays much faster.

URLbar

We started with XUL similar to Firefox for our URLbar. We used a <description> for the static caption and a <textbox> to allow the user to type in a new URL. The elements occupied the same space, but only one was visible at a time. We used some JS code to hide/show the appropriate element.

We found that the process of showing/hiding the elements was taking a noticeable amount of time, affecting the perceived page loading time. We ended up removing the <description> and we just toggle readOnly on the <textbox>.

Favicon Indicator

A similar situation occurred with the favicon indicator. We initially used the same <stack> holding two <image> elements - one for the throbber and another for the website’s favicon. Again, we were showing and hiding the images depending on situation. This time it was the <stack> that was the slow down - creates a native OS window. So we removed it and page loading appeared to complete a little faster. We kept the two image elements because the load time for the swapping the favicon image with the throbber image eclipsed any benefits of removing the show/hide code.

We also restructured the way we handled <link rel=""/> favicons to wait until the page fully loaded before updating the favicon indicator. Updating the indicator immediately, while the page was still loading, just caused the page load to take longer.

Canvas and Thumbnails

For panning and zooming performance, Fennec uses a canvas element as the main display surface - not a browser element. We copy the contents of the browser to the canvas. Updating the contents of a browser to a canvas is not cheap on mobile devices. Each drawWindow call can take ~300-400ms. On the other hand, drawImage is much faster - ~100ms. In Alpha 2, we switched to use drawImage as much as we could when updating the tab thumbnails.

Alpha 2 also uses the new MozAfterPaint event to optimize all DHTML updates to the the main canvas display surface. Whenever the contents of the web page changes, for whatever reason, we only update the areas that actually changed. We don’t repaint the entire canvas.

Post-Pageload Work

Any work that occurs after the page loads is potentially bad for performance. Users like to start interacting with page content as soon as possible. We had some slow code that transformed phone numbers into <a href="tel:555-123-4567"> links. The tel: links can allow devices to auto-dial telephone numbers. The code was optimized quite a bit in Alpha 2 (see bug).

File I/O

Various places in the platform code we found spots where file I/O was slowing Fennec down, usually on startup. As Taras said on IRC - “File I/O on the n810 is measured in milliseconds” - probably not just limited to the n810. So we tried to avoid useless I/O whenever we could. Startup improved from taking around 30 seconds (yes) for a first-time, cold start in Alpha 1 to around 7-10 seconds in Alpha 2. A warm start improved from taking around 13 seconds down to 4-5 seconds.

One spot in the Extension Manager code was checking for the existence of a file, which was never created unless you had extensions installed. That fix alone saved ~300ms during startup. XBL loading was also improved - saved 100-200ms during startup.

We still have more work to do - we are shooting for a ~3 second startup. Yes, we have already found several more changes we plan to make for the next release.

Wrapup

We made some significant improvements startup, panning and page loading. Take Fennec Alpha 2 for a spin, especially if you tried Alpha 1 and found it too slow.

The downside of the many changes we made, especially in the UI, will be extension breakage. Giorgio Maone, author of NoScript already discovered some breakage, but plans to have an updated version ready soon. Unfortunately, we will likely cause more breakage with the next release too. However, my hopes are that by soliciting feedback from the add-on developer community, we can get a stable XUL structure and JS API in place for the next release.

December 23, 2008 05:30 PM

Thanks to a tremendous effort by Wil Clouser, it is now possible to localize the SUMO (support.mozilla.com) site UI using Verbatim. For those unfamiliar with Verbatim, it’s an online translator tool for various Mozilla projects, including addons.mozilla.org. It’s designed to be easy to use, encourage help from casual contributors, and provide a clear overview of the translation progress.

The addition of SUMO support means that localizers can use Verbatim to translate the site’s UI rather than using the somewhat clunky built-in interface on SUMO itself. Note that this is strictly for UI localization, not for translating Knowledge Base articles. That’s still done by clicking on the “Translate this page” link on actual articles.

Here’s how the dashboard looks like for SUMO:

Verbatim is still in alpha, but if you want to test this out, please drop by at #verbatim on irc.mozilla.org right now and ping clouserw to get permissions (in Verbatim) to modify SUMO.  The actual translation process is still being worked on, but it’s already possible to start translating strings that will show up on the SUMO website once we import the changes (which will probably happen monthly).

December 23, 2008 04:57 PM

This upgrade should have little impact. I've upgraded the OS X builder responsible for the daily dep builds as well as the nightlies to XCode 2.5. This is a minor upgrade, and was necessary to enable full dwarf-2 debugging support in the upcoming builds.

See bug 468622 for the details.

December 23, 2008 03:44 PM

A couple of weeks ago, Chris Anderson (from TED fame) made a great speech in Paris about the Web, its dangers and its promises. Chris described the Web as a "giant brain", which had a "global IQ". The video is now available to the public.

In his conclusion – while showing a picture of kids in Pakistan (where Chris was raised), kids getting little access to education – Chris explained that the mobile Web could give access to the knowledge and education in ten years from today.

Chris' final sentence was:

If you are working on something who's going to boost global IQ, I salute you, because what you're doing is a gift of love to these children and to all of us.

This sentence did resonate a lot for me. While we, at Mozilla, do not solve World hunger not cure cancer, we're part of this wonderful thing we call the Web, and we are actually "boosting the global IQ", by enabling people to participate the way they can, where they are. We're helping people use the Web, but also build the Web. In this regard, I think we, at Mozilla, do boost the global IQ, even if it's at a tiny level. We should be proud of this.

December 23, 2008 03:28 PM

Editor’s note: Mozilla announced the release of Fennec alpha 2, an early developer release of the mobile version of Firefox, on Monday, December 22, 2008.  See Engineering Manager Stuart Parmenter’s comprehensive post for more details, excerpted here:

We’re happy to announce that our second alpha release of Fennec has come together.  While we focused much of the previous alpha on getting the user experience how we wanted, we’ve spent much of the time since focused on improving performance.  We’ve made major strides improving startup performance, panning and zooming performance, and responsiveness while pages are loading.

The release notes have information on a quick start, how to install, what’s new, known issues and how to provide feedback. So if you’re interested in getting involved with Mozilla Mobile, install Fennec and tell us what you think.

Congratulations to the entire mobile team!

December 23, 2008 03:11 PM

Fennec Alpha2 is out, breaking compatibility with NoScript up to 1.8.7.7 because of a change in the Browser object hierarchy.
If you’re using NoScript on Fennec (or you want to give it a try), please get the NoScript 1.8.7.8 development build.
A stable AMO release should follow in one day or two. upgrade to NoScript 1.8.8

December 23, 2008 12:59 PM

Attendees: djst, cilias, zzxc

Sumo

• Weekly metrics
  • Lots of KB updates in part because of our friend Bo!
  • Would be interesting to see how many locales are being edited per week
  • djst to add a wiki page with the metrics we’d like to collect in the automatic dashboard
  • Bug with the bottom understandable articles list — different top articles depending on how many articles you display in the list. cilias to file bug.
  • Significantly lower bounce rate on both start pages. No good explanation; normal start page got an updated top issues lust, but what about the inproduct start page?
• Last week’s weekly support issues
  • Got crash logs from Live Chat for Google Desktop. zzxc to attach to relevant bugs.
  • Got lots of feedback from new users of Firefox 3. Top confusions:
    • After clearing history, things still showing up in Awesome Bar. The question is how much impact the addition of the Privacy preferences in 3.1 will have if people don’t understand what they’re seeing.
      • Ideas on how we can reduce the confusion users are experiencing; djst proposed a “notification bar” inside the Awesome Bar that would appear when there is no history, notifying the user that the list still list bookmarks, with info on how to change that behavior. That could hopefully make it more obvious to the user that the Clear Private Data feature isn’t broken.
    • People are confused by the UI for adding a bookmark to a specific folder. Needs to click two small arrow buttons to select sub-folders (one to show folder selection, and another to expand a parent folder).
      • zzxc to summarize the feedback
• Start page layout looks crappy [1]

2008 review

• We’ve come a long way since the beginning of 2008:
  • From en-US only Knowledge Base to over 20 active locales
  • Moved in-product help to web based help on SUMO
  • From launch of Live Chat to over 20 active helpers per month
  • 50 active SUMO contributors per week
  • Helping at least 30,000 users of Firefox every month (these are people that actively said “yes, this solved my problem”)
  • Robust metrics about common issues in Firefox reported to QA/dev teams every week
• Room for lots of improvements in 2009:
  • Performance is a top complaint among contributors — top priority in Q1 2009
  • Better communication with members of the SUMO community. Personal outreach, e-mail, Skype meetings, etc. The SUMO community is part of something really important that ties into everything else that we do at Mozilla; we need to communicate that. MozillaCMS is interesting for SUMO.
  • Dig deeper into our data — need an automated metrics dashboard for the weekly metrics so we can focus on digging deeper
  • Preliminary 2009 roadmap is up on the wiki [2]

Knowledge Base

• Private Browsing article is up
• Lots of updates for 3.1 content
  • Big thanks to our friend Bo, who has been doing most of the updating!
• In Firefox meeting I asked about what is being about Smart Location Bar
  • Drop-down setting in Privacy panel to set suggestions to “History and Bookmarks”, “History”, “Bookmarks”, or “Nothing”.
  • UI was recently put in nightlies, but pref |browser.urlbar.search.sources| has been in about:config for a while. It should be in Beta 2.

Live Chat

• Contribution way up with the 3.0.5 release, total chat sessions almost doubled
  • 10 new accounts last week, out of which 5 helped with at least one chat
  • New account approvals: mindstormskid, tom06, listerofsmeg, mcgiwer, dan
  • New room monitor. Welcome to the team, Tanner!
• Live Chat CSAT is now collecting data. Several users have replied to us in the forum using the forum link on the CSAT page.
• Limited hours this week due to holiday

Roundtable

• Thanks for a fantastic year and Merry Christmas to the SUMO community!
• Meeting as usual next Monday

December 23, 2008 12:55 PM

December 23, 2008 06:01 AM

December 23, 2008 05:53 AM

December 23, 2008 04:00 AM

In my previous blog post I created the following:

• a single local repository with a web interface plus pushlog
  

and in this blog post, I will show you what I did to create:

• multiple local repositories with a web interface without pushlog

NOTE: I read this page which has much more information: "Publishing Repositories with hgwebdir.cgi" even though I do not use that file at all

These are the steps I followed:

1. sudo mkdir -p /var/hg
2. sudo chown -R armenzg /var/hg
3. sudo cat <
4. /var/hg/hgweb.config
   [collections]
   l10n-central/ = l10n-central/
   MARKER
5. mkdir l10n-central
6. hg init l10n-central/af
7. hg init l10n-central/de
8. hg serve --webdir-conf hgweb.config

You can now do this:

$> hg clone http://localhost:8000/af
or
$> hg clone http://localhost:8000/af

December 23, 2008 03:17 AM

Mozilla is proud to announce “Fox For All” as the grand prize winner of Impact Mozilla.  “Fox For All” was authored by Phani Kumar Vadrevu and Uttam Byragoni of India.

In total, more than 5,000 people cast a vote for their favorite plan.  While “Fox For All” received the most votes, there were several finalists who finished as close runners-up: “How Do You Firefox?” finished in 2nd place (Chicago Booth student team), “Surf On Your Own Turf” finished in 3rd (Haas business school student team), and “My Firefox” by Bruno Fleurquin of France came in 4th.

We’re extremely grateful to all ten finalists.  The degree of hard work and the diversity of ideas contributed by the teams far exceeded all expectations.  Impact Mozilla also succeeded in reaching out to groups not traditionally part of the Mozilla community (e.g., MBA students).

So, where do we go from here?

With respect to our winner, we’ll soon start engaging with Phani and Uttam to discuss possibilities for the implementation of their plan.  For our other finalists, we’ll be sending out swag as a token of our appreciation.  Impact Mozilla has been a wild success, and it couldn’t have happened without the enthusiasm of the community and strong efforts by all participants.

December 23, 2008 12:41 AM

Ubiquity 0.2 is on the table for release in the very near term future. We’re talking weeks away. But, what is it? We sat down with Atul Varma, the lead developer of Ubiquity (among other things), to talk about the major changes underway.

What’s up with Ubiquity 0.2?

How To Help

The main way to help is by joining in the process of getting Ubiquity 0.1.3 out the door. Features are frozen but there are still some bugs left to quash. The full list is here.

There’s lots of things you can do to help:

If you don’t know how to code

Get the latest Ubiquity 0.1.3 release candidate to verify some of the bugs and help figure out under what conditions they occur. We could also use some people to just download the release candidate and bang on it, to find any bugs lurking in the shadows; if you find one, please feel free to file a ticket for it.

If you know how to code, feel free to assign a bug to yourself and submit a patch that fixes it. Join us on #ubiquity on irc.mozilla.org if you have any questions or want to discuss solutions with our core developers.

As soon as these are finished, we should be able to get 0.1.3 out the door, which will drastically improve the speed of Ubiquity and make it a lot prettier.

December 22, 2008 09:35 PM

December 22, 2008 07:50 PM

A lot of people are talking about the interview with John Lilly that discusses the relationship between Mozilla and Google.

People like to paint think black and white. Either Mozilla is Google’s poodle (Mozilla is to Google as Tony Blair was to George Bush) or there is a falling out and they hate each other.

Of course, the answer is grey as John points out. From my standpoint, focusing on the Open Web, I see more areas to collaborate on than to fight over. When I was at Google I knew that the Open Web was very important to the long term future. Now I am at Mozilla, the same is true. At the micro level there will be differences, but at the macro-level there is alignment.

Switching gears a little, I have had some folks talk to me about responsiveness issues with Firefox 3. I have had a fantastic experience, and currently I run Mozilla nightlies / Minefield / Shiretoka (3.1.*) and WebKit nightlies side by side. I am very happy with the shape that Minefield is in.

Of course, the issue with the extension mechanism with Firefox is that you get a window to the entire world (which has also been a reason that lead to amazing add-ons). Since this is the case a bad add-on can do a lot.

Chrome does a good job showing you basic info about a tab (memory etc). What if we did that and more for add-ons. Give me top for the browser.

Now, this is a lot of engineering away, so can we use the crowd to help out?

What if we created an add-on that would track responsiveness information and send it back (anonymously) to the cloud (say, to Weave). We could use math to work out probable culprits and could even ship that information back to the people using the add-on. Thus, you would then find out that FooAddOn seems to be a culprit that slows down the browser. Maybe it could be called Vacinate-addon.

What do you think?

December 22, 2008 07:11 PM

(Pre-emptive snarky notice: nothing Mozilla-related here, so if that’s all you care about, scram. However, if you’re a non-Californian who enjoys the occasional dash of schadenfreude, even moreso if your local political unit is fiscally responsible, read on.)

Two quick news stories in California crossed my field of view in the past few days which I found, er, interesting, to say the least.

First, if you ever happen to visit California and I happen to be in a car crash while you’re present, do not under any circumstances move me out of the car if you think the car might explode. If you did, you’re liable for any harm that might cause me, and I might be able to find a convenient excuse to sue you for lots and lots of money. The relevant section of law (1799.102) is below:

1799.102. No person who in good faith, and not for compensation, renders emergency care at the scene of an emergency shall be liable for any civil damages resulting from any act or omission. The scene of an emergency shall not include emergency departments and other places where medical care is usually offered.

The California Supreme Court case is S152360; I don’t know enough about the California Supreme Court to know how the case is to be officially and permanently cited. (Anyone who does know should comment and inform me on this, please. ) The opinon, released on the 19th, ruled 4-3 that moving an injured person from a believed-dangerous location at the scene of an emergency (judged so by the mover, although at odds with the judgments of others at the scene) does not constitute emergency medical care; thus Torti, who in this case moved her (presumably now former) friend Van Horn from such a location is liable for civil damages resulting from moving her. Where did the term medical come from? According to the California Supreme Court:

While section 1799.102 is certainly susceptible of Torti’s plain language interpretation, a “[l]iteral construction should not prevail if it is contrary to the legislative intent apparent in the statute. The intent prevails over the letter, and the letter will, if possible, be so read as to conform to the spirit of the act.” (Lungren v. Deukmejian (1988) 45 Cal.3d 727, 735.)

In other words, the term medical has been read into the law by the Court from the other legislative provisions which surround it. (It wasn’t even done reasonably, either, as the dissenters in the case aptly show in their dissent.) Ergo, since moving a person from a dangerous situation in an emergency isn’t medical care, the Good Samaritan in this case can be held liable for damages caused by that action.

I believe I can confidently state that at least four of the justices on the California Supreme Court are not textualists.

(It’s worth noting that others present at the accident apparently contest that there was an actual emergency at the scene, because they saw no evidence the crashed car was going to explode. If that’s the case, the correct action would have been to contest that there was an emergency and thus prevent the Good Samaritan exception from applying. [In fact the dissent in its closing paragraph noted precisely this point.] This particular situation sounds to me like more a matter of nerves than anything else, but as that argument seems not to have been raised, it’s somewhat irrelevant now anyway.)

Second, it’s no big secret that California’s in the midst of a pretty hefty budget crisis (which, to the best of my knowledge, has been around since before the current economic upheavals — a situation also shared with Michigan, my immediate past home state). California’s legislatures have been attempting to address a projected $18 billion (or so) deficit for some time now. There’s merely one small roadblock to avoid in doing so: the California State Constitution in article 13A section 3 says that:

Section 3. From and after the effective date of this article, any changes in state taxes enacted for the purpose of increasing revenues collected pursuant thereto whether by increased rates or changes in methods of computation must be imposed by an Act passed by not less than two-thirds of all members elected to each of the two houses of the Legislature, except that no new ad valorem taxes on real property, or sales or transaction taxes on the sales of real property may be imposed.

To parse that out a little and omit irrelevant text, it says that any change in state taxes for the purpose of increasing revenues must be part of a legislative act passed by two-thirds of each house of the California legislature. So unless the California legislatures can get two-thirds of each house to agree to a bill to do it (and they can’t, not in the middle of an economic downturn), they can’t combat the fiscal emergency by increasing taxes.

What should then be done? Clearly, if you can’t make more money through taxes and you can’t make money through bond sales because nobody wants to buy them, the only other option is that you should spend less money (or, most probably, a blend of the two). Instead, however, we have the following (and more like it) as described by California State Assemblywoman Noreen Evans:

Specifically, the bill enacts a new $0.39 per gallon fee on gasoline. This compares with the existing $0.18 per gallon excise tax and the 5% general sales tax on gasoline which is assessed per dollar. It enacts a new $0.31 per gallon diesel fee, and this compares with the existing $0.18 per gallon diesel excise tax.

(The source of that quote is an audio file at around 27:30 into it; I transcribed from the audio. My Google-fu on this topic isn’t up to snuff at least partly because I’m still new to California politics and don’t know the right names to use in search queries, so I’m having trouble finding the quote in text format online.) So what’s happening is our spades (”taxes”) are now shovels (”fees”), except super-sized, and that rule that applied to spades no longer applies just because we’re calling them shovels rather than spades. Instead, an increase in a “fee” requires only a majority vote, not a two-thirds super-majority vote. The Governator™ vetoed this constitutional end-run (or will be doing so, not sure about the exact timeline), but that the legislatures would have the sheer audacity to attempt this is breathtaking.

There’s a lesson to be learned here, kids: if you don’t like your constitution, just ignore it. Also, blame it on an obstructionist minority if you can; it’s not your fault you had to violate the constitution to which you took an oath/affirmation of allegiance.

(also cross-posted on RedState)

December 22, 2008 06:43 PM

December 22, 2008 06:27 PM

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 51/2008 (December 15 - 21, 2008):

• Misc Development:
  The removal of the "what's related" sidebar has been completed (it was probably mostly unused, had privacy implications, and unmaintained binary code). Everyone missing it should watch out for the Alexa sidebar add-on.
• Releases:
  We released SeaMonkey 1.1.14 on Tuesday. As we did the first build run a bit later than Firefox, we already did include the fix the Mozilla Corporation people "forgot" in some shipped 2.0.0.19 builds and so couldn't come in the problem of potentially shipping the wrong builds. 1.1.14 includes all fixes that are in Firefox 2.0.0.20, and there will be future 1.1.x security update releases, even though Firefox will not ship 2.x updates at the same time any more.
• Automated Tests:
  We had some test failures occurring on SeaMonkey lately, and a long-standing leak issue I had been thinking about off and on.
  As I "caused" one of the failures by enabling that test in SeaMonkey with the places patch, I tried to figure out was was going on with it and created a patch that moves it into Firefox-specific code as it uses features only supported there.
  Another test had been failing since it was introduced and what it tests doesn't even work on my local Firefox builds but somehow succeeds in their tinderboxes, not on SeaMonkey's though - it looks like opening documents in new windows isn't as clean as it should be. I created a fix that could go in and marked the test todo for SeaMonkey, but "unfortunately" it half-succeeds on Windows, so this isn't completely done yet.
  The long-standing EM RDF leak had been mitigated somewhat by a recent EM fix, and after Dave Townsend ("Mossop") reminded me that there was a JS workaround in the bug, I decided to clean that one up and worked it into a patch that removes the EM datasources on window unload, and the helped our leak reports quite a bit.
• Download Manager:
  We've been planning for some time to move to the toolkit download manager backend, but always wanted to keep a tree-based download window similar to what SeaMonkey 1.x has (which was one of the motivations for toolkit getting a nice way to plug custom UI onto their backend). I invested some time into trying how we can do that this week. I hope to have more progress soon, what I have currently is basically a very rough sample, more a proof of concept than a usable download manager.
• SeaMonkey Vision:
  As our current project goals wiki document becomes (out)dated and the main goal of "keep a suite which is similar from a user's perspective to Mozilla 1.7.x" is something we have achieved in the SeaMonkey 1.x release series and keeping the project alive, and even the "plan to move to toolkit/ for the sake of code maintenance" becomes reality with SeaMonkey 2, I had started a thread on longer-term SeaMonkey goals a while ago, with the prospect of forming a real vision for the project from the comments of the community.
  This week, I summarized the comments and later grouped what they were saying by topics. This will form the base of our future vision, for which I'll make a proposal to the SeaMonkey Council soon.
• German L10n:
  Mostly ongoing work to keep up with comm-central and 1.9.1 development.
• Various Discussions:
  Toolbar customization, places prefs, Get All Messages, tabmail, fishcam, etc.

We're nearing the probably only few days in the year where many of us find some silence and time for some non-work activities with their family and friends. I wish everyone who is celebrating this week a very Merry Christmas and hope they'll have relaxing and peaceful holidays.
To everyone not celebrating this holiday (right now), I want to apologize for not responding as fast as usual this upcoming week - I need this time out myself to gather strength for the upcoming year, where we're planning on doing great things for SeaMonkey!

December 22, 2008 06:22 PM

If you are able to ignore Internet Explorer, all the other major browser can render SVG content. Recently, while writing previous posts and webapps, I discovered several quirks that may cause browsers to fail to render SVG content consistently.

Including SVG inline in the document.

<html xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <title>Using SVG inline in an XHTML document</title>
  </head>
  <body>
    <h1>Using SVG inline in an XHTML document</h1>

    <svg xmlns="http://www.w3.org/2000/svg" width="250" height="250"
         style="border: 1px solid black">
      <circle fill="rgb(250, 160, 20)"
              cx="100" cy="50" r="80" />
      <rect fill="rgb(20, 250, 20)" fill-opacity="0.6"
            x="35" y="85" width="180" height="85" />
    </svg>

  </body>
</html>

View this example in your browser.

Inline SVG is an attractive option because it doesn’t require an external file. Unfortunately, inline SVG has one significant problem: authors are forced to use XHTML and the application/xhtml+xml MIME type, instead of standard HTML and the text/html MIME type. XHTML is not a very forgiving language, and one I would generally discourage. Depending on authoring tools and other content on the page, producing valid XML may be difficult. Even more problematic is that Internet Explorer will refuse to display the page at all; there is no graceful fallback for the majority browser. Finally, syndicating SVG in feeds will often cause the SVG to be stripped as it is syndicated.

I used inline SVG for my Mozilla compiler warnings front end, because I don’t care about Internet Explorer users in that application. But it has very limited usefulness in general.

Referencing external SVG content

At first glance, it might seem that you could reference an SVG document using the HTML &lt:img> element., but this is not the case. SVG images are complete sub-documents. They have their own script context and can script themselves. They can also load additional sub-documents such as images. Because of this, browsers force authors to embed SVG images using <object> or <iframe>.

Embedding SVG with <object>

The <object> element is the generic HTML mechanism for embedding external content. It can be used just like an <iframe> for external HTML document. It can be used to embed plugin-rendered content such as Flash, and it can be used to embed SVG:

<object type="image/svg+xml"
        data="http://benjamin.smedbergs.us/blog/wp-content/uploads/2008/12/svg-document1.svg"
        width="250" height="250">
  Alternate markup here. If you see this, your browser may not support SVG, or a content aggregator may have stripped the object element.
</object>

Alternate markup here. If you see this, your browser may not support SVG, or a content aggregator may have stripped the object element.

The object element is the best choice in most situations. All browsers including Internet Explorer will display the fallback content if they don’t know how to display SVG or if the image won’t load. Using the object element, authors can even pass parameters to the SVG document.

Embedding SVG with <iframe>

It is also possible to include SVG content using the <iframe> element.

<iframe width="350" height="250"
        src="http://benjamin.smedbergs.us/blog/wp-content/uploads/2008/12/svg-document1.svg">
  Alternate markup here. If you see this, your browser might not support iframes, or a content aggregator might have stripped the iframe element.
</iframe>

Alternate markup here. If you see this, your browser might not support iframes, or a content aggregator might have stripped the iframe element.

There are minor but important differences using iframe rather than object to display SVG: Internet explorer will load the iframe but choke on the SVG content. The user won’t skip back to the fallback content within the <iframe>element, and in some cases the user may see a download prompt for the SVG document. But many content sanitizers such as those found in feed aggregators will allow <iframe> through while rejecting <object> And finally, iframes have a border by default. You can remove this border using CSS.

Use this MIME type: image/svg+xml

The correct MIME type for SVG content is image/svg+xml. Firefox will accept application/svg+xml but Safari will not!

Specify image dimensions

The author should know the image dimensions in advance. If you don’t specify the width and height in the <object> or <iframe> element, browsers will initially size the object at 300×150 pixels, and then their behavior will diverge:

	<object>	<iframe>
Firefox	Resize to the image intrinsic size, once loaded	Scroll overflow content
Opera
Safari	Crop overflow content
Example	Your browser doesn’t appear to support SVG, or a content aggregator has stripped the <object> tag.

Don’t use rgba() colors in SVG

The CSS3 specification allows for any color to be specified with transparency using rgba syntax. Many web browsers support RGBA colors for HTML content, but only Firefox supports them for SVG content. Instead of using rgba colors, use the SVG properties fill-opacity and stroke-opacity for maximum portability.

<svg xmlns="http://www.w3.org/2000/svg" width="500" height="100">
  <circle fill="rgb(180, 180, 250)"
          cx="100" cy="20" r="85" />

  <text x="10" y="45" font-size="40" fill="rgba(0, 0, 0, 0.3)">rgba transparent text?</text>
  <text x="10" y="95" font-size="40" fill="black" fill-opacity="0.3">use fill-opacity instead!</text>
</svg>

SVG using rgba colors and fill-opacity

December 22, 2008 06:19 PM

We often only display to the world a final, finished product design. That’s sort of like releasing only the last 10 minutes of a movie: it doesn’t show all of the mis-starts and dead-ends that to make the final ending meaningful. I’d like to explain one of the first sketches we did of the Ubiquity mouse-based interface, and why we didn’t stick with it.

Usage:

Step one: Make a selection. The Ubiquity action button appears.
Step two: Clicking the action button opens a context menu with suggested actions.
Step three: Hovering over an action shows its preview.
Step four: Clicking executes the action.
Step five: If the action you want isn’t available, click for more actions.

Critique:

Step one: I like this part. One of the largest problems with the current workflow of Ubiquity is that it requires you to remember to change it. That requires you to break your existing habits — I still sometimes catch myself doing a keyword search instead of using Ubiquity, despite the later being faster. By having a visual affordance that appears at the exact moment you need it (when you make a selection), the speed and convenience of Ubiquity is injected smoothly into your existing workflow. No need to stop and think.

The idea isn’t new. The trick, though, is making it not annoying. The New York Times has a good implementation.

Step two: Clicking is okay, but that’s mostly where the okay stops. The mockup shows a spruced up linear context menu. Instead of doing just a big list, there’s some preliminary information architecture — they are split between the Ubiquity-recommended actions as well as your most common actions. The reason we didn’t want to combine them were two fold: (1) The items in the menu would shift so often that habituation would be nigh impossible, and (2) detection of what kind of thing you’ve selected isn’t a perfect indicator of the action you want to take.

The big problem with a linear context menu is that it just isn’t very scalable. After you’ve got more than roughly 15 items in there, it’s just a big jumble. Especially if it’s listed in anything other than alphabetical. You can add submenus based on logical groupings, but given the number of Ubiquity commands available it quickly becomes an arduous trail of dexterity and memory.

Step three: Hovering is a nice, light interaction. But, if we are near the corner of the screen, where does the preview get put?

Step four: Just fine.

Step five: The mark of a bad design is needing to switch or invent mechanisms to accommodate common edge-cases. There’s no “obvious” thing to do with the “more actions” option — we’d have to invent an entirely new interface to cope. Not good.

Next

It’s clear that this isn’t the right interface for a mouse-based Ubiquity. We’ve got another couple on the drawing board, but we’d love to hear ideas and see sketches of other ideas!

December 22, 2008 06:00 PM

First, Aza Raskin does a quick interview with Dan Mills to talk about what’s going on with Weave. There’s been a huge amount of development going on in the weave project including a completely new server and client. I’ve heard that some of the labs guys have Weave syncing between desktop and mobile devices, too. So lots of progress going on there. I’m sure these guys will have another release up pretty soon.

Dan Mills on Mozilla Weave from Aza Raskin on Vimeo.

In this video Madhava Enros gives a demo of our Mozilla mobile browser called Fennec. Since the first Alpha release there’s been a lot of work on responsiveness and performance. Madhava gives a quick walk through of the browser as it stands today.

Fennec Alpha 2 Overview from Madhava Enros on Vimeo.

And in this last video mctones gives a demo of a concept that he’s working on that might be used when you open a new tab, using z-order to indicate age with a jQuery-driven visual layout. This video is pretty neat if for no other reason to see the sea of floating web pages. Not sure if it’s useful, but it’s a fun video.

Auto Dial 3D from mctones on Vimeo.

December 22, 2008 04:39 PM

• Two days in Frankfurt, two days in Munderkingen and two days in Heidelberg between December 5th and 17th. Mostly just ordinary working and travel days.
• Visited Sandro Groganz of Init Marketing in Munderkingen. Worked from Sandro's house after a nice dinner on Sunday.
• Caught up with (and was interviewed by) Rory MacDonald of Init Marketing while he was vacationing near Ulm. The interview was focused on Mozilla and should go online in the new year on http://www.initmarketing.tv
• Visited Georg Richter of MySQL/Sun in Heidelberg.
• Many thanks to Georg and Sandro for putting me up during my travels.

p.s. Baden-Württemberg is the name of the German state that Heidelberg, Munderkingen and Ulm are in. Frankfurt is in nearby Hesse.

December 22, 2008 03:59 PM

December 22, 2008 12:35 PM

…or, “Two weeks, two releases, and lots of other fun.”

• First and foremost, we released Camino 1.6.6 on Tuesday in sync with the Gecko 1.8.1.19 release. Special thanks to Marcello Testi and the entire caminol10n team for the quick turn-around when we switched the order of Camino 1.6.6 and Camino 2.0 Beta 1. As usual, Stuart Morgan was my partner in crime on this release, and Samuel Sidler kept the webserver happy during and after the release.
• In addition to his role on the release team, Stuart performed his usual complement of reviews and super-reviews. He also finally got to land his patch to prevent stray frames of QuickTime (and other plug-in) content from persisting when switching tabs and polished off the fix to enable beginning drags of background tabs with a single click.
• Sean Murphy collaborated with Stuart on the fix for dragging background tabs and performed several reviews.
• Bryan Atwood finished up his work on the exceptions list for “Block Flash animations” (aka the Flashblock whitelist) early last week, and he also returned to an old bug about hiding Flashblock placeholders for Flash animations already hidden by ad-blocking.
• Several of Christopher Henderson’s outstanding patches landed over the past two weeks, including the tab height fix that was one of the blockers for Camino 2.0 Beta 1. He was also the reviewer of record on many patches.
• The past two weeks saw not only Ilya Sherman’s first Camino patch land, but also his second. In between exams and winter break, he continued to poke various download-related bugs.
• Chris Lawson finished several patches during the recent weeks, including one that cleans up how we construct bookmark names for entries in the Address Book collection, bringing both saner behavior and improved localizability.
• The past two weeks felt a little like a never-ending race to me; I think that’s related to serving as driver and release-master for two releases in two weeks, with last week including both pushing a release live and building another! When not doing that, I helped Sam and Chris L. chase down a regression in Gecko 1.8.1.19 that broke Wells Fargo’s insane login form. Over the weekend I decided it would be relaxing (!) to make another foray into Objective-C-land, and with some great code originally written by Simon Fraser and Chris L. as a guide, a stylesheet from Philippe Wittenbergh, and Christopher H.’s help, I got our Aqua <select> override working and ready for review.

As we head into Christmas week and New Year’s, we’re definitely planning on slowing down a bit. For those of you who celebrate a holiday this week, we’ll have an early present for you (if you aren’t celebrating this week, consider it simply a random late-December gift from all of us ).

Also on the subject of scheduling notes, I don’t expect to produce a weekly update this week, but I’ll be back at the end of the year with my annual year-in-review.

December 22, 2008 05:41 AM

It sounds strange, but today I worked on a Firefox (or actually Minefield) extension because I wanted to write SeaMonkey-specific code!

As SeaMonkey 2 will be switching to the toolkit download manager backend but wants to keep its own, much different, UI for the download manager, there needs to be quite some work done. Justin Wood ("Callek") has been doing a large part of that, making SeaMonkey able to build with the toolkit download manager, and trying to get the option for having progress dialogs instead of the manager window working with that new backend.

One thing Callek left out for now is getting a tree-based download manager UI for the new backend though, as he (just like me) doesn't have too much experience with custom tree views. After working on places history, I got a first piece of insight into that area though, and so I figured I could at least try how far I could get with such a download manager window.

The problem I had though is that SeaMonkey still has the xpfe backend, and my code needs to work with the new toolkit one. After thinking about this for a while, I realized that it should be possible to just write some code to replace the Firefox download manager with what we want and move it "back" to SeaMonkey once we have the patches for the new backend.

This is what I could get in a few hours of work:



Using nsIDownloadManagerUI, this completely replaces the toolkit download manager even though it's an in-profile extension. Note that it shows grippies as I just symlinked comm.jar etc. from SeaMonkey into my extension and made it define the "communicator" chrome package - I'm not targeting Firefox but SeaMonkey in the end.

The screen shot probably also looks better than reality, the current state doesn't show all info correctly yet or update active downloads, or even do fancy stuff like sorting, searching or managing the downloads yet.

What it does is loads a basic list of downloads at the time the dialog is opened, and show some raw info about it in the cells, without nice formatting.

It's a somewhat interesting way to work on (to-be) SeaMonkey-specific code as a Firefox extension, but I hope it'll help to achieve getting the UI and backend we want in a similar timeframe for SeaMonkey 2.

December 22, 2008 01:54 AM

TL;DR: Dates are terrible; use timestamps. Don’t expect good Date.now() resolution from Safari/Opera/IE on Windows.

Introduction

A common testing method in benchmarks, including our own Talos tests, is to measure and compare performance by recording how long it takes to run a given set of tests. In JavaScript, this is often done by using Date.now() to record the start time and the end time. The duration is computed by subtracting the start from the end. This seemingly simple method has hidden complexities and imposes undue requirements upon the Date.now() implementation.

Assumptions

Let’s take a step back to consider the assumptions this testing method makes upon Date.now(). For clarity and simplicity, I assume that time travel is impossible and relativity doesn’t come in to play. Thus if we were to have some function called continuously that represents the current time as a number, it would be continuous and increasing with a constant slope. (Ok, this is starting to fall into the realm of philosophy and physics). These are the two properties we want in our function that records the start and end times for our benchmark.

Dates

Dates do not have these properties. In the notation used by humans for dates, the representations are ambiguous and finding the duration between two dates can be complicated in that notation. Even with the notation used internally by the computer, issues still arise.

DST

In the United States on days where daylight savings changes, 2am occurs twice or never. This breaks the continuous and increasing properties. Switching to UTC avoids this, but having to convert from UTC into your local timezone is burdensome. We can have the computer automate this, sure, but local times are still ambiguous if that’s how we look at them. It’s hard to tell duration when you have to factor DST into account. This is furthermore complicated by the fact that the laws governing DST change frequently and vary from country to country. Converting from UTC thus depends on having a system that has up to date DST information and of course a correct implementation. So if you are looking at performance results on an out of date system, you may see different durations than on an up to date system. How many Linux/UNIX/Java/PHP users have up to date zoneinfo? Microsoft pushes out DST updates via Windows Update and Apple presumably does the same via their Software Update. Older systems like Windows 98, OS 10.2 and most Linux distributions from more than a few years ago no longer receive updates. So when doing performance tests (or checkins around the DST change), dates can be problematic because you cannot assume that there are 24 hours in a day. Thanks to leap seconds, you cannot even assume 60 seconds per minute. I’m not sure that any operating system supports them though any box using Unix time does not.

This matters why?

But computers don’t use human notation for the dates. Windows, OSX, and Linux all represent dates as an offset from a epoch so why bother concerning ourselves with the human representation? User interface matters. Start/stop dates for the tinderbox are important to get right to track regressions and connect them to checkins (though with hg, figuring out the changeset is much easier). Like DST, timezones are problematic for date representation, but so long as they are clearly marked and the user is aware of the timezone, it is not too problematic. Still, many apps are not aware of timezone changes (Thunderbird included sadly) so this small burden remains on the user to be aware of which timezone apps are using.

Still not enough

Supposing that the DST problems are overcome, there remains the problem of clock drift. Nearly every system routinely synchronizes time via NTP with some master time servers. This results in small and usually unnoticeable corrections to the system time which break our desired properties. One might argue that such offsets are rare and small and thus hardly noticeable, but they are on the order of milliseconds to 100s of milliseconds which means that they can come up and make a difference. Turning off NTP sync is undesirable since clock sync between computers is important for coordinating distributed tasks and having a reliable clock to look at to find out if you’re late to a meeting or not.

Resolution

Which brings up the next concern: time resolution. Put yourself in an operating system architect’s shoes for a moment. You’re designing an API and internal structures to keep track of the time. Let’s look at some use cases using Windows as an example.
1) The taskbar clock - this updates every minute or so
2) The analog clock in Vista - this updates once a second to draw the second hand
3) A fancy analog clock - this updates at a continuous 60 frames per second to draw a smoothly animating second hand
I cannot think of any other use cases for needing knowing the whole date at a rate faster than 60 fps (~16 ms). Coincidently (or maybe not), the Windows system clock updates roughly every 15.6ms on most NT based systems. And given the use cases discussed above it is a reasonable rate.

However, once we start using Date.now() for performance tests, 15.6ms is not fast enough. Some of the SunSpider benchmarks from Apple run in just a few ms. Either these benchmarks need to be made longer or the resolution of Date.now() needs to increase. There are drawbacks to both. Increasing the test length means that the Talos boxes take longer to run and so regressions take longer to find and we need more machines to keep up with the rate of checkins. Also, sitting around for hours waiting to find out if your changesets regressed performance is no fun. Looking at the second option, it’s not immediately clear how to increase the resolution on Windows’ GetSystemTimeAsFileTime API. This was my challenge in bug 363258. OSX and Linux have a 1ms resolution via gettimeofday() so this is a Windows-only issue. Just as Windows/OSX/UNIX store dates as an offset from an epoch, so can we. There are a few methods for measuring durations in Windows: GetTickCount, timeGetTime and QueryPerformanceCounter. There are drawbacks to all of them.

GetTickCount

GetTickCount returns the number of milliseconds since the NT kernel booted. A tick is the timer interrupt from the APIC on x86 systems (and because Mozilla doesn’t run on the other platforms supported by NT I won’t consider them). At each tick, the system time is updated by a certain amount as specified by the Get/SetSystemTimeAdjustment or “the system’s internal adjustment mechanisms.” This computed time since boot is stored into a shared readonly page mapped into each process so the API call is fast since it just reads from that page, but resolution is still limited by the kernel tick rate. Furthermore, the value returned a DWORD (32bit int) so every 49.7 days, the value will overflow. There is a GetTickCount64 which does not have that problem but it is Vista only.

timeGetTime

timeGetTime() suffers from the same problems as GetTickCount by default. By calling timeBeginPeriod(1), the kernel tick rate is increased to 1ms sometime after the call returns. In my brief testing with this function, I found it took effect immediately on Vista and one or two ticks on XP. This also increases the resolution of GetTickCount. Ignoring the overflow problem, why can’t we just call timeBeginPeriod and be done with it? Well, increasing the kernel tick rate increases the system load; more work is being done just to maintain a higher resolution clock. This would mean that leaving Firefox running while your laptop is on battery could decrease the battery’s performance by up to 25% (see this Intel article or this Microsoft presentation) There is a corresponding timeEndPeriod call that can restore the old tick rate, but that would require us to know when the last high-performance call to Date.now() is made.

QueryPerformanceCounter and RDTSC

QueryPerformanceCounter returns a 64 bit time stamp so it does not suffer from the overflow problem. This timestamp increases at the rate returned by QueryPerformanceFrequency. The API states that this rate does not change while the system is running. That’s not quite true. On older systems, QPC is implemented using the rdtsc instruction for x86. This returns the number of clock cycles since the processor booted. It is very high resolution and very accurate on those systems if they are uniprocessor. Newer processors such as Intel’s Centrino and Core processors dynamically change the clock speed of the processor in response to the workload and certain HALs (Hardware Abstraction Layer) for certain versions of Windows still use rdtsc to implement QPC. Needless to say, this makes it difficult to obtain accurate timings. Suppose we could force the processor into its highest speed; this can be done by the user fairly easily, especially if we’re running a CPU intensive benchmark. Note that I stated rdtsc returns the number of cycles since the processor booted. On multiprocessor systems (including multi core), the cores don’t boot at the same time. There is sometimes a noticeable difference between the two depending on your OS. Windows attempts to keep the CPU TSCs roughly in sync but the keyword there is roughly. Even in single threaded programs there is the issue of reading different time stamps when the thread switches cores. There is no way to perfectly tell which core you are on when the TSC is read because context switches can happen between any two instructions (in user space). On newer systems, there is a dedicated timer on the motherboard which QPC reads. This results in a system call and a read from the device so it is far more expensive than the TSC read but it is stable.

To add to the challenge, neither the TSC nor hardware timer are reliable after suspend/hibernate.

Summary

So to summarize, we have GetTickCount/timeGetTime which suffer from resolution and rollover issues and we have QPC which has superb resolution but lousy consistency in some cases (though it is very fast then). How can we use these to generate a reasonably reliable high performance (multithreaded) Date.now() implementation? Read the bug or the source or perhaps I’ll write another blog post describing the implementation. If you were hoping for a clever and perfect solution, there is none right now. My point is that high resolution date calculation is tricky and sometimes unreliable to calculate the date with high precision on Windows. So let’s revisit the duration calculation.

Duration revisited

duration = end - start where start and end are calculated using an offset from some epoch. Expanding the known implementations of gettimeofday() we get
duration = (epoch + offset_end) - (epoch + offset_start)
which reduces to
duration = offset_end - offset_start
where both offsets are measured in seconds. As you probably already knew, the current date doesn’t matter, it’s all relative. Calculating the full date to high precision just wastes time and effort. What we really care about is the offsets and it doesn’t matter what epoch they’re from so long as it’s consistent for the lifetime of the process.

Looking back on our choices in Windows, QPC is the only viable option since we don’t know when Date.now() needs to be high precision and when it doesn’t. It would be much nicer to have a separate API like Timestamp.sample(). To use timeGetTime or GetTickCount, we could extend this to include Timestamp.begin() and Timestamp.end(). This would leave us with fairly fast implementations for Date.now() and the Timestamp functions so that JS users that would like to do performance tests or animations could do so without sacrificing performance. This API is fairly trivial to implement for other systems since they can reuse their gettimeofday() functions for Timestamp.sample() or use higher performance timers (librt for example) the same as Windows does.

Moving forward

Of course, there should be some concerns with allowing a web page to alter the tick rate of the user’s computer so this should be discussed and more thoroughly thought out before committing to an implementation. And it should be standardized. Doesn’t seem right to have a Mozilla-only API (though for Talos, it wouldn’t be the end of the world).

Points of interest

And for those who are curious about other browser’s implementations, John Resig
had a nice article
comparing JS time resolution on Windows.
SpiderMonkey/TraceMonkey implementation
NSPR’s PR_Now()
NSPR’s interval API
Chrome’s implementation seems to be here
V8’s implementation (look for Time::SetToCurrentTime())
Note that Chrome and V8 don’t have the multithread-safe requirement that SpiderMonkey does.

As for Safari, IE and Opera, I don’t know but it looks like they just call GetSystemTimeAsFileTime based on John Resig’s performance results.

December 22, 2008 01:04 AM

I am totally unable to post a new tweet from last nightly of Shiretoko on Mac (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081220 Shiretoko/3.1b3pre, even using a new profile. It works fine from all other browsers including FF304. I have filed this bug for the issue even if I am not really proud of the summary of the bug report. Since there's nothing on the console or the jsconsole, it does not contain a lot of information...

Update: DUP of 470559. Strange, I did a search on "twitter" to make sure I was not filing a DUP and that one did not appear in the search results...

Update #2: twitter's fault ?

December 21, 2008 11:08 AM

While working on Mozilla Community Sites project, I encountered an interesting challenge.

This Poll Box may look nice, but there’s a hidden trap for anyone trying to use this on his website. How to make the cute bars look nice and present real value in it? The intuitive response is to create a small PHP script that will be drawing the bar depending on the input value.

It would be easy to do if only the bar itself is a simple green/red dual color rectangle but in this case, it’s something more sophisticated. Because the bar can be used on different backgrounds, I had to extract it from the source and create a translucent PNG file with representation of blends, shadows and smooth edges. The file looks like this:

Great. Now we have the bar, and we can present it on any customized background, but it’s somehow static and cannot be used to present real values, right?
So the next step is to take it into PHP world and here were the trap is hidden. How to take a complex PNG image into PHP file? Unfortunately Google failed to help me here, so I started playing around with GD library (after an hour of searching for how to take alpha value from pixel in Gimp - it’s impossible) and crafted a plan.
I could create two dimension array of pixels (rgba) representing left edge, right edge, green line and red line and bundle it into a bar like this.
Alternative approach would be to cut PNG file and load elements into PHP script on each load, but it will have to cost much more (load file, decode, operations, encode, write) so I sticked to the pixel array map idea.
I was also initially considering trying to create such bar algorithmically (take green, red rectangles, then do the math for shadows, rounded corners, opacity etc.) but even ignoring how much time it would take to write it, the performance of such script would be definitely not satisfying.

So I needed two scripts. First, to take PNG file and build a PHP Array map of pixels. Second, to take such array and paint it on PNG file.

The script with those two functions is my svn repo.

At the top of the script file is an example Array map that will paint the example bar. drawpixelmap() is a function that can take such map as an argument and create PNG image from it.

getpixelmap() is a function that takes PNG image and creates string with PHP Array map.

In result you can take PNG image, save it in PHP, operate on it and draw the final result.

In case of my quest I had to cut the Array map into pieces (left edge, right edge etc.) and do a little bit of math.

The result looks like this:

http://labs.braniecki.net/pollbar.png.php?v=50

http://labs.braniecki.net/pollbar.png.php?v=30

http://labs.braniecki.net/pollbar.png.php?v=75

Of course, any other value from 0-100 range for $v is possible.

So, if you will ever need to dynamically modify PNG file by pixels, those scripts may be useful for you

btw. I’m writing it from Victoria, where it is snowing for the third day in a row. Not sure how to explain it, but the snow in Canada is different from the one in Europe. Is it possible that its a kind of eggnog influence?

December 21, 2008 10:09 AM

December 21, 2008 09:00 AM

NSID 2008 had to come to an early close for me today. I leave Monday for my sister’s wedding in Chicagoland and while I would have loved to hold out till the end of the month or even a few more days, that just wasn’t realistic (something about looking presentable).

You could argue I could have waited a couple more days but shaving at this scale is best done at home and not in a hotel!  Too bad too because it was just starting to get comfortable.

Here’s to next year!

December 21, 2008 07:47 AM

O, focus code, focus code,
How much do I love tree?
Why store focus in one place,
When you can store it in three?

O, focus code, focus code,
You seem twisted and bent,
You know that no-one would mind,
A lost or extra event.

O, focus code, focus code,
What fun games you do play,
When you’ve got A calling B,
Who says B shouldn’t call A?

I’m so tired of wasting time fixing bugs in focus handling. I’ve literally spent weeks trying to get focus working properly within popup panels. Tests often fail arbitrarily due to focus or the right window not being active. Quite a pain. Little to no documentation as well as wacky code make for frustrating times. I realized after a fit of banging my head against the wall that there was really only one possible solution here. So a while ago, in a final burst of absolute insanity, I rewrote the focus handling code.

Crazy? Yes. Good idea? I wasn’t sure at first. I can honestly say that I’ve spent less time doing this than I have spent fixing or working around the focus bugs I’ve encountered in the past. Anyway, I’ve only been working on this off an on when I get a chance, usually when I get frustrated with some focus related bug. But things are almost in good enough shape now that I can say that I think this will have been worth the effort.

Lots still to do of course - embedding might or might not work, a while ago Camino seemed to be grasping at the concept of working, plugins seem OK, accessibility, maybe… And of course, more testing.

More coming soon… Right now, I must sleep.

December 21, 2008 03:07 AM

Well, almost.

The "open browser and close again" as well as the "open mail and close again" tests our (Linux) bloat test box is doing both reports 0 refcnt leaks now, even without the slight hack we had in there until today (not loading the EM RDF datasource and not populate the "View > Apply Theme" menu with actual themes).

And even the chrome mochitest suite reports "no leaks" on Linux and Windows.

Unfortunately, we somehow still leak 1112 bytes on Mac for those tests. For the plain mochitest suite, where we run much more tests, we report 8 bytes leaked on Windows and Linux, on Mac OS, we report those 8 plus the previously mentioned 1112, making up 1120 bytes total. And for the browser chrome mochitests, we leak 1112 bytes on Linux and Windows, and 1232 on Mac. Somehow this 1112 number is something we like - interestingly, we get it in those places where one non-browser window is open in addition to the standard browser window (the "hidden window" on Mac or the additional window for browser chrome tests), I wonder if that's somehow connected. Also, we're leaking the RDFServiceImpl and an InMemoryDataSource there, which could be an indication what to look for, I guess (unfortunately I don't know the code too well myself).

By the way, I just worked a long-standing workaround to our EM RDF datasource leak into an actual patch, removing the datasource in the unload handler of the browser window, the real fix would be in cycle collection though.

Oh, and have patches waiting for review to get the actual test failures on SeaMonkey machines out of the way and hopefully turn them green for the holidays.

December 20, 2008 10:57 PM

In the last month, I've had two laptops go bad (one hard drive, one logic board), I've misplaced (or lost) my Gran Turismo 5 Prologue game disc, and now my PS3's optical drive is dead and won't recognize any discs. I've also had to reboot my DirecTivo twice within the same timeframe, something that's almost never necessary.

I'm cursed. WTF?!

December 20, 2008 08:56 PM

LLega 2009 y he decidido volver a escribir en este blog en español puesto que ya no mantengo el otro blog (Plaza Mozilla) que tenía y que mantenía conjuntamente con Noctuido (miembro de Mozilla hispano).

Buena noticia, ya no tendré que mantener dos instalaciones de blogs (uso Dotclear) distintas en el mismo servidor puesto que Dotclear 2.1 es multilingũe y me permite tener hilos RSS/Atom por idioma.

Sí quéréis seguir las noticias en español del blog, podéis agregar este link a vuestro agregador de flujos web: Carnet Web de Pascal (en español)

December 20, 2008 04:57 PM

December 20, 2008 07:07 AM

Last weekend, we celebrated in Madrid the first extension workshop in Spain. Pascal Chevrel and Paul Rouget were there and also around 50 developers interested in how to write code for the Mozilla platform.

Lot of people get surprised about how easy is to write an extension if you already know HTML, CSS and Javascript, you just have to know a few XUL tags and you are done!

Paul talk was great using an extension he developed as an example which uses data and interacts with the biggest Spanish social network called Tuenti. The code was given to Mozilla Hispano so as to help the community continue development of the extension. We have opened a thread on our forums to coordinate the development using a Mercurial repository.

Personally I found the talk very interesting and now I'm trying to improve my coding skills in XUL and Javascript, I've implemented some minor improvement to this extension while I learn more and more about working with the Mozilla platform. I intend to learn enough to do a similar workshop at my local city since we need more developers in the Spanish community.

December 20, 2008 01:17 AM

During the past weeks I’ve started a new project called ABE, sponsored by the NLnet Foundation and meant to provide CSRF countermeasures configurable on the client side, the server side or both.

As you probably know, the NoScript browser extension improves web client security by applying a Default Deny policy to JavaScript, Java, Flash and other active content and providing users with an one-click interface to easily whitelist sites they trust for active content execution. It also implements the most effective Cross-Site Scripting (XSS) filters available on the client side, covering Type-0 and Type-1 XSS attacks; ClearClick, the only specific browser countermeasure currently available against ClickJacking/UI redressing attacks, and many other security enhancements, including a limited form of protection against Cross-Site Request Forgery (CSRF) attacks: POST requests from non-whitelisted (unknown or untrusted) sites are stripped out of their payload and turned into idempotent GET requests.

Many of the threats NoScript is currently capable of handling, such as XSS, CSRF or ClickJacking, have one common evil root: lack of proper isolation at the web application level. Since the web has not been originally conceived as an application platform, it misses some key features required for ensuring application security. Actually, it cannot even define what a “web application” is, or declare its boundaries especially if they span across multiple domains, a scenario becoming more common and common in these “mashups” and “social media” days.

The idea behind the Application Boundaries Enforcer (ABE) module is hardening the web application oriented protections already provided by NoScript, by developing a firewall-like component running inside the browser. It will be specialized in defining and guarding the boundaries of each sensitive web application relevant to the user (e.g. webmail, online banking and so on), according to policies defined either by the user himself, or by the web developer/administrator, or by a trusted 3^rd party.

ABE rules, whose syntax is defined in this specification (pdf), are quite simple and intuitive, especially if you ever looked at a firewall policy file:

# This one defines normal application behavior, allowing hyperlinking
# but not cross-site POST requests altering app status
# Additionally, pages can be embedded as subdocuments only by documents from
# the same domain (this prevents ClickJacking/UI redressing attacks)
Site *.somesite.com
Accept POST, SUBDOC from SELF, https://secure.somesite.com
Accept GET
Deny

# This one guards logout, which is foolish enough to accept GET and
# therefore we need to guard against trivial CSRF (e.g. via <img>)
Site www.somesite.com/logout
Accept GET, POST from SELF
Deny

# This one guards the local network, like LocalRodeo
# LOCAL is a placeholder which matches all the LAN
# subnets (possibly configurable) and localhost
Site LOCAL
Accept from LOCAL
Deny

# This one strips off any authentication data
# (Auth and Cookie headers) from requests outside the
# application domains, like RequestRodeo
Site *.webapp.net
Accept ALL from *.webapp.net
Logout

Living inside the browser, the ABE component can take advantage of its privileged placement for enforcing web application boundaries, because it always knows the real origin of each HTTP request, rather than a possibly missing or forged (even for privacy reasons) HTTP Referer header, and can learn from user’s feedback.
Rules for the most popular web applications will be made downloadable and/or available via automatic updates for opt-in subscribers, and UI front-ends will be provided to edit them manually or through a transparent auto-learning process, while browsing. Additionally, web developers or administrator will be able to declare policies for their own web applications: ABE will honor them, unless they conflict with more restrictive user-defined rules.
As soon as browser support for the Origin HTTP header becomes widespread and reliable, an external version of ABE might be developed as a filtering proxy.

An initial implementation will be released during the 1^st quarter of 2009 as a NoScript module.
I already collected precious feedback from security researchers like Arshan “Anti-Samy” Dabirsiaghi, Ivan Ristic of ModSecurity fame, Sirdarckcat and others.
More opinions and suggestions about rules design and features are very welcome.

December 20, 2008 12:27 AM

For those of you who couldn't make it to the brown bag yesterday, here are the slides:

The Silme slides were based on Gandalfs slides from Barcelona.

A short description what I was talking about:

Making sure, that a localization works properly and does not have obvious mistakes is all but easy. On the other hand it is important for both, the developer and the localizer, to have it working. With the upcoming L10n library called "Silme" it will be possible to write a variety of localization testing tools, easily. One, already working tool, is compare-locales . The presentation will be about how to write and use Silme tools based on my compare-locales work.

December 20, 2008 12:27 AM

Thanks to Reed, I just put up my latest pet project up on the l10n server.

It’s offering a new web interface for buildbot builds. It does so by feeding the status data that buildbot has into a database on the one end, and on the other end is a django app displaying that data.

The nice thing about this is that writing features (or fixing bugs) is “just webdev”. Compared to whatever you want to call tinderbox hacking.

There are already a few concepts demoed on the site. All urls are in flux, note the “stage” in them. But the principle should be obvious.

Firstly, you can get to a regular waterfall on waterfall. Yes, there are some time-sorting issues there. But it’s quick, which is cool. Compare it to the regular buildbot waterfall (didn’t bother checking which timerange that shows). And it offers a nice compromise (IMHO) for displaying detail or not. For finished builds, it shows one box per build. For builds in progress, it shows a box per step (it doesn’t show a box for the build for those steps, which is confusing). It has a blame column, too. Whenever you see a change number, that links to a new page, which lists all builds for that particular change. This one shows an en-US check-in with all locales turning red, for example. Another one just shows how things go green for Arabic again, as that localizer checked in.

For the l10n builds, that’s peanuts, but if you’re landing on a tree with real compiles, being able to follow all builds for your landing, and no others sounds cool.

And django comes with helpers for generating feeds, so creating a meaningful live bookmark to follow your own landing doesn’t seem like an unsolvable RFE.

There’s more. You can restrict the waterfall to only show builds for a particular slave. You can restrict the shown builds to only show builds with a particular property, say, the Macedonian builds, compared to all builds.

There’s obviously lots of room for improvement, the code is in the tinder app in my hg repo. Volunteers welcome.

December 19, 2008 11:50 PM