Corion / WWW-Mechanize-Chrome

automate the Chrome browser

Home Page:https://metacpan.org/release/WWW-Mechanize-Chrome

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

form_with_fields versus _field_by_name (inconsistent results)

castaway opened this issue · comments

commented

I'm attempting to load, then fill in, the amazon.co.uk signin page .. I get as far as "wait_until_visible" (the email input field is loaded by js.. why, who knows).. but then get stuck.

It seems the various xpath fetches don't all do the same things (is my guess):

  • form_with_fields('email','password') - this one works / no errors, selects the signIn form, as expected

  • _field_by_name(name => 'email', ..) as called by get_set_value (and ultimately from submit_form(with_fields => {email => '...'}); - this one doesnt, we get No elements found for input with name 'email'

  • xpath 1 (works):
    //form[.//*[(local-name(.)="input" or local-name(.)="select" or local-name(.)="textarea") and @name="email"] and .//*[(local-name(.)="input" or local-name(.)="select" or local-name(.)="textarea") and @name="password"]]

  • xpath 2 (fails):
    .//*[(local-name(.)="input" or local-name(.)="select" or local-name(.)="textarea") and @name="email"]

Any ideas?

Hi Jess,

the two XPath expressions are not the same:

Passes:

//form[.//*

Fails:

.//*[(local-name(.)="input" 

Some short code replicating the situation, or ideally, the actual, ideally self-contained HTML page (+JS) to reproduce the problem would help me diagnose this far better...

commented

Yup I see they arent, yet they both get used to find fields in a form..

We're trying to login to: https://www.amazon.co.uk/gp/yourstore/iyr/ref=pd_ys_iyr_edit_watched?ie=UTF8&collection=watched (which presents a signin page if not logged in)

Code:

my $mech = WWW::Mechanize::Chrome->new(
    #tab => qr/amazon/,
    autoclose => 0,
    launch_exe => '/usr/bin/google-chrome-stable',
    host => 'localhost',

    background_networking => 0,
    autodie => 1,
    report_js_errors => 1,
    incognito => 1,

    );
$mech->allow( javascript => 1 );
#my $mech = WWW::Mechanize->new();
say "Created mechanize, getting initial page.";
$mech->get('https://www.amazon.co.uk/gp/yourstore/iyr/ref=pd_ys_iyr_edit_watched?ie=UTF8&collection=watched');
say "Loaded first-level form, waiting until visible";

$mech->wait_until_visible(
    selector => '#ap_email',
    timeout => 30
);

say "Waited until visible";
if($mech->is_visible(selector => '#ap_email')) {
    say "Yup, visible";
}

{
    open my $fh, ">", "login_1.html" or die;
    print $fh $mech->content;
}

$mech->dump_forms;

## Works:
$mech->form_name('signIn');

# Just checking.. yup its there:
my @text = $mech->selector('#ap_email');
say $_->get_attribute('outerHTML') for @text;

# Works
$mech->form_with_fields('email', 'password');
print $mech->current_form()->get_attribute('outerHTML');
# Fails!
$mech->submit_form(with_fields => {email => 'foo@bar.baz'});

say "Submitting form";

v 0.42, now on CPAN should fix this problem.

Thank you for providing code to reproduce the issue!

commented

Awesome, thanks!

commented

works!

Did you intend to break: $mech->current_form()->get_attribute('outerHTML'); btw? it now prints HASH(0x...) instead of the HTML (we were just using it for debugging)

Oops - no, that was not intended (and also not in the test suite ...)!

Thanks for finding this and telling me, I'll release a fix soon!