Cursory hack – Fake address bar interaction(jameshfisher.github.io) |
Cursory hack – Fake address bar interaction(jameshfisher.github.io) |
Can anyone explain what's going on here.
In terms of mitigation, it seems like at a minimum custom cursors should never be rendered outside the bounds of the page content.
The tracking wasn't great, but maybe that was intentional to illustrate a point.
Part of the problem here is the fact that the fake cursor never actually escapes the page on this one. When my mouse is near the top of the page it reverts back to the system cursor instead of the fake one, before it even leaves the frame of the page. The original linked hack worked much better.
All of them are nofix.
Sorry, I'm on mobile. But several similar reports as the HN link shows.
https://github.com/jameshfisher/cursory-hack/blob/gh-pages/i...
It's using a canvas to draw the address bar and adjusting the position every time the mouse moves, but I don't understand the details of it
Edit: looks like it only works on the same origin.
Alt + Left
to go back :P
⌘ + Left (go back)
⌘ + W (closes the window)
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/
In this case the browser could create a clipped version of the cursor image and set it as the new cursor.
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.