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

bug fixes: async, markup, Poltergeist (plus methods for checking state) #15

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

eostrom
Copy link

@eostrom eostrom commented Aug 3, 2013

See the respective commits. Sorry these aren't all separate pull requests; I just had to get this all working for my project, so it's all in one branch.

eostrom added 4 commits August 2, 2013 23:53
The scenario: press a button that (perhaps via AJAX) causes a select2
with a label to appear asynchronously. This test would fail:

    click_button('Make a Select2')
    select2('My Choice', from: 'The Newly Created Select2')

because the label isn't present immediately, and `first("label", ...)`
doesn't wait for the label to appear. `find` does.

This change will cause an error to be raised if there's more than one label
with the given text. The solution here is to limit the scope using
`within`, and/or use a selector instead of text to find the select2.
The previous code expected the select2 to be inside the innermost div
containing the label. That won't necessarily hold for all scenarios (for
example, the "Inline Labels" markup for Zurb Foundation). So now we use
the label to find the element that it gives focus to, and then search up
the DOM to find the select2-container.
In the single-select scenario, we clicked the "choice" element (to open
the dropdown), then clicked it again during the "values" loop. This
probably works on some Capybara drivers, but Poltergeist noticed that
the second time we tried to click, the choice element was obscured by
select2's dropdown mask.

There's no reason to click the choice element twice in the single-select
UI. But we do need to click it once for each value in the
multiple-select UI. So now we just check which UI is in use, and act
appropriately.

BTW, we do the single-select click *before* we enter the search term. I
suspect search doesn't work in the multiple-select UI, but it didn't
work before this change, either.
Useful for examining the select2's current state.

It would probably be better to have a single method

    expect_select2('Expected Value(s)', from: 'My Select')

but I haven't done that yet.
@anark
Copy link

anark commented Oct 16, 2013

👍 This makes capybara-select2 work with poltergeist. Thank You

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

Successfully merging this pull request may close these issues.

2 participants