Tell me about it. If you've ever used iScroll (amazing library btw https://github.com/cubiq/iscroll) to get iPad scrolling support you'll see how deep the rabbit hole goes. I initially used it for 2013.artsy.net (source code: https://github.com/artsy/artsy-2013) and had to eventually decide to toggle it on only for iPad b/c there were too many edge cases in the browser.
But I digress. Thanks for pointing this out, hopefully we'll eventually smooth over the quirks to a reasonable degree. Logged the bug for now: https://github.com/artsy/scroll-frame/issues/12
Additional quirk: Middle-button click to open in a new tab is also broken. Right-click -> open-in-new-tab works though.
This kind of stuff, in addition to being a pain in the ass for you, the developer, is why users hate this kind of trickery. I see that I'm on an infinite-scrolling page and I say to myself "ugh, I wonder which standard browser behavior is broken due to the weird hacks they had to employ to make this crap work." Which, ironically, is one reason I habitually open things in a new tab on pages like this -- I don't want whatever hacks are being employed to cause me to lose my page state.
I think if they used `window.history.back()` instead of whatever they do now when closing the frame, and listened to the popstate event to reopen it, it would work.
That being said, yes, this is why reimplementing browser builtins hard, you have to get all the details right. That being said, hard != don't do it.
But I digress. Thanks for pointing this out, hopefully we'll eventually smooth over the quirks to a reasonable degree. Logged the bug for now: https://github.com/artsy/scroll-frame/issues/12