fix in_view function

[bluwy]

@PH4NTOMiki's #3873 (comment) reminded me of #3741 (comment). The in_view function now isn't correct and reports true if the element is anywhere on the page, not stricly in the viewport as expected.

With this PR, in_view only returns true if the element is actually in the viewport.

Notes

According to playwright's docs:

This method returns the bounding box of the element, or null if the element is not visible

Playwright's term for "is not visible" is confusing:

Element is considered visible when it has non-empty bounding box and does not have visibility:hidden computed style. Note that elements of zero size or with display:none are not considered visible.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

[changeset-bot]

⚠️ No Changeset found

Latest commit: 2f75426

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[netlify]

✔️ Deploy Preview for kit-demo canceled.

🔨 Explore the source changes: 2f75426

🔍 Inspect the deploy log: https://app.netlify.com/sites/kit-demo/deploys/6208b699a1a38e00087b2e6a

[PH4NTOMiki]

@bluwy @benmccann the tests using in_view are being flaky again.

[bluwy]

Yeah, I don't think the tests were de-flaked in the first place.

[PH4NTOMiki]

I'm trying this now https://stackoverflow.com/a/68848306

[PH4NTOMiki]

@bluwy what do you think of that, it seems to pass consistently.

[PH4NTOMiki]

@bluwy what do you think of that, it seems to pass consistently.

Everywhere except Windows

[PH4NTOMiki]

https://github.com/puppeteer/puppeteer/blob/08e9978ce662cf1c2c2708f7e6098cbea328cbe2/src/common/JSHandle.ts#L1133-L1151 uses it, but in the Playwright the Windows is still inconsistent.

[PH4NTOMiki]

@bluwy @benmccann This works consistently even on Windows, it's the old deprecated way, but it works:

in_view: async ({ page }, use) => {
		/** @param {string} selector */
		async function in_view(selector) {
			return await page.$eval(selector, async (/** @type {Element} */ element) => {
				// @ts-ignore
				let top = element.offsetTop;
				// @ts-ignore
				let left = element.offsetLeft;
				// @ts-ignore
				const width = element.offsetWidth;
				// @ts-ignore
				const height = element.offsetHeight;

				// @ts-ignore
				while (element.offsetParent) {
					// @ts-ignore
					element = element.offsetParent;
					// @ts-ignore
					top += element.offsetTop;
					// @ts-ignore
					left += element.offsetLeft;
				}

				return top < window.pageYOffset + window.innerHeight &&
					left < window.pageXOffset + window.innerWidth &&
					top + height > window.pageYOffset &&
					left + width > window.pageXOffset
					? true
					: { top, left, width, height };
			});
		}

		use(in_view);
	}

Maybe you or I can do a PR for it and merge it.

[bluwy]

Thanks for digging into this @PH4NTOMiki. My first encounter with the scrolling shenanigans was also through that stackoverflow post, and the function had evolved over time. I'm not sure if using ResizeObservers would help though if it would still sometimes fail in windows.

Re the old deprecated way, do you know why that works more reliably? I'm not 100% sure if the function is safe too.

Also maybe related, perhaps we can setup the CI to emit the screenshots for failed tests. That might show us if the element is actually inside the view, or it's an error with in_view incorrectly detecting stuff.

[benmccann]

It's already outputting screenshots and failure traces on the CI:

kit/packages/kit/test/utils.js

Line 194 in 0c6bc25

screenshot: 'only-on-failure',

I'm not sure how to retrieve them though. I guess we'd have to setup something to upload them somewhere?

[benmccann]

There were a couple tests I couldn't get to fail on my machine. A user in Discord provided me with these traces awhile back to help us debug. Unfortunately, I haven't gotten to investigate yet. But maybe someone else will be able to 😁

playwright-test-results.zip

[bluwy]

I'm not sure how to retrieve them though. I guess we'd have to setup something to upload them somewhere?

I've done something like this before using upload-artifact. Will send a PR.

[PH4NTOMiki]

Re the old deprecated way, do you know why that works more reliably? I'm not 100% sure if the function is safe too.

Well it's more reliable than current ones, but still not 100% reliable, but it's the best we currently have.

[PH4NTOMiki]

@bluwy I think it works better because it doesn't use boundingClientRect(boundingBox in playwright is similar). It uses element static properties.