Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] Is there a way to identify if an element is intractable? #874

Closed
VikramTiwari opened this issue Feb 6, 2020 · 6 comments
Closed

Comments

@VikramTiwari
Copy link

VikramTiwari commented Feb 6, 2020

I can use IntersectionObserver (elementHandle.scrollIntoViewIfNeeded()) to understand if the element is in viewport but it doesn't help if the element is behind an overlay/dialog. Is there some function that I can use to confirm if the element that I am going to perform an action upon is actually present in the view.

Something like:
page.isInView(selector/xpath) and return the element.boundingBox.

@pavelfeldman
Copy link
Member

By 'in view', do you mean visible to the user, receiving input events if clicked or something else? Element can behind a (semi-transparent) overlay that has pointer-events: none, or the opposite, it can be on top, but not receive input events, etc. etc. Knowing what exact scenario you are facing would help us understand the problem.

@VikramTiwari
Copy link
Author

Ah! I understand the confusion. It would be great to have a function which could tell the state of the element. Right now we have waitForSelector but it triggers even when the element is not in view. It would be very useful to

  • have a function which tells the state of an element, or
  • a set of functions which wait for an element to get into a state

These states could be:

  • in the DOM tree: already present
  • in the viewport: already present
  • visible to the user: element is not behind a sticky header, or not hidden behind a dialog box etc
  • user can interact: element is not disabled, or hidden behind a translucent overlay etc

I think they will be very helpful because they would give the exact state of an element and thus allow better understanding. Even better if I could attach a listener on the page for a specific selector and it would trigger these different events as an element cycles through them.

As for a specific use cases:

  • I was trying to click on element-2 which appeared in view after clicking on element-1 + an uncertain amount of animation time.
  • I was trying to click on a text which was hidden behind a sticky header

@VikramTiwari
Copy link
Author

Seems like there were some discussion around this here:

@VikramTiwari
Copy link
Author

@pavelfeldman One of the other use cases here is, trying to interact with the element in page when event handlers are not registered to it yet.

On this page: https://developers.google.com/web/tools/lighthouse/audits/time-to-interactive it's mentioned that Event handlers are registered. I am not sure if there's a way to listen to this for a specific element.

I would love to have a new event intractable which we can add listeners for on each element.

@VikramTiwari VikramTiwari changed the title [Question] Is there a way to identify if an element is in view? [Question] Is there a way to identify if an element is intractable? Feb 16, 2020
@pavelfeldman
Copy link
Member

There is no efficient way to instrument event listener addition so we won't be able to do that. Present version of page.click will wait for the element to be free from a sticky headers.

@VikramTiwari
Copy link
Author

Click free from sticky headers is fantastic. Thanks! :)

Regarding event listener addition, what are the inefficient ways? haha I was unable to find anything at all in this case. For example: getEventListeners(domElement) was of no use.

sand4rt pushed a commit to sand4rt/playwright that referenced this issue Dec 21, 2022
Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants