Max Maischein > WWW-Mechanize-Firefox-0.73 > WWW::Mechanize::Firefox::Troubleshooting

Download:
WWW-Mechanize-Firefox-0.73.tar.gz

Annotate this POD

CPAN RT

New  1
Open  0
View/Report Bugs
Source   Latest Release: WWW-Mechanize-Firefox-0.76

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.

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.

syntax highlighting: