How to Test That an Element Does Not Have a `hidden` Attribute in Playwright?

Anushree Chatterjee

You may have come across certain UI elements on webpages that are otherwise not visible but suddenly appear when performing some action on the page. For example, a dropdown menu might be displayed when a user hovers over a parent element.

If you check the Document Object Model (DOM), you’ll see that these elements are ‘hidden’. This is achieved through different ways like ‘display: none’, ‘visibility: hidden’, using HTML’s hidden attribute, or even by setting opacity as 0.

If you are dealing with hidden elements in your Playwright test scripts, this article will help you get a better understanding of how to go ahead with it.

What are hidden elements?

It is possible to have UI elements on a page but not see them all the time. Hidden elements in web development are elements that are present in the Document Object Model (DOM) but are not visible on the page. This can be achieved in several ways:

• CSS display: none: This is a common method for hiding an element. When an element is set to display: none, it is completely removed from the document flow. It takes up no space and is not visible, but it still exists in the DOM.
• CSS visibility: hidden: Unlike display: none, when an element is set to visibility: hidden, it remains in the document flow. This means it still occupies space on the page but is not visible.
• HTML hidden Attribute: HTML5 introduced a global hidden attribute that can be applied to any element. When present, it suggests that the element is not yet, or no longer, relevant. Browsers typically render elements with the hidden attribute using display: none.
• Opacity: Setting an element’s opacity to 0 makes it fully transparent. However, unlike the other methods, an element with opacity: 0 can still interact with the user (like capturing clicks) and still takes up space in the layout.
• Positioning off-screen: Sometimes, elements are positioned outside the visible area of the browser window, making them not visible to the user.

Ways to work with hidden elements in Playwright

Playwright considers an element as visible if it does not have the attribute visibility:hidden. Also, elements of zero size or with display:none are not considered visible.

Here is a list of methods that Playwright’s Assertion Library provides that can be used to deal with hidden elements.

Locating elements regardless of visibility

• $(selector): This method returns the first element matching the selector, regardless of its visibility.
• $$(selector): Returns all elements that match the selector, including hidden ones.

Evaluating properties or states of elements

• isVisible(): Determines if the element is visible, that is, not hidden and within the viewport.
• isHidden(): Checks if the element is hidden. It’s the opposite of isVisible.
• getAttribute(name): Gets the value of an attribute, which can be used to check for attributes like hidden, style, etc.
• isHiddenAsync(): Returns whether the element is hidden. For example:

  Boolean hidden = await page.GetByRole(AriaRole.Button).IsHiddenAsync();

• isVisibleAsync(): Returns whether the element is visible. For example:

  Boolean visible = await page.GetByRole(AriaRole.Button).IsVisibleAsync();

• getAttributeAsync(): Returns matching element’s attribute. For example:

  await Locator.GetAttributeAsync(name, options);

Interacting with elements even if hidden

• click(options): You can click on elements that are not visible by setting the force option to true. However, this bypasses the actionability checks, so it doesn’t simulate a real user interaction.
• evaluate(): This method allows you to run a snippet of JavaScript in the element’s context, which can be used to change its properties or simulate interactions.

Waiting for elements to become visible or hidden

• waitForSelector(selector, { state: 'visible' }): Waits for an element to be present and visible.
• waitForSelector(selector, { state: 'hidden' }): Waits for an element to be either detached from the DOM or hidden.

Asserting the presence or absence of elements

• Playwright-expect library can be used with matchers like toHaveCount, toHaveText, etc., to assert the state of elements, regardless of their visibility.

Scrolling to elements

• scrollIntoViewIfNeeded(): Scrolls the element into view if it’s not already visible. This is useful for elements hidden due to their position outside the current viewport.

Modifying CSS or attributes

• Using evaluate(), you can modify the CSS or attributes of an element, making it visible or hidden as required for your test scenario.

test('element should not have hidden attribute', async ({ page }) => {

  await page.goto('https://xyz.com');

  const element = await page.$('selector-for-your-element');
  await expect(element).not.toHaveAttribute('hidden');
});

Smarter assertions with testRigor

These days, you can find smart testing tools that allow you to work with hidden elements easily. testRigor is one such tool using which you can automate complex test scenarios with simple English statements. Read more about assertion testing here.

This AI-based tool allows the tester to write test scripts in the English language. So, anyone on your team can easily automate tests by referring to the documentation. Just because these commands are in plain English does not mean they are ineffective. There are countless possibilities when it comes to creating tests with testRigor.

Read here testRigor vs. Selenium vs. Playwright.

open url "https://testrigor.com/"
check that property "font-weight" of "Request A Demo" is equal to "700"

That’s not all. You can automate web, mobile (hybrid, native), desktop, and even API tests using testRigor, that too across platforms and browsers.

Final Note

Working with hidden elements may seem daunting, but if you have a sound understanding of how the element is supposed to behave in your test case, then you can automate it. You need not even worry about the ‘how to validate’ part, as choosing competent test automation tools can solve this problem right away.

“We spent so much time on maintenance when using Selenium, and we spend nearly zero time with maintenance using testRigor.”

Keith Powe VP Of Engineering - IDT