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

Unable to click an element as it does not scroll above the webpage footer #2601

Closed
srijitdas8 opened this issue Jul 6, 2018 · 29 comments
Closed
Assignees
Labels
AREA: client STATE: Auto-locked An issue has been automatically locked by the Lock bot. SYSTEM: automations TYPE: bug The described behavior is considered as wrong (bug).
Milestone

Comments

@srijitdas8
Copy link

srijitdas8 commented Jul 6, 2018

Are you requesting a feature or reporting a bug?

Bug

What is the current behavior?

The webpage under test has a footer and the button to be clicked scrolls and comes behind the footer. Due to this, testcafe is unable to click on the button and the script fails.
Workaround used: Tried to use a client function with “ScrollBy” function. This works inconsistently. Works in one environment but does not work on another test environment

What is the expected behavior?

The button scrolls up automatically into the browser viewport above the webpages footer and testcafe is able to click the button

How would you reproduce the current behavior (if this is a bug)?

Since I am unable to share our application under test in our test environment. testcafe script with an sample website with similar footer and similar issue is provided below.

Provide the test code and the tested page URL (if applicable)

Attached testcafe script has the details
Tested page URL:

Test code

===================================
Testcafe sample code:

import { Selector } from 'testcafe';
import { ClientFunction } from 'testcafe';
fixture `Automation Testing Started...`

.page `https://www.fwd.com.sg`;


  const browserscroll = ClientFunction(function() {
    //  window.scrollBy(0, 100);
    window.scrollBy(0,1000)

      //document.scrollIntoView(true)
  })

test('Test', async t => {

  await t.maximizeWindow();
  await browserscroll();
  //await t.wait(5000);
	await t.click("body > nav:nth-child(2) > div.nav-container.top-nav.container-fluid > div.navbar-collapse.collapse > div > button");
	await t.click("#productListModalWrapper > div > div > div > ul > li:nth-child(2) > div.frame-container > svg");
	await t.click("#quickquestions > form > div:nth-child(1) > div:nth-child(2) > div > div.input-group__input > i");
	await t.click("#app > div.menu__content.menu__content--select.menu__content--auto.menuable__content__active > div > ul > li:nth-child(1) > a > div");
	await t.click("#TI_GetQuotepage_Next_1");
	await t.click("#TI_GetQuotepage_Promo_Skip");
	await t.click("#TI_QuoteSummarypage_Premium_Buy_Bottom");
	await t.click("#TI_BuyEnhacements_Continue_Yes"); // FAILS TO CLICK THIS BUTTON AS IT APPEARS BEHIND THE FOOTER
	await t.click("#coverage-list > ul > li:nth-child(4) > section > div.coverage__checkbox > div > div.input-group__input > div");
	await t.click("#TI_BuyEnhacements_Next_Submit");
	await t.typeText("#holder-form > div:nth-child(7) > div.flex.spinner-input.xs12.sm7 > input", "100060");
	await t.click("#traveller-details > div > div.consent > div.consent__checkbox > div > div.input-group__input > div");

})

===================================

Specify your

  • operating system: Windows 10 pro
  • testcafe version: 0.19.2 and 0.20.0
  • node.js version: 8.11.2
    *Browser version: 67.0.3396.99 (Official Build) (64-bit)
    *NPM: 5.6.0
@AndreyBelym AndreyBelym added TYPE: bug The described behavior is considered as wrong (bug). AREA: client SYSTEM: automations labels Jul 6, 2018
@AndreyBelym AndreyBelym added this to the Planned milestone Jul 6, 2018
@AndreyBelym
Copy link
Contributor

Hi @srijitdas8, I've reproduced the problem.

@srijitdas8
Copy link
Author

Hi Guys....Any luck with the issue. Appreciate your help...Thanks

@AndreyBelym AndreyBelym added this to Needs triage in Bugs triage Jul 13, 2018
@AndreyBelym AndreyBelym moved this from Needs triage to Automations in Bugs triage Jul 13, 2018
@AndreyBelym AndreyBelym moved this from Action Simulation to Scrolling in Bugs triage Jul 13, 2018
@AndreyBelym AndreyBelym moved this from Scrolling to Action Simulation in Bugs triage Jul 16, 2018
@AndreyBelym AndreyBelym moved this from Action Simulation to Scrolling in Bugs triage Jul 16, 2018
@AndreyBelym AndreyBelym added this to Candidates in Sprint #14 via automation Jul 16, 2018
@AndreyBelym AndreyBelym moved this from Candidates to To do: Automation Bugs in Sprint #14 Jul 16, 2018
@AndreyBelym AndreyBelym moved this from To do: Automation Bugs to Candidates in Sprint #14 Jul 16, 2018
@AndreyBelym AndreyBelym moved this from Candidates to To do: Automation Bugs in Sprint #14 Jul 16, 2018
@AndreyBelym AndreyBelym modified the milestones: Planned, Sprint #14 Jul 16, 2018
@AndreyBelym AndreyBelym self-assigned this Jul 25, 2018
@AndreyBelym
Copy link
Contributor

Hi @srijitdas8, I'm working on this.

@AndreyBelym AndreyBelym modified the milestones: Sprint #14, Sprint #15 Jul 30, 2018
@AlexKamaev
Copy link
Contributor

Hi @srijitdas8
We've optimized the scrolling mechanism in context of #2450 . It should also fix the current issue. Could you please check the issue with the latest (0.21.1) testcafe version?

@AndreyBelym AndreyBelym modified the milestones: Sprint #15, Sprint #16 Aug 14, 2018
@edenadler
Copy link

edenadler commented Aug 28, 2018

Hi @AlexKamaev and @AndreyBelym, since upgrading from version 0.20.5 to 0.21.1 I suddenly started experiencing the same issue as #2450. This seems to be a new issue as of the newer versions, because on version 0.20.5 this was not a problem. In 0.20.5, it would scroll to avoid the fixed element, but I don't see that same scrolling behavior happening in 0.21.1.

@AlexKamaev
Copy link
Contributor

Hi @edenadler
Would you please share your test page and test file? Could you also clarify in which browser you can reproduce the issue?

@AndreyBelym AndreyBelym modified the milestones: Sprint #16, Sprint #17 Aug 30, 2018
@edenadler
Copy link

Hi @AlexKamaev. I'm not able to share the test page and file, but I found a solution to the problem. The problem was that it is only scrolling horizontally but not vertically. I can submit a pull request for it. Since #2450 is already closed, let me know what ID I should submit it with.

@AlexKamaev
Copy link
Contributor

AlexKamaev commented Sep 4, 2018

I'm happy to hear that you solved the issue. If you think that it was connected to #2450, you can submit your PR with its ID. I'll take a look at your PR and review it; otherwise, you are free to open a separate issue and post it there.

@AlexKamaev AlexKamaev assigned AlexKamaev and unassigned AndreyBelym Jun 17, 2019
@AlexKamaev
Copy link
Contributor

@tbcoyle
I was not able to reproduce the issue in your example in Chrome, but I managed to reproduce it in Firefox. I'll reopen the issue for further research.
I greatly appreciate your providing the sample.

@AlexKamaev AlexKamaev reopened this Jun 17, 2019
@need-response-app need-response-app bot removed the STATE: Need response An issue that requires a response or attention from the team. label Jun 17, 2019
@AlexKamaev AlexKamaev added this to the Sprint #35 milestone Jun 17, 2019
@AlexKamaev AlexKamaev added TYPE: bug The described behavior is considered as wrong (bug). and removed STATE: Need clarification An issue lacks information for further research. labels Jun 17, 2019
@no-response
Copy link

no-response bot commented Jun 17, 2019

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

@no-response no-response bot closed this as completed Jun 17, 2019
@AlexKamaev AlexKamaev reopened this Jun 17, 2019
@tbcoyle
Copy link

tbcoyle commented Jun 17, 2019

@AlexKamaev

Thank you for investigating. It is odd that the issue seems to be reproducible only in Firefox, as I am using Chrome. Perhaps there is an issue with my example file.

Please see below another example on a live site (note - I am running with "skipJsErrors": true):

import {Selector as $} from 'testcafe';

fixture`Testcafe 2601`
	.page`https://www.kcrw.com`;

test('Case A - Click fails - target element is within window but fully subsumed by fixed footer', async (t) => {
	const TARGET_INDEX = 4; // svg.icon-more is WITHIN window for 4th index

	await t
		.resizeWindow(1500, 800)
		.click('a.logo-link')
		.click('#nav-playlist')
		.click($('div.track.clearfix:not(.episode_Break)').nth(TARGET_INDEX).find('svg.icon-more'));

	await t
		.wait(2000)
		.expect(await $('div.track.clearfix.expanded').count)
		.eql(1, 'Successfully clicked the more-info arrow and expanded row');
});

test('Case B - Click succeeds - target element is below window and scroll occurs successfully', async (t) => {
	const TARGET_INDEX = 5; // svg.icon-more is BELOW window for 5th index

	await t
		.resizeWindow(1500, 800)
		.click('a.logo-link')
		.click('#nav-playlist')
		.click($('div.track.clearfix:not(.episode_Break)').nth(TARGET_INDEX).find('svg.icon-more'));

	await t
		.wait(2000)
		.expect(await $('div.track.clearfix.expanded').count)
		.eql(1, 'Successfully clicked the more-info arrow and expanded row');
});

Here is what I see for Case A:

  1. Testcafe navigates to page
  2. Testcafe "Waiting for element to appear..." message shows up on the shadow ui bar
  3. Testcafe waits for specified timeout period
  4. Testcafe clicks the position on the fixed footer corresponding to the target element's position on the page

The issue in this example is that Testcafe should have scrolled before clicking in step 4. With Case B, you can see that Testcafe does indeed scroll before clicking, which is the intended behavior. The difference between Case A and Case B is simply that in Case A the target element is contained within the current window (but hidden beneath the fixed footer), whereas in Case B the target element is below the window.

Given the above, I would suspect that the mechanics of scrolling is working properly - the issue may be with deciding under what conditions a scroll should occur.

I did a little more investigating and found that the issue appears to have been introduced between Testcafe v0.22.0 and v0.23.0. I am seeing the test for Case A passing in v0.22.0 and failing in v0.23.0.

Please let me know if I can provide any additional information - we are motivated to be helpful as we are stuck in v0.22.0 for now.

@need-response-app need-response-app bot added the STATE: Need response An issue that requires a response or attention from the team. label Jun 17, 2019
@AlexKamaev
Copy link
Contributor

@tbcoyle
Thank you for another example. I was able to reproduce the issue in Chrome. I hope to fix it in the near future.
 

@need-response-app need-response-app bot removed the STATE: Need response An issue that requires a response or attention from the team. label Jun 18, 2019
@AlexKamaev AlexKamaev assigned AlexKamaev and unassigned AlexKamaev Jun 19, 2019
@AlexKamaev
Copy link
Contributor

@tbcoyle
I researched both your examples and found that they have different causes. So I created a separated ticked for this one #2601 (comment)
Please refer to it #3924

@Krappt
Copy link

Krappt commented Jun 24, 2019

@AlexKamaev I am surprised! I have the same problem in Chrome, Firefox and Opera. It only works in Edge and Safari. Page doesn't scroll to element and tests are always failed.

This is a basic function. How can this not work?

@need-response-app need-response-app bot added the STATE: Need response An issue that requires a response or attention from the team. label Jun 24, 2019
@AlexKamaev
Copy link
Contributor

@Krappt
If your scenario is the same as @tbcoyle has, this means that page markup has some specifics, which break our calculations. I'm working on this right now, so I hope to provide a fix soon.

@need-response-app need-response-app bot removed the STATE: Need response An issue that requires a response or attention from the team. label Jun 25, 2019
@AndreyBelym AndreyBelym modified the milestones: Sprint #35, Sprint #36 Jul 1, 2019
@lock
Copy link

lock bot commented Jul 13, 2019

This thread has been automatically locked since it is closed and there has not been any recent activity. Please open a new issue for related bugs or feature requests. We recommend you ask TestCafe API, usage and configuration inquiries on StackOverflow.

@lock lock bot added the STATE: Auto-locked An issue has been automatically locked by the Lock bot. label Jul 13, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jul 13, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
AREA: client STATE: Auto-locked An issue has been automatically locked by the Lock bot. SYSTEM: automations TYPE: bug The described behavior is considered as wrong (bug).
Projects
Bugs triage
  
Closed
Sprint #14
  
Done
Development

No branches or pull requests

10 participants