Given the quick review on AMO (many thanks to you guys that this happened under a week!) the Mozmill team can call out that Mozmill 1.3 has been released. It’s available for download on addons.mozilla.com.
This release is a big step forward by adding a couple of new features and fixing some important bugs which have been found by users and have been introduced by the last release. A complete list can be found on Bugzilla.
Let’s give a short overview and mention some of the fixes/features:
Bug 509912: We have updated the maxVersion for all applications. So Mozmill is not compatible up to Firefox 3.7a1pre, Thunderbird 3.1a1pre, and SeaMonkey 2.1a1
Bug 508643: From now on new profiles are created by Firefox itself. Before that fix we have used the files from within the default profile folder of the default application. That caused failures for localized builds because the profile has been initialized with wrong profile data.
Bug 516729: Tests failed by clicking on elements inside the content area if the window was too small. Now with this fix elements will be scrolled into view before clicking on them.
Bug 522990: Nested elements in the content or chrome document weren’t correctly reported by the inspector which didn’t let you get an element string.
Bug 512789: Both controller.check and controller.radio functions have been updated to work now.
Bug 515072: A second parameter has been added for controller.assertJS which let you specify an object which can be accessed via “subject” from within that function. It allows to show a more detailed information for a failing test.
Bug 500987: Restart tests can pass variables between test modules. There is a persisted property available by default which can be used to set/get user-defined values.
Bug 515209: Restart tests can have a callback handler written in Python which can be called asynchronously.
If something has been regressed since the last version please file a bug under Testing/Mozmill on Bugzilla.
Release testing which has to be done by QA right before a new release of Firefox will be offered to our users is still an area where lot of manual work is involved. That means we run Smoketests and the Basic Functional Tests (BFT’s) against the build candidate. As I have already written there is ongoing work with Mozmill to get those work fully automated in the future. But that are not the only tests we have to run…
Since ever Firefox is supporting automatic updates we also have to check that each and every user will get the right update package for the installed version of Firefox. Most of our users should run the latest version of Firefox but there are also cases where people don’t update immediately or even don’t want to upgrade to the next major version of Firefox. Given that updates have to be delivered to each of the supported branches (e.g. Firefox 3.0.0.x and Firefox 3.5.x) and also as major update for upgrading to the next major version. We also have a community beta program running where users can help testing beta versions of the next Firefox version. Those users will get a separate update offer on another update channel.
Finally there are 4 different channels we have to test for en-US and some of our P1 localized builds. In detail those are in the right order:
betatest: This channel makes sure that updates which will be delivered to beta users will pass.
beta: Beta testers will get their updates on that channel.
releasetest: This channel tests the update snippets which have been pushed to our official download mirrors.
release: Default channel for all Firefox installations to get the next version.
For each of those mentioned channels we offer partial and complete updates. The former one will be used if the latest minor version of Firefox is in use, e.g. a user wants to update from 3.5.4 to 3.5.5, while the latter one is for all other versions of the same branch. If an update fails to apply which could happen due to different reasons like a download problem, users will not get stuck on their installed version. In such a case a fallback update will be downloaded which is identical to the complete update. If that fails too the same process will be started again after a given time.
Until now these tests had to be done manually by us. An example can be seen in the update section of the Firefox 3.5.5 test plan. So we normally tests updates on all supported platforms, for each update type (minor, major), and make sure that fallback updates will pass.
With the new software update tests for Mozmill which I have finished two days ago, we can easily automate this process now. The only manual steps which have to be done is to prepare the tests by downloading the necessary builds for all the platforms and place them in their own folders. Once that is done the automated test can be started. It will use all builds within a given folder and runs tests updates for the specified channel. The results are printed in wiki format to the console and only have to be copied to the appropriate Wiki page.
This is a big step forward in a direction where we can run update checks against each localized build of Firefox and can make sure that updates are successfully applied and don’t fail or cause any sort of failure. And it will give QA more time to focus on other topics.
That’s pretty cool! Years ago I was fascinated by watching minimalism pictures but today I noticed something which is much much better. Keith Loutit from Sydney uses the same technique to create own videos with the same effect. I cannot get enough from it… See on of his shorts movies to get fascinated too:
Nearly 3 month after we have released Mozmill 1.2 we are close to our next release of Mozmill. Lots of bugs have been fixed and even a couple of new features were implemented. A nearly complete list you can find on Bugzilla.
Everyone who is using Mozmill regularly is welcome to help us in testing the beta version. As long as no big issues will come up the release of Mozmill 1.3 will happen next week.
If you want to test the extension please download it from Github.
Users of the pyPI packages only have to run “easy_install -U mozmill” to get the latest packages for Mozmill, JSBridge, and Mozrunner.
Working on two or even more machines in parallel would require a KVM switch or just a neat software like Teleport which lets you share your keyboard and mouse simply over the network. One big advantage against Synergy is that this solution comes as a prefpane and embeds the configuration UI and the backend within one application. Further once a Mac has been enabled for sharing other Mac’s will automatically find it in the network. Anyone who has security concerns will be happy that the connection can be encrypted.
After a couple of hours using it I will definitely not miss it anymore!