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:
Install mozrepl from
http://wiki.github.com/bard/mozrepl/
A direct link is
http://repo.hyperstruct.net/mozrepl/1.0/mozrepl.xpi
Launch Firefox
Start mozrepl in Firefox by going to the menu:
mozrepl
"Tools" -> "MozRepl" -> "Start"
You may want to tick the "Activate on startup" item.
Alternatively, launch the Firefox binary with the -mozrepl command line switch:
-mozrepl
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.
Solution:
Open t/50-click.html in Firefox
Allow Javascript for all file:// URLs
Re-run tests
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.
This section lists things that can (and will) happen which might block your Perl scripts from working properly with Firefox.
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
->get
->save_url
$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.
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.
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:
$mech->click('#a_link');
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:
synchronize => 0
$mech->click({ selector => '#a_link', synchronize => 0 });
This will tell WWW::Mechanize::Firefox not to wait for any response from the webserver.
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.
$mech
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.
$MozRepl::RemoteObject::WARN_ON_LEAK
STDERR
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
... undef $mech;
When taking a screenshot of a large page, the script crashes with
maximum input buffer length exceeded: 1048576 bytes ...
Pass the bufsize parameter to the WWW::Mechanize::Firefox constructor to give Net::Telnet a larger buffer:
bufsize
my $firefox = WWW::Mechanize::Firefox->new( bufsize => 10_000_000, );
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 corion@cpan.org
corion@cpan.org
Copyright 2010-2011, 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.
To install WWW::Mechanize::Firefox, copy and paste the appropriate command in to your terminal.
cpanm
cpanm WWW::Mechanize::Firefox
CPAN shell
perl -MCPAN -e shell install WWW::Mechanize::Firefox
For more information on module installation, please visit the detailed CPAN module installation guide.