[gabemart]

After a first look, it seems like this hack involves setting a custom cursor, which is defined as a canvas image that is 128 px tall. This 128px high image is mostly transparent, and has a fake "cursor" image at the top of it. The bottom of this image tracks your real cursor, and the fake cursor at the top of the image makes it seem like your real cursor is hovering over the browser chrome, when in fact it is ~128px lower than it appears. The rest of the effect is achieved via animating the canvas used for the custom cursor.

In terms of mitigation, it seems like at a minimum custom cursors should never be rendered outside the bounds of the page content.

[jamesfisher]

Hello! Author here (along with my inspiration benjaminbenben). This explanation is perfect. And yes, I think the TODO is to not render the custom cursor outside the viewport.

[Mithaldu]

Are you sure that is possible?

At least on Windows, i'm reasonably sure all the API does is tell the OS which image to render as cursor and the cursor is rendered entirely by the OS; meaning there's no control over whether the cursor is being rendered partially outside the viewport or not.

Solutions where the browser would have enough control would likely require rendering the cursor by itself, which would impart it noticable input latency.

Edit: Quick addition of a bounding box to the demo: https://wchristian.github.io/cursory-hack/

[jabiko]

The browser could check whether the cursor image would be painted outside the page viewport.

In this case the browser could create a clipped version of the cursor image and set it as the new cursor.

[Mithaldu]

That would be very expensive computationally, and as seen in the padlock, accompanied by latency and jitter.

It would also break the case where pages have legit uses for crosshair style cursors, or cursors that are rotated 180° in order to not overlay contents.

[pingec]

Thanks for the explanation. Most informative comment.