Alex Krolick

I wonder if it has something to do with the MutationObserver optimizations in waitFor hogging too much of the thread for the more expensive getByRole DOM traversal

```js const row = getByRole('cell', {name: 'Jane'}).closest('tr') fireEvent.click( within(row).getByText('Delete') ) ``` Of course, this doesn't work if you aren't using literal table elements, virtualized tables, etc.

Previously: * #266 #769 #420 #327 #294 * https://testing-library.com/docs/ecosystem-testing-library-selector * https://testing-library.com/docs/ecosystem-rtl-simple-queries * https://testing-library.com/docs/ecosystem-query-extensions

In general JSDOM out of the box doesn't support screen sizes very well (I think the default size for all elements is 0x0) nor does it parse CSS stylesheets that...

The big issue for me is that Cypress can use computed styles, which includes CSS, but JSDOM can only use element styles and properties. So even if a lot of...

Hmm, now that I think about it, I don't think that the queries themselves should have this check. For example, in a long form, a user would scroll the page...

Cypress does this before firing events on elements: https://docs.cypress.io/guides/core-concepts/interacting-with-elements.html#Actionability > Checks and Actions Performed > > 1. Scroll the element into view. > 1. Ensure the element is not hidden....

> I think I'd be more comfortable trying something like this out in another package and seeing how that goes before bringing it into the core. Anyone up for that?...

I still think it would be possible to dig into what Cypress (and other full browser test platforms) do and extract that into a function. Then you could wrap all...

To focus this back on the latest request: > I'm running into the same issue in testcafe. The testcafe docs say: > Before executing an action, TestCafe waits for the...