Add click and scrollIntoView abstractions

[simonua]

It would be nice to abstract the click and scrollIntoView calls a little, so that code such as

(() => browser.executeScript('arguments[0].scrollIntoView();', this.locatorButton.webMail))
(() => browser.executeScript('arguments[0].click();', this.locatorButton.webMail))

could be rewritten as

(() => browser.scrollIntoView(this.locatorButton.webMail))
(() => browser.click(this.locatorButton.webMail))

If there's interest in and support for this, I'd be happy to contribute more (unit tests, etc.), if needed, to bring this to completion.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

:memo: Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

:memo: Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here (e.g. I signed it!) and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

[simonua]

I signed it!

[googlebot]

CLAs look good, thanks!

[googlebot]

CLAs look good, thanks!

[simonua]

Tests appear to have failed due to unrelated items.

[Pablodotnet]

@simonua Remember scrollIntoView can have an optional parameter to align it to top or not, it should be on your abstraction too as it is very useful to use that parameter 👍

[simonua]

Good point, @Pablodotnet. I pushed an update. I'm thinking this may cover:

[Pablodotnet]

That's perfect! Hope this pull request get merge soon 💯

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google. In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

[simonua]

@qiyigg, I merged upstream/master into my master and the CLA dropped out. Could you please advise what should be done? Also, is there merit to this PR, please?

[awarecan]

To be honest, I didn't get it. Is an enhancement of ElementFinder.scrollIntoView() better?

Moreover, I don't think browser.click() is better than ElementFinder.click(), it looks like an anti-protractor design for me.

[simonua]

@awarecan, syntactical sugar to abstract common and specific aspects of executeScript. To me, it makes it more readable and understandable.

[qiyigg]

@simonua in general, you shouldn't use any "merge" command. You should use "rebase" instead. I guess you merged other's commit into your commit and now it is contributed by two people and CLA doesn't like it.

For this PR itself. I don't fully understand the purpose of doing so. what's the purpose of using this: (() => browser.executeScript('arguments[0].click();', this.locatorButton.webMail))

rather than: this.locatorButton.webMail.click()

Usually we use browser.executeScript when we want to get the "return value"

[awarecan]

1. proposed browser.click() As my understanding, your intention is to click some DOM element which is not clickable by define of WebDriver protocol. I remembered there was some discussion when Selenium decided move to WebDriver around the same issue. Your proposal is the way Selenium 1.0 (Selenium RC) handle clicking, and the major argument at that time was WebDriver no longer allow click invisible element. From e2e testing perspective, I strongly support WebDriver way, if user cannot see the element in browser, there is no reason your test script should click it.

2. proposed browser.scrollIntoView() In WebDriver protocol, the interactive with element such as click and sendKeys will scroll into view first. That eliminates the majority usage of your browser.scrollIntoView. Actually, in Selenium, there are already tons of code to make sure the WebDriver protocol got implemented right, for example https://github.com/SeleniumHQ/selenium/blob/74e584d12ba31bb2e1b61b17a4751402c70c6da6/javascript/atoms/action.js#L601-L619 In my newer project, I use scroll fewer and fewer actually. Even you still want to introduce that function, I will suggest that put it into ElementFinder. I feel that

this.locatorButton.webMail.scrollIntoView()

is better than

browser.scrollIntoView(this.locatorButton.webMail)

How do you think?

[simonua]

@qiyigg and @awarecan, thank you very much for your feedback. I'll dig into your suggestions a bit in my project to see if I still see as much validity for this PR. I appreciate you!

[Pablodotnet]

@awarecan

the interactive with element such as click and sendKeys will scroll into view first. That eliminates the majority usage of your browser.scrollIntoView.

I can't agree with this, personally I struggle with a lot of situations where the test failed because it says "element not visible" or "other element will receive click" and I need to scroll to them using scrollIntoView, that automatic scroll you say fails a lot of times.

[simonua]

@Pablodotnet, I've had similar experiences, which motivated me to create the abstraction.

[simonua]

I don't think I am opposed to putting it with ElementFinder. That would still appear to be a semantic way, just a different angle. Would that change gain support?