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

E2E: Refactor clickWhenClickable() helper #50911

Merged
merged 8 commits into from Mar 17, 2021

Conversation

WunderBart
Copy link
Member

@WunderBart WunderBart commented Mar 9, 2021

Changes proposed in this pull request

  • Refactored DriverHelper.clickWhenClickable() to make sure that element is enabled before clicking. This should address some general flakiness where a clicked element is (initially) disabled (due to i.e. pending request).
  • The above revealed an issue with the ensureMobileMenuOpen helper, where the findElement & clickWhenClickable methods weren't called via await and, as a result, returning an unreliable state of the menu. This PR fixes that.

Testing instructions

Specs should pass :)

@matticbot
Copy link
Contributor

@WunderBart WunderBart force-pushed the refactor/e2e-tweaks-part-005 branch from 62d905a to 6dc6043 Compare March 9, 2021 17:47
@matticbot
Copy link
Contributor

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

@WunderBart WunderBart changed the title E2E: DriverHelper tweaks part 1 E2E: Refactor clickWhenClickable() helper Mar 10, 2021
@@ -530,7 +529,7 @@ export async function selectElementByText( driver, selector, text ) {
const allElements = await driver.findElements( selector );
return await webdriver.promise.filter( allElements, getInnerTextMatcherFunction( text ) );
};
return await this.clickWhenClickable( driver, element, null, `while looking for '${ text }'` );
return await this.clickWhenClickable( driver, element );
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm removing this only temporarily. Already working on a refactor that would include displaying similar message in #50944.

@WunderBart
Copy link
Member Author

WunderBart commented Mar 12, 2021

There's one failing flaky spec that can be ignored. It's being addressed in #50999.

@WunderBart WunderBart marked this pull request as ready for review March 12, 2021 13:28
@WunderBart WunderBart added [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. and removed [Status] In Progress labels Mar 12, 2021
WunderBart added a commit that referenced this pull request Mar 12, 2021
WunderBart added a commit that referenced this pull request Mar 16, 2021
* @param {By} locator The element's locator
* @returns {WebElementCondition} The new condition
*/
elementIsClickable( locator ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Neat way to logically group this as a local extension based on the until object 👍🏻

.getAttribute( 'aria-disabled' )
.then( ( v ) => v !== 'true' );

return isEnabled && isAriaEnabled ? element : null;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if / could it happen that the element isEnabled but not isAriaEnabled? The && here seems to suggest that it might be possible.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question, because AFAIK it's how we actually disable elements in Gutenberg (most probably because of the inconsistency issue between screen readers). So when an element is enabled, but at the same time it's aria-disabled="true" (i.e. the Publish button) it should be treated just like a disabled element would, which in the result should be a non-clickable/non-actionable element.

@fullofcaffeine
Copy link
Member

fullofcaffeine commented Mar 17, 2021

helper, where the findElement method was not called via await and, as a result, returning an unreliable state of the menu. This PR fixes that.

Out of curiosity, it'd be great if you could elaborate on why it was failing as a result of being called without an await, as it's not entirely clear to me.

Copy link
Member

@fullofcaffeine fullofcaffeine left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code looks great! I see that the remaining failed Desktop E2E test is related to the loginc magic link, which is being addressed in another PR(s). 🚢

@WunderBart
Copy link
Member Author

WunderBart commented Mar 17, 2021

helper, where the findElement method was not called via await and, as a result, returning an unreliable state of the menu. This PR fixes that.

Out of curiosity, it'd be great if you could elaborate on why it was failing as a result of being called without an await, as it's not entirely clear to me.

Of course! The driver.findElement method returns a promise, so we need to either return it in the chain or await for it before it's resolved. The same goes for clickWhenClickable. We weren't doing that (#1, #2), so the actual result of the promise was not returned by that helper in time. Does that make sense?

@WunderBart WunderBart added [Status] Ready to Merge and removed [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. labels Mar 17, 2021
@matticbot matticbot added the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Mar 17, 2021
@WunderBart WunderBart removed the [Status] Needs Review The PR is ready for review. This also triggers e2e canary tests and wp-desktop tests automatically. label Mar 17, 2021
@WunderBart WunderBart merged commit 0c8c8f2 into trunk Mar 17, 2021
@WunderBart WunderBart deleted the refactor/e2e-tweaks-part-005 branch March 17, 2021 11:14
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.

None yet

3 participants