Problem/Motivation

ContextualLinkClickTrait::clickContextualLink() was introduced to ease the interaction with contextual links in tests.

However, in some cases when using it multiple times within a single page load it can produce unexpected results.

Proposed resolution

Remove the ambiguity around toggling the .visually-hidden class, and with pressing the .contextual button

Remaining tasks

User interface changes

API changes

Data model changes

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tim.plunkett created an issue. See original summary.

Anonymous’s picture

In #2924201: Resolve random failure in LayoutBuilderTest so that it can be added to HEAD we found an unstable works of the Mink press(). So we had to replace it like:

+++ b/core/modules/layout_builder/tests/src/FunctionalJavascript/LayoutBuilderTest.php
@@ -380,7 +381,7 @@ protected function clickContextualLink($selector, $link_locator, $force_visible
-        $element->find('css', '.contextual button')->press();
+        $this->getSession()->executeScript("jQuery('$selector .contextual button').trigger('click');");

Also sometimes a bug with a non-working button on the first click can be reproduced manually on real sites. A few clicks help.

Anonymous’s picture

#2:

Also sometimes a bug with a non-working button on the first click can be reproduced manually on real sites. A few clicks help.

Separate issue for this #2926207: Contextual button sometimes not works. Bug in Chrome?.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Anonymous’s picture

After #2870452-39: Convert web tests to browser tests for menu_ui module (yes, I was not mistaken in the link) the clickContextualLink() will have to work much more stable. Because it will be independent of the initialization of contextual links.

Another source of instability for PhantomJS tests is

$element->find('css', '.contextual button')->press();
$element->findLink($link_locator)->click();

But this should not be a problem for WebDriver (see #2936122-6: Find out why JavscriptTestBase occasionally needs a waitForElement on a normal page load).

Therefore, I hope soon this issue will be no longer relevant.

Anonymous’s picture

Status: Active » Needs review
FileSize
1.99 KB

#2924201-56: Resolve random failure in LayoutBuilderTest so that it can be added to HEAD showed that the reliability promised by me in #5 did not come 😓

Why? Having cried well, I found few points:

Point 1.

if ($force_visible) {
  $this->toggleContextualTriggerVisibility($selector);
}

It switches the class regardless of its current state. If the button is visible, it will hide it. This is what can happens in 2924201-56.


Point 2.
Remove a ".visually-hidden" class does not guarantee that the button will immediately become visible. Because css transition (delay, duration) and other effects. See #2901792: Disable all animations in Javascript testing. Therefore, we should wait for this moment. This is what can happens in 2924201-56 too.
Point 3.
Point 2 refers to the contextual links that appear after clicking on the button.
Point 4.
If a general selector is used, resulting in several suitable context regions, a conflict occurs.
The attached patch struggles with all these points.
PS.
In general, this is still not an absolutely reliable method, because
 $page->waitFor(10, function () use ($page, $selector) {
      return $page->find('css', "$selector .contextual-links");
    });

We check the existence of a ".contextual-links" class that appears even before drupalContextualLinkAdded event. So, it is possible that a full-fledged readiness of contextual links has not yet come. It would be great if the contextual, quikedit, settings tray modules added some classes, meaning that they have already set up for this contextual link. But this is already beyond the scope of this issue.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

larowlan’s picture

Priority: Normal » Minor
Issue tags: +Bug Smash Initiative, +DX (Developer Experience), +Needs reroll
karishmaamin’s picture

Re-rolled patch against 9.4.x. Please review

Status: Needs review » Needs work

The last submitted patch, 15: 2918718-15.patch, failed testing. View results

yogeshmpawar’s picture

Issue tags: -Needs reroll
immaculatexavier’s picture

Status: Needs work » Needs review
FileSize
2.49 KB
1.15 KB

Re-rolled patch against #15 with interdiff for 9.4.x. Please review

Status: Needs review » Needs work

The last submitted patch, 18: 2918718-16.patch, failed testing. View results

immaculatexavier’s picture

larowlan’s picture

Status: Needs work » Needs review

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Needs review » Needs work

Patch or MR doesn't apply anymore
The last patch or MR doesn't apply to the target branch, please reroll the code so that it can be reviewed by the automated testbot.

_utsavsharma’s picture

Status: Needs work » Needs review
FileSize
2.02 KB

Rerolled for 10.1.x.

Status: Needs review » Needs work

The last submitted patch, 25: 2918718-25.patch, failed testing. View results

smustgrave’s picture

Status: Needs work » Needs review
FileSize
1.33 KB
3.11 KB
larowlan’s picture

Status: Needs review » Reviewed & tested by the community

This looks like a nice step forward

xjm’s picture

Priority: Minor » Major
Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs frontend framework manager review
Related issues: +#3267247: [meta] Fix and re-enable tests skipped for random failures

Bumping up from "minor"; any bugfix that means less random race condition stuff in our JS tests is probably at least major if it works as advertised.

  1. +++ b/core/modules/contextual/tests/src/FunctionalJavascript/ContextualLinkClickTrait.php
    @@ -16,20 +16,37 @@ trait ContextualLinkClickTrait {
    +   *   Exception if more than one contextual links found by selector.
    

    This contains a grammatical error. I'd suggest:

    Exception thrown when more than one contextual link is found with the given $selector.

  2. +++ b/core/modules/contextual/tests/src/FunctionalJavascript/ContextualLinkClickTrait.php
    @@ -16,20 +16,37 @@ trait ContextualLinkClickTrait {
    +      throw new \Exception('More than one contextual links found by selector');
    

    Could we put some debug information in this exception message, like $selector for example?

    Also, there's a grammatical error. I'd suggest:

    The selector '$selector .contextual-links' was found more than once on the page.

  3. +++ b/core/modules/contextual/tests/src/FunctionalJavascript/ContextualLinkClickTrait.php
    @@ -16,20 +16,37 @@ trait ContextualLinkClickTrait {
    +      $button = $page->waitFor(10, function () use ($element) {
    +        $button = $element->find('css', '.contextual button');
    +        return $button->isVisible() ? $button : FALSE;
    +      });
    +      $button->press();
    +      $link = $page->waitFor(10, function () use ($link) {
    +        return $link->isVisible() ? $link : FALSE;
    +      });
    

    Don't we usually do waitForElementVisible() rather than waiting a magical 10 seconds? Tagging for FEFM review on this point.

  4. +++ b/core/modules/layout_builder/tests/src/FunctionalJavascript/InlineBlockTestBase.php
    @@ -163,6 +163,11 @@ protected function addInlineBlockToLayout($title, $body) {
    +    // Avoid multiple selectors.
    

    This comment could be expanded a bit as I'd have no idea what it meant if I hadn't read this issue.

This might also help with some of the issues in #3267247: [meta] Fix and re-enable tests skipped for random failures. We should test those tests with this change.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.