NAME
WWW::Mechanize::Firefox::Troubleshooting - Things to watch out for
Installation
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 1.1.0 available from
http://wiki.github.com/bard/mozrepl/
respectively
https://github.com/bard/mozrepl/tags
You will need to edit the
.zip
file into a.xpi
file.Launch Firefox
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 -repl
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.
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.
Solution
Find where Firefox pops up the dialog and replace that with a callback to Perl.
Workaround
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.
Solution
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.
Workaround
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.
Solution
Find where Firefox pops up this dialog and override the display with a function that supplies the appropriate credentials directly.
Workaround
There is no workaround.
Scripting
Clicking on a link makes the Perl script wait forever
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.
Solution
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.
Solution
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;
The script crashes with maximum input buffer length exceeded
When taking a screenshot of a large page, the script crashes with
maximum input buffer length exceeded: 1048576 bytes ...
Solution
Pass the bufsize
parameter to the WWW::Mechanize::Firefox constructor to give Net::Telnet a larger buffer:
my $firefox = WWW::Mechanize::Firefox->new(
bufsize => 10_000_000,
);
Javascript error "0x8007000e (NS_ERROR_OUT_OF_MEMORY)" on ->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.
Workaround
Until that bug is fixed, disable hardware acceleration and restart Firefox 4.
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.
AUTHOR
Max Maischein corion@cpan.org
COPYRIGHT
Copyright 2010-2012 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.