A working solution (though, not ideal) is as follows. Ideally the waitForSelector with { visible:true } would behave this way... or the documentation clearly states that it doesn't do this.

/** Internal method to determine if an elementHandle is visible on the page. */
const _isVisible = async(page, elementHandle) => await page.evaluate((el) => {
  if (!el || el.offsetParent === null) {
    return false;
  }

  const style = window.getComputedStyle(el);
  return style && style.display !== 'none' && style.visibility !== 'hidden' && style.opacity !== '0';
}, elementHandle);

/**
 * Checks if an element with selector exists in DOM and is visible.
 * @param {*} page
 * @param {*} selector CSS Selector.
 * @param {*} timeout amount of time to wait for existence and visible.
 */
const waitForVisible = async(page, selector, timeout=25) => {
  const startTime = new Date();
  try {
    await page.waitForSelector(selector, { timeout: timeout });
    // Keep looking for the first visible element matching selector until timeout
    while (true) {
      const els = await page.$$(selector);
      for(const el of els) {
        if (await _isVisible(page, el)) {
          console.log(`PASS Check visible : ${selector}`);
          return el;
        }
      }
      if (new Date() - startTime > timeout) {
        throw new Error(`Timeout after ${timeout}ms`);
      }
      page.waitFor(50);
    }
  } catch (e) {
    console.log(`FAIL Check visible : ${selector}`);
    return false;
  }
};

Sounds reasonable. PRs welcome.

@JoelEinbinder PR is up, though you guys don't have any info or docs on testing/building for the experimental/firefox stuff. what's the protocol?

The page.waitForSelector with {visible: true} should have found and returned the visible element on the page.

@razorman8669 Ok I see what you mean here. Indeed, the behavior is somewhat confusing.

However, I disagree with the proposed approach. CSS selector is the only thing that we should use to identify the element. Adding the suggested logic adds magic to how we find elements - making it equally hard to debug.

The best solution here is to update the documentation - so that we do a better job explaining what's going on.

So , since razorman's fix did not go through. What is the alternative if I hit this case ? I do wish to skip the first selector ( inside display none) and assert on the second selector like the bug explains. Any alternatives or suggestions ?

Hey, @aslushnikov is this task up for grab? I would like to kickstart my contribution and looking for a good first issue. Also, I completely agree with you as technologies like selenium also moving towards finding element through CSS selector components only and giving consistent behaviour across technologies should be an ideal thing to do.

I'm having this same issue. For most instances of the element in question, parent elements are hidden, and I need the visible elements matching the selector. How are we supposed to find the 1 (or more) visible element among many hidden elements with the same selector?

Hi Guys, I would like to help and contribute to the repo. Is this bug still up for grabs ?. I am actually new to open source contribution, so is there any way I can kickstart my contributions. Would like your help here.

Similar situation that I think is being caused by the same bug. I would like to use a , in my selector on a page where only 1 of 2 elements will be visible.
Selector is #item1, #item2. If #item1 becomes visible, this works as expected, if #item2 does, I get a timeout.

Any updates on this? What should be the recommended approach in this case?