Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

form_with_fields versus _field_by_name (inconsistent results) #48

Closed
castaway opened this issue Dec 3, 2019 · 6 comments
Closed

form_with_fields versus _field_by_name (inconsistent results) #48

castaway opened this issue Dec 3, 2019 · 6 comments

Comments

@castaway
Copy link

castaway commented Dec 3, 2019

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?

@Corion
Copy link
Owner

Corion commented Dec 6, 2019

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

@castaway
Copy link
Author

castaway commented Dec 6, 2019

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";

Corion pushed a commit that referenced this issue Dec 23, 2019
…get_attribute_future()

This is rather invasive but fixes GH issue #48 by respecting the
element subtree given as a reference, for example by ->current_form
to restrict results to the current form.
Corion pushed a commit that referenced this issue Dec 23, 2019
Error reports with reproducible code are great!
@Corion
Copy link
Owner

Corion commented Dec 23, 2019

v 0.42, now on CPAN should fix this problem.

Thank you for providing code to reproduce the issue!

@Corion Corion closed this as completed Dec 23, 2019
@castaway
Copy link
Author

Awesome, thanks!

@castaway
Copy link
Author

castaway commented Jan 2, 2020

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)

@Corion
Copy link
Owner

Corion commented Jan 3, 2020

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants