That’s because the site messes with the scrolling in an attempt to prevent the top chrome to not come back, which unfortunately (or fortunately?) doesn’t do anything because Safari refuses to hide it.
Yeah, the scrolling is so janky on the page, I thought my iPad wasn’t properly responding to multitouch input for a moment... Then I opened the HN discussion and smooth, buttery scrolling (tm) was back. Lesson: don’t hijack scrolling behavior, it’s awful. (Very smart hack though.)
> With a little more effort, the page could detect which browser it’s in, and forge an inception bar for that browser.
It’s just a proof of concept, focusing on one browser in one operating system. It would be interesting to see how well this could be done on iOS. The real host name is always shown at the top of the page, so it’s not going to be perfect.
Interesting! So it does. However Firefox does hide the URL bar on other pages! I'll try to figure out what the logic is in Firefox, and whether there's an equivalent trick to hide the URL bar ...
Just to be clear, you're referring to real Firefox address bar (pointing to TFA), not the fake Chrome address bar (pointing to hsbc.com). So yes, in this case Firefox has (accidentally?) somewhat thwarted this attack vector.
I noticed this as well. I'm wondering if FF is smart enough to always show it's own title bar if a CSS element is pinned to the top of the viewport? Gotta do more testing ...
Safari doesn’t hide the url bar when you employ the “scroll jail” technique he described. It also doesn’t feel right scrolling because he omitted the css property for inertial scrolling in his “scroll jail.”