Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cursory hack – Fake address bar interaction

jameshfisher.github.io

Post reply on HN
Print view View original

31–40 of 42 posts

Re: Cursory hack – Fake address bar interaction

#31

Post by jamesfisher »

gabemart wrote: post #5
andybak wrote: post #2

Unless I'm completely getting myself confused then it's doing something I didn't think was possible and drawing over the browser chrome. Can anyone explain what's going on here.

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…

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.

Re: Cursory hack – Fake address bar interaction

#36

Post by Mithaldu »

jamesfisher wrote: post #31
gabemart wrote: post #5

Earlier quoted context omitted.

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…

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.

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/

Re: Cursory hack – Fake address bar interaction

#37

Post by jabiko »

Mithaldu wrote: post #36
jamesfisher wrote: post #31

Earlier quoted context omitted.

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.

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…

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.

Re: Cursory hack – Fake address bar interaction

#39

Post by Mithaldu »

jabiko wrote: post #37
Mithaldu wrote: post #36

Earlier quoted context omitted.

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…

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.

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.

Re: Cursory hack – Fake address bar interaction

#40

Post by eridius »

The original linked hack is clever. But this page is just confusing (in Safari on OS X), for several reasons, not the least of which is the fact that the page is in fact served over https, and if I mouse over the padlock and click it, everything behaves correctly (and even if the page was specially designed for Safari and could figure out where the url bar was, it can't even replicate the behavior Safari has for clicking the padlock because web pages can't show sheet dialogs).

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.

Post reply on HN