Skip to content
This repository has been archived by the owner on Dec 24, 2023. It is now read-only.

checkFullPageScreen method is not calculate correctly the scroll height #22

Open
amolinaalvarez opened this issue Jun 24, 2019 · 10 comments
Assignees
Labels

Comments

@amolinaalvarez
Copy link

amolinaalvarez commented Jun 24, 2019

Environment:

  • Node.js version: 8.12.0
  • NPM version: 6.4.1
  • Browser name and version: Chrome 72.0.3626.96
  • Platform name and version: Ubuntu 16.04
  • Framework name and version: Protractor 5.4.2
  • Plugin name and version: protractor-image-comparison 3.2.0
  • webdriver-image-comparison version: 0.5.0

Config of the automation framework + plugin
here a basic example of how my conf.js looks like:

exports.config = {
   framework: 'jasmine',
   multiCapabilities: env.multiCapabilities,
   baseUrl: env.baseUrl,
   specs: [
     'image-comparator.spec.js',
   ],
   SELENIUM_PROMISE_MANAGER: false,
   directConnect: true,
}

Describe the bug
Using the checkFullPageScreen method with a dialog which blocks the browser's scroll, I am getting a weird behavior as the way of calculating the scroll height is not working well.

To Reproduce
I created this simple example: https://angular-5sbdat.stackblitz.io/

and this is basic my test:

describe('compare example screen', () => {
  beforeEach(async () => {
    await browser.waitForAngularEnabled(false);
    await browser.get("https://angular-5sbdat.stackblitz.io/");
  });

  it('should compare login page with a baseline', async () => {
    await browser.sleep(3000);
    await element.all(by.css('button')).get(0).click();
    expect(await browser.imageComparison.checkFullPageScreen('test')).toEqual(0);
  });
});

Using the version 0.4.8 I am getting this result (the desired one):
test2--1855x1056

However using the version 0.5.0:
test--1855x1056

As you can see, using the version 0.5.0 checkFullPageScreen method is scrolling down but it does not make sense because the scroll is blocked by the dialog.

@wswebcreation
Copy link
Owner

@amolinaalvarez

Thanks for filling the issue, it's related to this one

#21

Will come up with a fix asap

@wswebcreation
Copy link
Owner

Hi @amolinaalvarez

Ive release version 3.3.0 for `protractor-image-comparison, see here. Can you please try that one and see if it is fixed? If so, can you close this issue?

@amolinaalvarez
Copy link
Author

Thanks for your prompt response, unfortunately I came across the same issue after updating the version.

@wswebcreation
Copy link
Owner

@amolinaalvarez

Thanks for you quick response, can you check 2 things for me

  1. What version of the webdriver-image-comparison is stored in your package-lock.json file?
  2. Can you share you config of the plugin?

Tnx

@amolinaalvarez
Copy link
Author

"protractor-image-comparison": {
      "version": "3.3.0",
      "resolved": "https://registry.npmjs.org/protractor-image-comparison/-/protractor-image-comparison-3.3.0.tgz",
      "integrity": "sha512-XDYQ1NE6bD3SjtAZGCbnq11V3gthJLX2LDmwYgmIFu0U8A8K4oUS9VPfHHrB04+Lt0WC4hvZWmXV2zVep7iTZA==",
      "requires": {
        "webdriver-image-comparison": "^0.6.0"
      }
},
{
      package: require.resolve('protractor-image-comparison'),
      options: {
        baselineFolder: join(process.cwd(), './baseline/'),
        formatImageName: `{tag}-{logName}-{width}x{height}`,
        screenshotPath: join(process.cwd(), '.tmp/'),
        savePerInstance: true,
        autoSaveBaseline: true,
      },
 },

I hope it could be helpful!

@wswebcreation
Copy link
Owner

wswebcreation commented Jul 4, 2019

Hmm, let me check, I'll get back to it

You are right, I see the problem. The problem is in the new getDocumentScrollHeight , see https://github.com/wswebcreation/webdriver-image-comparison/blob/master/lib/clientSideScripts/getDocumentScrollHeight.ts#L11

There were issues on different pages (depending on how the page was build) that the scrollheight was not determined correctly.
I might need to rethink this logic.

My question to you is what the reason is use the fullpage screenshot method here?

@wswebcreation wswebcreation self-assigned this Jul 4, 2019
@tomyam1
Copy link
Contributor

tomyam1 commented Oct 11, 2019

I have a similar issue with a modal dialog.

I think the underlying issue is that the scrolling and the calculations are done on the body but they should be done on the the scrolling container.

For instance, when using bootstrap, e.g. http://embed.plnkr.co/Ds4U0Nbmth8gj6RYF9iV/,
it should be done on the .modal div.

Maybe a good solution would to make the scrolling element configurable, e.g. by providing a query to be valudated with querySelector?

@wswebcreation
Copy link
Owner

Hi @tomyam1

It's always hard for a module to detect how the page works and what element should be the element that should be scrolled. Each page is different. What would your proposal be?

@tomyam1
Copy link
Contributor

tomyam1 commented Oct 15, 2019

I think a good initial solution would be to let the user define the scrolling element using a scrollingElement: string optional parameter.

If given, it will be used instead of document.scrollingElement.

This won't be a solution of for all the possible use cases, but it does solve the modal dialog case at hand which is very common.

(I'm afraid I cannot afford the time to work on a PR for this at the moment)

@mhdSid
Copy link

mhdSid commented Sep 29, 2022

@wswebcreation
Could it just use browser.screenshot({...}) instead? without having a custom method to take screenshots?

An alternative solution would be to use puppeteer instance and use page.screenshot({...})

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

No branches or pull requests

4 participants