The final bits of Mozmill 1.5.8 are now available through Pypi. Install or upgrade Mozmill by running:
pip install --upgrade mozmill==1.5.8
We had to release this version to fix a recent regression which has been identified in Mozmill 1.5.7, and which caused a hard-stop when an user restart has been requested. The issue did only exist on OS X.
Beside this fix we now enabled the new boolean preference called ‘focusmanager.testmode’ by default. It will allow us to run multiple Mozmill tests concurrently on the same machine. Support for the focusmanager testing mode has already been made available on Nightly and Aurora builds. Also there is a good chance to get this patch landed in an upcoming Firefox 10.0.1 release. I will follow-up with another blog post with more details once the final landing has happened and we can actually make use of it across our supported branches.
Tags: automation, firefox, mozmill, mozqa, testing
Since I have been using rdiff-backup to backup my Xen domU machines, I get a daily message from cron which informs me that some sockets couldn’t be backed-up because the path is too long:
SpecialFileError var/spool/postfix/public/flush Socket error: AF_UNIX path too long
After some digging I have found that this is related to the length limitation of the AF_UNIX constant in one of the kernel header files, and which only allows 107 characters. Depending on where you want to backup to the length can exceed.
The solution is simple. Why do you want to backup sockets at all? Those are bound to the current system and will be executed when an application gets started. So I don’t see a reason to backup those files. Therefor just use the –exclude-sockets option for rdiff-backup.
Please note that you will have to run rdiff-backup twice before the failure message from above will no longer appear.
It’s the first time for us that we release two new versions of Mozmill in such a short interval. While this release is a bug fix release, it will add support for an upcoming feature in Firefox Nightly builds, which will probably checked-in today and be available in tomorrows builds. If you wonder what I’m talking about, please read bug 693743, which describes the changes in how Firefox will handle 3rd party add-ons in the future. Especially those extensions which are getting installed into the application or profile folder. In our case both mozmill.xpi and jsbridge.xpi are affected and will be disabled on start-up. With the fix on bug 696027 we make sure that both extensions will not be disabled.
Beside that we also pushed another fix which re-enables the installation of add-ons from the application scope. It has been accidentally disabled in a former release.
Happy testing!
Tags: automation, firefox, mozmill, mozqa, testing
Lately we have released Mozmill 1.5.5. It’s a bug fix release only and we had to release it as fast as possible, because of a broken waitForPageLoaded() method. Also the structure of the JSON report was broken if a module import from within a Mozmill test raised a global exception.
A list of fixes can be found on Bugzilla.
Tags: automation, firefox, mozmill, mozqa, testing
To help the team around the Memshrink project Mozilla QA Automation Services has released Mozmill Crowd 0.1.4. In this version the only changes which affect the extension itself are additions for the Endurance test-run, which allow users to specify the number of entities and if Firefox has to be restarted in-between each test.
We also have moved our Mozmill environments for all platforms from my own Mozilla people account to a new secure location on mozqa.com. In the future please always use this new location to grab the latest version of the environment.
For more information please see the tracking bug for Mozmill Crowd 0.1.4.
Tags: automation, crowd sourcing, firefox, mozilla, mozmill, mozqa, testing
On Friday Mozmill 1.5.4 has been finally released, including a lot of bug fixes and a couple of new features. This time it has been taken a bit longer as usual to get the release out, but the A-team is also working kinda hard on the Mozmill 2 code, where we expect a preview release kinda soon.
So thanks to everyone for their help in letting us get the following stuff out:
- Add support for Linux3 kernels (Bug 664564)
- Disable any preference for caching XUL elements (Bug 661588)
- The private property .documentLoaded has been renamed to .mozmillDocumentLoaded and a public API has been added to avoid namespace conflicts on window objects (Bug 661408)
- Don’t install distributed extensions from the application folder per default (Bug 661008)
- Add support for iFrames to the waitForPageLoad() method (Bug 659000)
- Expose full stack frames again after the Error properties are not enumerable anymore (Bug 650646)
- Add Mozmill version to the report document (Bug 636746)
If you haven’t upgraded yet, please do so by running: pip install --upgrade mozmill
This command will also upgrade all dependent tools necessary by Mozmill. For questions just drop by in our #mozmill channel on IRC.
Tags: automation, firefox, mozmill, mozqa, testing
As part of the discussions during our QA Automation Services work week end of July, we have decided to be more open to the public. We have seen that in the past mostly all conversations regarding tools, tasks, and status updates happened on our internal mailing list, which is not accessible by any of our contributors. Well, that’s counter-productive because we have dozens of smart and awesome community members out there who probably want to help and learn the techniques in automated testing. And we should give those the possibility to easily participate.
As result we have raised bug 676224 two weeks ago with the request to create a public facing mailing list and newsgroup. The creation has been a bit delayed but finally happened last Friday. So if you want to participate in automation, feel free to join by subscribing yourself to one of the following communication channels:
- Mailing List: https://lists.mozilla.org/listinfo/dev-automation
- Newsgroup: news://news.mozilla.org/mozilla.dev.automation
- Google Groups: http://groups.google.com/group/mozilla.dev.automation
We are looking forward to being able to discuss automation topics with you in a more collaborated fashion as before.
Tags: automation, mozilla, mozqa, testing
For a long time, exactly since January 29th in 2010, the Mozilla QA team is running daily Mozmill tests to prove the functionality of Firefox and the update system across all supported platforms and release branches. With those tests we were able to find a couple of regressions, which then were fixed before the next release of Firefox.
Given those results we have decided to extend our daily test-runs and not only run the functional and update tests, but also cover endurance tests, add-on tests, and the new remote tests.
Especially with the endurance tests, Dave Hunt has shown that we can retrieve a lot of useful memory related information and find regressions or bad interactions with add-ons very easily. So it makes a lot of sense to additionally perform those tests on Nightly and Aurora builds of Firefox. The test results can be found on our dashboard.
But also for add-on authors who have written Mozmill tests for their add-ons, we now provide test results. Regressions in the add-on or in Firefox itself can now be identified as close as possible. Currently only 2 add-ons have Mozmill tests and are being tested. If you are an add-on author get in contact with us, and we can work together to get your add-on tested.
Remote tests, which we haven’t talked about yet, are tests which connect the testing of the Firefox UI and remote websites. Those are fairly new, means they have been added recently, and currently only cover tests for the ‘Get Add-ons’ pane of the new Add-ons Manager. Those were necessary to create because Selenium can not automate the installation of add-ons. For the latest test results see our dashboard.
We are now looking forward to any regression we can detect with the newly added test-runs. And those we can not only identify by our daily test-runs, but also from reports sent by users of the Mozmill Crowd add-on. So please help us testing Firefox by sending your test reports. Thanks!
QA Automation Services is happy to announce that Mozmill Crowd 0.1.3 has been released. With this minor release Mozmill Crowd now got its own branding for the extension itself, and on AMO. Thanks goes to Tara Shahian and her team for their support in creating the icon. We think it looks brilliant. What do you think?
With the hiding of the menu bar on Windows we also had to introduce some more launch points for the extension. Now you can not only reach it via the Tools menu, but also in the Firefox button or the Add-on bar.
Beside the changes for the extension we have also updated the Mozmill test environment. If you are already an user of Mozmill Crowd, please open the chosen storage folder and delete the mozmill-*.zip and mozmill-env folder. With the next test-run Mozmill Crowd will automatically download and install the new version. With the upcoming Mozmill Crowd 0.2 this process will be fully automatic then. But as long as it is not available please run those steps manually. Thanks.
Tags: automation, crowd sourcing, firefox, mozilla, mozmill, mozqa, testing
As blogged by Release Engineering last week the Firefox 3.5 builds have been stopped. That means there are no more daily nightly builds available Mozilla QA will have to test with Mozmill. According to this action we also have turned off our daily test-runs for the latest Firefox 3.5.x builds on all platforms. At the same time the mozilla-1.9.1 branch of our mozmill-tests repository has been closed and as a good result, test failures which couldn’t be fixes due to limitations in Mozmill don’t exist anymore.
Recent Comments