The roads I take...

This Monday, my new Nokia N810 arrived! I'm played a bit with its features now, installed some additional software, tried browsing a number of websites, and all in all, I really like it.



You (as a geek yourself, probably) might notice that on the picture, its UI has a lot of similarity to Star Trek TNG's mobile tablets (PADDs), that's not the default look - one of the first things I installed was the LCARS PADD theme package, when I tried how well free WLAN hotspots work in Vienna - and I was satisfied (both with freewave and the theme).



Of course, for people like us, the web browser is quite important - and the device running on Linux and having a Gecko-based browser were among my main reasons for buying the N810. And, despite not being SeaMonkey , I like the microB browser a lot. It works like a real browser and displays web pages like they should look, not garbling a number of them like the Opera mobile version on my Nokia 7710 phone (which performs well enough for the N810's GPRS internet connection where no WLAN is in reach). I even did write a paragraph on the last weekly status update on this blog from the microB browser, when my desktop locked up and I had to reboot it - something that I haven't seen with the N810 yet.
The system feels very stable and comfortable, and you wouldn't realize it's actually Linux unless you e.g. open up an X terminal on it or connect to the device via ssh (after installing OpenSSH, that is). Oh, and as a regular long-time Linux user, I just like being able to look into top or ps to see what the system's doing/running and just ssh'ing into all my computers from all my computers.
Now I finally got a device I can take with me to take notes, look into the web and such stuff without needing to bring with me and unfold a fully laptop computer. Yay!



One further reason why I finally decided to get me an N810 is its GPS and mapping capability. Especially when I was in the US in April, but eventually also when on my way somewhere here in Vienna, I often felt it would be nice to have a good map handy, ideally along with some indicator pointing out my position. The N810 promised to be able to do both, with software being able to use free OpenStreetMap data (maemo-mapper), and even GPS positioning and tracking capability. I already read in advance to buying the device that its internal GPS takes a very long time to find a satellite fix, but then work quite well even where signal quality is not that good - and I can confirm both, though esp. the former. When turning on display of GPS details in maemo-mapper, it's quite common for the device to have 2-5 satellites in view but being unable to establish a fix - at least in the central area of Vienna that is covered with 6-7 story buildings. Once the miracle happens and an initial fix can be established, the position isn't always accurate due to heavy signal reflection between those buildings, but it hardly loses the fix and can re-establish it fast when it gets lost, at least when not being in a building for a longer period of time.
I'm looking forward to trying this outside the city (in my home town) this weekend and see hoe well things work there. If anybody knows a good trick to ease the device getting an initial GPS fix, please tell me, I'll happily try out your suggestions.

All in all, I'm positively impressed by this device, it works very well and perfectly shows off how well Linux and Gecko 1.9 are suited for mobile use already - but then, I barely scratched the surface of what it can do in those two days I have it now. I'm looking forward to the N810 supporting my work and perhaps even some fun activities in the future. Well done, Nokia!

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 21/2008 (May 19 - 25, 2008):

• Automated Testing:
  We got the hardware set up for the Mac buildbot slave, but I still need to figure out how to log in and get the software up and running.
  While I'm on the topic of testing, there has been some talk about turning off the TUnit tests on the Linux tinderbox, which should improve the machine's cycle time. The buildbot machines have taken over this job and their output is also better - so if you have any objection, please tell me soon or I'll take TUnit off that box.
• Preference Migration:
  More review and discussion about the advanced pref panel. It looks like the JVM switching stuff has only worked on Unix/Linux, but requires names of the paths that are not common any more, so it has been broken for a while on common systems (JVM devs probably knew better, but I'm not sure anyone else did). It seems like this feature should be extension fodder, and I'll get all the reviews for killing it.
  I also hope that other people are starting to work on the remaining pref panels left active in the old window, as we want to kill the old window finally for alpha.
• Windows Development Tools:
  I checked in Serge Gautherie's patch for enabling Windows source server support, if you want to try it, please do, and tell me if it works because I have no clue, being Linux-only on the development side of things.
• Version Control and SeaMonkey Development:
  As there has been talk of opening the mozilla-central repository on Mercurial (hg) and continuing trunk (1.9.1.x) development there, leaving cvs HEAD for the stable 1.9.0.x series once FF3 is out, it's time for SeaMonkey and Thunderbird to think about how to host development code in the future.
  We want want to base our next releases on 1.9.1.x for various reasons, so we need to figure out how to place our code in separate hg repositories and pull those together into a tree we can build. We probably all knew this point in time will come, though I guess many of us hoped to concentrate on Thunderbird 3 and SeaMonkey 2 before figuring this out.
  Figuring out where to place code affects everything not in mozilla-central today, including most suite-specific, shared mailnews and included extensions code, with at least the notable exception of Composer stuff that somehow got imported into mozilla-central. This might not be trivial, given that we might want to share a repository with e.g. Thunderbird, and given that even our own code is spread across multiple top-level directories at the moment. I'd like to figure that out at least in a testing setup, but any help is appreciated.
• SeaMonkey Status Meetings:
  I'd like to get the SeaMonkey together in some kind of status update regularly, ideally in a weekly manner, so that all of us know better what's progressing and what needs to be done. This could be via a phone meeting, an IRC meeting, or even just updating a wiki status page to be ready by some deadline (a wiki summary should be done for the other meeting types as well).
  If you want to participate and have some preferences for the type and timing of such status updates, please let me know.
• Various Discussions:
  Session (re)store, Thunderbird/mailnews development, 1.9.0 vs. 1.9.1, L10n and hg, Firefox Plus Summit, etc.

I finally got my invitation for the "Firefox Plus" Summit this summer without losing it via the Junk mail mechanism (my Bayes filter seems to be trained to consider it as spam), and I registered successfully, so I'm pretty sure now I'll attend this come together. As a project coordinator, I probably have several different interests there, I hope I don't need to weigh build&release, mailnews, and other talks too heavily against each other, but it's possible that I'll have to in some way. If you have any topic you want to talk to me about, please tell me, I'll be there and try to communicate with as many people as possible.
That said, my main focus (even on an event with the Firefox brand) is of course SeaMonkey, and I'll try to make as many talks/topics as possible that help our project and can bring us forward in some way.

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 20/2008 (May 12 - 18, 2008):

• Automated Testing:
  The automated testing machines are green on Linux and Windows and reporting to the main SeaMonkey waterfall page. It's now required to not break them for checking in SeaMonkey patches.
  A Mac buildbot slave is in the works.
• Preference Migration:
  Still waiting for reviews for the advanced pref panel.
  When I realized that unfortunately people need about:config every now and then and Thunderbird has an option to call it but we don't, I realized we could add a button for it to the advanced panel and filed a bug for this.
• Linuxwochen Wien:
  As mentioned in my previous blog post, I spent some time at the local free and open source software event called "Linuxwochen", promoting Mozilla and SeaMonkey at least in the local community - and I hope to spread the word and get connected with this community further in the future.
• Various Discussions:
  AMO integration in SeaMonkey (it has landed!), session (re)store, Thunderbird/mailnews development, next bug triage targets, 1.9.0 vs. 19.1. for next Thunderbird and SeaMonkey releases, hg move, etc.

Sorry for the really long delay of this status update, the last week or so has been a bit of a crazy time for me privately, but I hope to come around to more actual work again. Stay tuned!

This Friday and Saturday, I spent a lot of time at a local free and open source event called "Linuxwochen Wien". Both days I had intended to only visit there for two talks or so, but on both days I didn't come home before 2 in the morning, spending the rest of the evenings and nights with people from the local FLOSS community and talking about all kinds of interesting things.

My first contact with that community (yes, I know, I probably should have done that earlier) was a lot of fun, and I surely intend to repeat the experience. And I even could reply that SeaMonkey 2 and Firefox 3 will improve exactly some of the areas where people complained about Mozilla - though one guy was surprised that we still aren't a GTK application on Linux, because we feel so much like one nowadays that he couldn't tell the difference.

I had lots of interesting conversation with people from CAcert, OpenOffice.org, the FSFE local interest groups, etc. At the official event, I attended a discussion about "Linux vs. FLOSS" (mostly about which name should be part of a mass-targeted event like this), a talk about customizing Firefox (mostly actually listing and demoing "Add-Ons you must have") - and an inspiring talk about the OpenStreetMap ("OSM") project, which works towards free map data, created by a global community.

After 2 days of not getting much "real work" done, I would have thought to dig deep into SeaMonkey stuff today, but instead, I could not get OSM out of my mind. I looked at the currently available maps from my home town of Steyr, which are/were only rudimentary there, and decided to "just improve a few bits" like names of the streets they had in, maybe some missing connections, just for trying how this works. Well, that's what I thought, at least. After I guess about ten hours of naming streets, drawing new areas and streets according to satellite imagery and correcting already existing data, you might be able to grasp the amount of changes I made by a look at the images below - the first is the nicely rendered view of what OSM had before, the second is the current data in the edit view (nice "Mapnik" view will only be rendered mid-week):

Yes, this really is the same sector of a map, click on the images and view larger version if you don't believe it.

OSM is not just a nice project, I fear I could get hooked on it - not sure if that's a good or bad outlook.
Additionally, I have just added a few items to the list of why I may want to buy a N810, as there's software for it to work with the free map data from OSM and it should also be able to create GPX tracks that I can use with OSM to improve map data. Not sure how long I can hold myself back now before throwing my euros over the counter just to get this device...

Running a Gecko browser on it might even get me back to Mozilla-related work.

As reported here before, I asked for help help with triaging SeaMonkey bugs. Back then we had over a thousand unconfirmed non-enhancement bugs in the "Mozilla Application Suite" product that had no activity for more than 6 months. When I looked at the query today, I was quite surprised when it only showed 15 bugs!

Looking at the open bug graph for our Bugzilla product I could confirm what the query had suggested:
The people helping us here have killed about a thousand bugs in 8 weeks!
This is absolutely awesome, thanks and congratulations to everyone helping with this effort!

It would be really cool if we can prolong this Bugzilla cleanup effort and try to reduce unconfirmed and old bugs even more, so the real bugs are easier to find and deal with. In my newsgroup posting from today (web version), I have a few suggestions on what to attack next - I'd welcome your input!

For years, we have read comments about the default browser window size for the Mozilla suite and now SeaMonkey being sucky, as you couldn't even see the the full URL of the default start page. Even if you have a large screen, you end up with something like "http://www.moz" or "http://www.sea" in the visible part of the urlbar, depending on your platform and its UI font settings.
We had improved the situation somewhat in SeaMonkey by making the default window 70ch (avg char width) by 45em (line height) units, so that it's increasing with the default UI font sizes, but it was still awfully small on most current displays.

The reason for not increasing the size more was to still support smaller screens by not making the window going offscreen and be hardly resizeable - and we didn't want to come into that situation.

With our machines for automated testing, we ran into this problem in a different way: The mochitest suite runs its tests in an HTML iframe, with test summary information above it, and this made us end up with mouse events that were automatically generated to happen over elements in the iframe not being successful just because the iframe was not fully visible - the default window was too small to display it as a whole under those test summaries.

This problem caused a certain amount of test failures - at least on Windows. While we found out that increasing the height to 65em should have helped with the tests, such a default window size would get problematic on small screens.

Looking into how Firefox does this, I realized it sets the default window size dynamically, depending on the available screen size. We now implemented this for SeaMonkey as well, though with small improvements over the Firefox solution: While (judging by reading their code, I couldn't test) default Firefox windows probably grow out of the window when the screen is higher than 600 pixels but slimmer than 994 (which can happen e.g. on a rotated 800x600 or 1024x768 screen, but is surely rare), the SeaMonkey code should always make the default window fit into the screen size. On screens with 600px or less in height, we switch to a maximized window, just like Firefox, and on wide screens (over 1440px in our case) we also take only half the width, suggesting side-by-side page view.

If someone happens to have such a strange screen configuration that is higher than 600px but not at least 994px wide, I'd encourage you to test my assumption of Firefox growing out of the screen by default and filing a bug if you can confirm - I'm sure Firefox developers will be happy to fix that edge case.

For everybody else, enjoy upcoming SeaMonkey 2 nightlies and releases making better use of your screen by default when starting up, fixing a long-time-existing problem we heard complaints about every now and then.

Finally, if you're interested in the unit test boxes being visible on the main SeaMonkey tinderbox waterfall page, I'll do that move soon, probably on Monday, as now all available tests on both machines are passing without using any local patches.

Here's a summary of SeaMonkey/Mozilla-related work I've done in week 18/2008 (April 28 - May 4, 2008):

• Automated Testing:
  As noted earlier on this blog, I worked quite a lot on getting automated testing running for SeaMonkey, as I finally got access to the VMs that were created for this (thanks to Mozilla IT and build people!).
  I also made broswer-chrome test pass once the machines themselves were up and running and patched them so they test-run Andrew's patch for mochitest focus problems, which made all tests pass on Linux (Windows has a few remaining problems, possibly due to a small window size).
• Preference Migration:
  I checked in the migration of ChatZilla integration to the SeaMonkey prefwindow so that those options are available in the new window now as well.
  Additionally, I worked on a new iteration of the advanced panel patch, eliminating the old JVM switch cruft.
  Finally on this topic, I also did a new patch for application preferences help, addressing the open review comments.
• L10n-friendlier "Close" accesskey:
  When investigating a duplicate accesskeys in German, I found out that "Close" and "Close Tab" in the SeaMonkey browser window were reusing the same accesskey defined for "Close" elsewhere, which is a nightmare for localizers finding out what accesskeys to use where. I filed a bug for that and finally fixed it.
• nsSuiteGlue Cleanup:
  As in the case of fixing sanitizer tests I added myself for automated testing, I worked on a second fix this week to a bug I introduced myself:
  When someone else asked my about nsSuiteGlue observers and I looked at the code again, it struck me that we never actually did a call to remove observers and I created a patch for fixing this by porting a few lines I accidentally deleted when porting this from Firefox.
  (As a side note, this was because that "someone", being Misak Khachatryan, is now working on session restore for SeaMonkey!)
• kill-xpfe:
  When Camino people obsoleted a few more xpfe components in their bug to move away from xpfe, I did cvs removals of those parts of code. Another part of xpfe is history.
  (Some people may notice an inflation of "kill-*" names in my project language, I've adopted the style invented in mailnews with "kill-mork" and "kill-rdf" and started using it for "kill-wallet", "kill-winhooks" and now even "kill-xpfe" )
• German L10n:
  I kept SeaMonkey L10n complete on trunk, even though it remains orange for some excess strings (the reporter ones may get killed in a mass-removal for all localizations, the mailnews one might come back soon as that patch got removed temporarily for the Thunderbird alpha).
• Various Discussions:
  Download manager, password manager, AMO and SeaMonkey themes, session (re)store, places backends, Thunderbird/mailnews development, addressbook improvements, etc.

There has been some talk about what policy to follow for SeaMonkey patches with respect to automated testing, now that we have the frameworks running on dedicated machines. Though it's not a firm decision yet, it seems like the best way is for reviewers to require tests for r+ where they are feasible (reviewers should be able to decide that). I'd like to encourage everyone to write tests where it's possible to test their work automatically right from the beginning, and only only per request of reviewers, though. And I'd like to urge reviewers ti require tests from patch writers where they are possible. We have the infrastructure now, let's really use it!

As many of you know, one of the new addition to Firefox development between the Gecko-1.8.1-based Firefox 2 and the Gecko-1.9-based Firefox 3 releases was performing automated tests on all kinds of functionality in this software. This greatly improves software quality by having constant checking of a good part of this complex system and being able to early spot problems introduced in code and revert/correct those.

Starting this week, we also have machines that run a broad range of automated tests on SeaMonkey trunk (the Gecko-1.9-based code that will end up in SeaMonkey 2). Currently, we have Windows and Linux boxes (bug for a Mac box is filed - unfortunately, Apple doesn't support those being run as VMs), reporting to the SeaMonkey-Ports tinderbox waterfall page - and failing a number of tests.

The test failures we see with those machines have different causes:

• The mochitest framework has some focus problems, and generating a keypress event doesn't have the intended effect when the wrong window has focus. Applying the patch from bug 431464 helped with the vast amount of those problems (thanks, Andrew, for figuring that out).
• The remaining mochitests failures on Windows might be because not the whole iframe is in focus and some generated mouse events don't point into it, maybe due to a too small window size. We need to look into improving that.
• Failures in browser chrome tests due to multiple problems, including use of Firefox-only functionality in platform tests, testing a download manager that is not (yet) built for SeaMonkey, and some errors in SeaMonkey sanitizer tests. I could create a patch for those which is currently under review.

The machines will be switched to report to the main SeaMonkey tinderbox waterfall page and be required not to break in future development, once we have fixed those problems and all tests pass.

We have run the unit tests for Linux in our main tinderbox for a while now, but without detailed reporting of numbers, and without coverage of reftests, crashtests, mochitests, chrome or browser tests or other platforms. We now have all those test suites running on two platforms, hopefully adding Mac "soon".

Even a number of about 51500 passing tests doesn't mean that a lot of SeaMonkey-specific code is tested, though. What we're currently are running, are mainly platform tests we share with Firefox - we only have a total of 1 suite and 14 mailnews unit tests being run, and the sanitizer tests account for 31 passed browser-chrome tests (with my patch applies so they actually pass). All other SeaMonkey application code is still not covered by such tests.

What this means is that even though we have machines running the tests, we badly need tests for SeaMonkey code (including mailnews [hint for Thunderbird people reading this]) to be checked in so they get run. Still, we know that the platform still works fine in the configuration used by SeaMonkey, which is good to know and already a major improvement to earlier times.

I'm convinced that amount of automated testing will even improve the jewel of product that SeaMonkey 2 will be. That said, automated testing can only augment manual testing by our community, and never replace it, so please keep on testing our nightly builds - those tests will help to make us not have bad breakage in those nightlies though (at least not for long - it's always a good idea to check for green tinderboxes before downloading and using a nightly, as I hope you know).