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

[InnerBrowser] click with context respects base tag #4330

Merged
merged 3 commits into from Jun 19, 2017

Conversation

Projects
None yet
3 participants
@Naktibalda
Member

Naktibalda commented Jun 15, 2017

Fixes #4311

@dhensby

This comment has been minimized.

Show comment
Hide comment
@dhensby

dhensby Jun 16, 2017

Thanks a lot for putting the time in to patch my issue. However, whilst this patch solves my specific issue, it is more of a "band-aid" solution than a complete one.

Symfony's BrowserKit Client holds an internalResponse which stores the original state as well as a response which stores the current filtered context. I feel this is an approach that should be mimicked.

I hypothesise that it would be possible to check for an element in a specific context and then attempt to check another outside that context (in a new context) and this would fail as the second check will only look within the filtered context and not the original context.

dhensby commented Jun 16, 2017

Thanks a lot for putting the time in to patch my issue. However, whilst this patch solves my specific issue, it is more of a "band-aid" solution than a complete one.

Symfony's BrowserKit Client holds an internalResponse which stores the original state as well as a response which stores the current filtered context. I feel this is an approach that should be mimicked.

I hypothesise that it would be possible to check for an element in a specific context and then attempt to check another outside that context (in a new context) and this would fail as the second check will only look within the filtered context and not the original context.

@dhensby

This comment has been minimized.

Show comment
Hide comment
@dhensby

dhensby Jun 16, 2017

OK - my hypothesis is incorrect; the uses of selectors in all other instances store the filtered nodes in a temporary variable and acts against those where as for click() the $crawler property is changed to hold the filtered nodes and this is the root of the problem.

This instance appears to be the only one where the filtered nodes are placed as the global context and not a temporary one.

This patch successfully provides a workaround.


edited: To be more clear

dhensby commented Jun 16, 2017

OK - my hypothesis is incorrect; the uses of selectors in all other instances store the filtered nodes in a temporary variable and acts against those where as for click() the $crawler property is changed to hold the filtered nodes and this is the root of the problem.

This instance appears to be the only one where the filtered nodes are placed as the global context and not a temporary one.

This patch successfully provides a workaround.


edited: To be more clear

@DavertMik DavertMik merged commit e797934 into Codeception:2.3 Jun 19, 2017

2 of 4 checks passed

semaphoreci The build failed on Semaphore.
Details
wercker/build Wercker pipeline failed
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@Naktibalda Naktibalda deleted the Naktibalda:click-respects-base-tag branch Jun 20, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment