Optimizing displayCheck: 'full'

It is possible to assess whether an element, or one of its ancestors, have display: none without having to traverse the DOM.

This condition can be simplified to:

if (!displayCheck || displayCheck === 'full') {
  return !node.getClientRects().length;
}

I actually don’t know if checking for getClientRects().length is really equivalent to that expensive while loop.

According to the specs, the getClientRects() method returns an empty list

If the element on which it was invoked does not have an associated layout box

What exactly are all the cases in which an element does not have an associated layout box? I am not sure.

But the e2e tests currently present in the project are all passing.
However I didn’t go through the tests myself and I don’t know what they do, I only checked this very small set of possible edge cases and it looks like the method should be good enough.

May I open a PR?

By the way, since the getBoundingClientRect() method internally uses getClientRects(), the "full" option would become faster than the "non-zero-area" one. But I guess that the latter would still be useful for accessibility purpose.

[DaviDevMod]

One tip: Cypress does not natively support tabbing. Shocking, I know, but it is what it is. We have to use a plugin to support .tab() and this plugin does not support all scenarios.

Thanks for the opportunity and the tip, I’ll see what I can do 😆

[stefcameron]

That’s all right. I understand that removing displayCheck would be a big change needing a lot care. Though I hope you’ll reconsider this possibility.

I’m up for the change, but I don’t want a breaking change. As long as we can be surgical about it, then we’re good to go. Even though the other modes will still exist, we’re talking about optimizing the default path, which is what probably (guessing) 98% of consumers are using. So many people may see a performance gain. It’ll have a big enough impact as it is.

Regarding the tests, I have no experience whatsoever with cypress (and e2e testing in general), so I could leave them up to someone else. On the other hand, this would be a nice opportunity to get started with e2e testing, so I can write the tests if you don’t mind having to wait for me learning a bit about cypress. But if you do mind, I totally understand and respect that.

Go for it! Use it as a learning opportunity. No rush at all. This is an optimization, not a time-sensitive critical bug fix or something like that. 😄

One tip: Cypress does not natively support tabbing. Shocking, I know, but it is what it is. We have to use a plugin to support .tab() and this plugin does not support all scenarios. You may run into a scenario where you’re bashing your head against a wall thinking you’re going nuts because Cypress keeps failing with an error (which is actually from the plugin) complaining that some node you’ve landed on isn’t a tabbable target (or something like that). That’s a failure of the plugin, not you, and you’ll have to be creative, or we’ll have to pass on testing that specific aspect. focus-trap has a few instances of this that I recall, with comments about it, so maybe looking at focus-trap Cypress tests might help in your work here.