Contrib.social

Radio buttons report as not visible in browser tests

Open on Drupal.org →
Created on 11 May 2023, over 1 year ago
Updated 31 January 2024, 11 months ago

Problem/Motivation

Tests which pass using the stark theme fail under the uswds_base theme.

Steps to reproduce

  1. Create a form with radio buttons
  2. Create a browser test
  3. Find a radio button by ID in the test
  4. Click the button in the test
  5. Run the test under phpunit
  6. Read the error message ("WebDriver\Exception\ElementNotVisible: element not interactable")

Here is sample test code.

class SomeTest extends WebDriverTestBase {
  protected $defaultTheme = 'uswds_base';
  public function testSomething() {
    $this->drupalGet($some_url);
    $form = $this->getSession()->getPage();
    $this->createScreenshot('/some/location/screenshot.png');
    $form->findById('radio-button-id')->click();
  }
}

Expected Behavior

The radio button is selected.

Actual Behavior

The test throws an exception, as described above.

Additional Information

The buttons work properly on the live site. The tests pass using the stark theme. Not sure it's relevant, but the radio buttons are inside a fieldset. Note that this is not a showstopper for us, as we have a workaround. Our workaround is to create a separate set for the tests which depend on the exact page rendering of custom uswds_base-derived theme, and all of our other tests use the stark theme, where radio buttons behave correctly for the tests. I'm reporting it here on the theory that the maintainers would want to know about the issue, and to save other developers the work of trying to figure out why their tests are failing in this situation.

Screenshots or other files

Here is the evidence that the radio buttons are actually visible, even though they report not being visible or interactable.

Here is a screenshot showing that the button gets correctly selected when using the stark theme.

🐛 Bug report
Status

Closed: won't fix

Version

3.3

Component

Code

Created by

🇺🇸United States bkline Virginia

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @bkline
  • Status changed to Postponed: needs info over 1 year ago
  • Comment over 1 year ago →
    🇺🇸United States smustgrave

    In the screenshot is the accordion opened by default?

  • Comment over 1 year ago →
    🇺🇸United States bkline Virginia

    In the repro code above (pared down to the minimum), yes. In our actual test, no. For that the accordion is closed on page load, so we have a line

      $form->findButton('Display Options')->click();

    When the next line creates and save the screenshot, the accordion is open.

  • Comment over 1 year ago →
    🇺🇸United States smustgrave

    Can you do some check for another uswds-base element? To verify the test is pulling the theme in.

  • Comment over 1 year ago →
    🇺🇸United States bkline Virginia

    Can you clarify exactly what you'd like me to try? I'm not sure I understand what "verify the test is pulling the theme in" would mean beyond what the first screenshot has already done by showing the footer which can only have come from uswds_base. To me that seems like pretty strong evidence that the theme has been "pulled in."

  • Status changed to Closed: works as designed 11 months ago
  • Comment 11 months ago →
    🇺🇸United States mferanda
  • Comment 11 months ago →
    🇺🇸United States bkline Virginia

    Did you not see my request for clarification of what you were asking for in my last comment? And can you explain why it is by design that radio buttons which work in the Stark theme would fail with this theme?

  • Comment 11 months ago →
    🇺🇸United States mferanda

    This started almost 9 months ago and has been idle for a long time. At this point, no one has else has come forward with anything.

    smustgrave asked the question and is not a maintainer on the theme. He was trying to volunteer a little time to understand as well.

    Unfortunately, I don't know and the theme is currently working as designed. If you find anything directly that can be modified in the theme, I'd be happy to take a look. (e.g. testing plans, etc) However, if the fix would require anything js or CSS related, it would have to be addressed in a sub theme. (a change would go to the demo sub theme for this theme)

    I don't really like to use "won't fix"... because I would if anything substantial was presented. I'll switch it over to that instead of works as designed, but will be happy to review and resolve if and when there is anything to resolve in the theme.

  • Status changed to Closed: won't fix 11 months ago
  • Comment 11 months ago →
    🇺🇸United States mferanda
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024