webapi: reject elementFromPoint outside viewport

[FAIpang]

Summary

• return early when elementFromPoint() receives coordinates outside the viewport
• preserve internal document-coordinate hit testing used by elementFromVerticalPoint()
• cover negative, viewport-overflow, exact-boundary, and Taobao reproduction coordinates

Motivation

CSSOM View requires negative coordinates or coordinates greater than the viewport dimensions to return null. For very large y values, the existing traversal shortcut does not fire, so the browser unnecessarily walks the DOM and performs visibility checks.

Testing

• git diff --check
• embedded test-script syntax validation
• CI: TEST_FILTER="WebApi: Document#element_from_point.html" make test

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[FAIpang]

Thank you for your submission, we really appreciate it. Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request Comment same as the below format.

I have read the CLA Document and I hereby sign the CLA

You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.

recheck

[FAIpang]

I have read the CLA Document and I hereby sign the CLA

[karlseguin]

Can you provide an exact link that causes the performance issue?

I think this change is likely to break sites. Since we don't change the viewport, any script that expects an element to become visible from a scroll or some other viewport change will hang. Also, while it might not be correct, all of our coordinates are document-based, not viewport based, e.g. getBoundingClientRect() doesn't consider the scroll position. So at least we're consistent.

[FAIpang]

Can you provide an exact link that causes the performance issue?

I think this change is likely to break sites. Since we don't change the viewport, any script that expects an element to become visible from a scroll or some other viewport change will hang. Also, while it might not be correct, all of our coordinates are document-based, not viewport based, e.g. getBoundingClientRect() doesn't consider the scroll position. So at least we're consistent.

[krichprollsch]

@FAIpang any update about the use case?

EDIT: I didn't see #3251, my bad

[karlseguin]

Hi @FAIpang closing this as I believe #3353 fixes the issue.