WWW::Mechanize::Firefox::Troubleshooting - Things to watch out for


If you notice that tests get skipped and/or the module installs but "does not seem to work", there are some more steps required to configure Firefox:

  1. Install mozrepl from

    A direct link is

  2. Launch Firefox

  3. Start mozrepl in Firefox by going to the menu:

       "Tools" -> "MozRepl" -> "Start"

    You may want to tick the "Activate on startup" item.

    Alternatively, launch the Firefox binary with the -mozrepl command line switch:

      firefox -mozrepl

    If tests still fail, especially t/50-click.t and 51-mech-submit.t , this might be because you use the NoScript Mozilla extension and have it blocking Javascript for file:// URLs. While this is good, the tests need Javascript enabled.


    1. Open t/50-click.html in Firefox

    2. Allow Javascript for all file:// URLs

    3. Re-run tests

    4. No test should fail

    If tests fail with an error from Firefox that a file could not be found, check that the test suite and the Firefox process are run using the same user. Otherwise, the Firefox process might not have the permissions to access the files created by the test suite.

Dialogs that break your application

This section lists things that can (and will) happen which might block your Perl scripts from working properly with Firefox.

Save-As Dialog Displays

If a webserver sends the appropriate headers, Firefox will ask the user where to save a file. This dialog will pop up and stall the Perl application until a user clicks "OK" to confirm where to save the file.


Find where Firefox pops up the dialog and replace that with a callback to Perl.


In many cases, you can instruct Firefox to always save files into the same folder. This may or may not be acceptable. You can directly call ->get or ->save_url and also specify where to save the content by using

  $mech->get( $url, ':content_file' => $tempfile );

or alternatively

  $mech->save_url( $url => $target_filename );

Both of these workarounds require you to know the URL you want to download.

Updates to Firefox Add-Ons

The dialog notification for new versions of Add-Ons is not yet automated. If Firefox pops up this dialog, your application will stall until a human closes this dialog.


Find where Firefox pops up this dialog and override the display either through a setting or through replacing the Javascript code with the appropriate Perl code.


Disable checking for and notification about updated Add-Ons.

Proxy password

If a fresh Firefox process is launched and a proxy is configured, Firefox will ask for the credentials needed for that proxy. The Perl script will stall until a human enters or confirms the credentials.


Find where Firefox pops up this dialog and override the display with a function that supplies the appropriate credentials directly.


There is no workaround.


If you have something like the following code:


WWW::Mechanize::Firefox expects a HTTP interaction ("a web request") to ensue and will wait until a new page is loaded. If the element your script clicks on only changes some aspect of the Javascript page, like acknowledging a message, then no HTTP interaction will occur and your script will wait forever.


For those requests, pass the synchronize => 0 option:

  $mech->click({ selector => '#a_link', synchronize => 0 });

This will tell WWW::Mechanize::Firefox not to wait for any response from the webserver.

A tab remains open even after the program closes

If you have something like the following code:

  my $mech = WWW::Mechanize::Firefox->new();

  sub page_title {
      $mech->selector( 'div.title', single => 1 )->{innerHTML};

then Perl will keep the $mech object alive until the program ends and Global Destruction of all objects starts. As Global Destruction happens in a non-deterministic order, this will sometimes prevent the $mech object from properly closing the Firefox tab attached to it.

For debugging whether that is really the cause, set $MozRepl::RemoteObject::WARN_ON_LEAK to a true value. This will emit warnings to STDERR if objects cannot release their Firefox counterpart during Global Destruction.


Pass the $mech object around as parameter:

  my $mech = WWW::Mechanize::Firefox->new();

  sub page_title {
      my ($mech) = @_;
      $mech->selector( 'div.title', single => 1 )->{innerHTML};

Alternatively, explicitly set $mech to undef at the end of your main program:

  undef $mech;

Known Problems

Page Encoding Versus Perl Encoding

Currently, whatever Firefox delivers as the page content is decoded to UTF-8 unless it already is. This is likely not the case in some situations, for example with pages encoded in koi-8. Please send me test cases where decoding fails or does not produce the correct data.


Max Maischein


Copyright 2010, Max Maischein.

All Rights Reserved. This module is free software. It may be used, redistributed and/or modified under the same terms as Perl itself.