/ 
WWW-Mechanize-Firefox-0.76
River stage one • 2 direct dependents • 2 total dependents
/ WWW::Mechanize::Firefox::Troubleshooting

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. 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.

  1. 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.

  2. Go through the steps in WWW::Mechanize::Firefox::Installation to verify that the mozrepl extension is installed.

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

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-2014 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.