Max Maischein

During the Easter weekend, I've started to write code supporting Firefox 4 in WWW::Mechanize::Firefox. So far, only some ugly parts of the restructuring of Firefox have broken WWW::Mechanize::Firefox. As my main application for it still runs Firefox 3.x, I have to support both versions, and especially not break any functionality for 3.x. So far, I could put most of the differences between Firefox 3.x and Firefox 4 into two submodules, WWW::Mechanize::Firefox::API35 respectively WWW::Mechanize::Firefox::API40. The constructor of WWW::Mechanize::Firefox does return either of these subclasses, depending on the version. This proves that you can't solve the problem of too many indirections by adding another layer.

As I have no real use case for Firefox 4 yet, I'm not sure whether there are more differences in when (and which) events fire during page load etc.. There is one nice glimmer of improvement for Firefox 4. I've found a Selenium test file that overrides many of the modal dialogs, so that I can now maybe implement ->proxy() for WWW::Mechanize::Firefox and suppress modal dialogs from blocking the whole application.

If you have Firefox 3.x and automate a critical application, don't blindly upgrade Firefox on your main machine. Firefox 4 and Firefox 3 will not peacefully coexist if you don't take preventive measures.

If you want to do a test drive of the upcoming version, take a look at the Firefox4 branch of the Github repository.