WWW::Mechanize::Firefox::Troubleshooting - Things to watch out for
There is a version of the browser codebase that is supposedly still maintained. It is distributed under the name Waterfox at:
https://www.waterfoxproject.org/en-US/waterfox/desktop/
Currently it does not seem to be compatible with the mozrepl plugin, so WWW::Mechanize::Firefox will not work with Waterfox.
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. Please see WWW::Mechanize::Firefox::Installation for more information.
Failed to connect to , problem connecting to "localhost", port 4242: Connection refused at ...
The mozrepl plugin is not correctly installed or not configured to listen in Firefox on port 4242.
mozrepl
Check that Firefox is listening on port 4242:
telnet localhost 4242
If this does fail with some error message, you have either a firewall issue or the mozrepl extension is not properly installed.
Go through the steps in WWW::Mechanize::Firefox::Installation to verify that the mozrepl extension is installed.
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, );
->content_as_png
This error is caused because of Firefox 4 bug 649924 (https://bugzilla.mozilla.org/show_bug.cgi?id=649924). It seems that the Firefox canvas element is size-limited when hardware acceleration is enabled.
canvas
Until that bug is fixed, disable hardware acceleration and restart Firefox 4.
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-2018 by Max Maischein corion@cpan.org.
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.