Window scrolls to show full gallery on initial click

[jasonwbullok]

I've only been able to recreate this behavior in WebKit browsers:

After a flickity instance has been initialized, scroll the page so it's only half visible. Click on a cell and the window will jump to make the whole flickity instance visible.

http://codepen.io/jasonwbullok/pen/PwBrzG

(I'm also seeing this behavior on the flickity homepage instances)

[desandro]

Thanks for reporting this! This behavior is actually a feature of keyboard accessibility. By clicking/tapping on a gallery, it adds focus to its element. This will jump the scroll so that element is completely in the viewport.

If this behavior is really bugging you, you can disable it with accessibility: false -- which I don't recommend because accessibility is a wonderful thing.

[jasonwbullok]

Good to know! Thanks for the help.

[esseb]

Can't you read the scroll position before setting focus and then set the scroll afterwards to prevent the jump? Slightly dirty, but better than users disabling accessibility as a workaround.

[desandro]

@esseb Interesting idea, but I suspect messing with native browser behavior in this matter would lead to more problems that it resolves.

[desandro]

After looking deeper into this, I've added a hack to reset the scroll position after the element has been focused. The next version of Flickity (after v1.1.1) will have this fix.

[felthy]

I came across a problem with this fix today - in my case I'm using Flickity inside a Stackla widget, i.e. inside an iframe. The iframe is always resized to fit its content, so is never scrollable. For some reason, on an iPhone (tested in iOS 10.3.2 and 10.3.3, Safari 10.0), the call to element.focus() causes the page to jump towards the bottom and the element ends up way outside the viewport (it's the parent page that is scrolled). Because of the iframe, pageYOffset is 0 before and after, so scrollTo() isn't called (and wouldn't do anything even if it was).

Because the scrollTo() hack can't possibly work in this case, I'll use accessibility:false to avoid the call to element.focus(). I just thought I'd mention here because it's a slightly different permutation of the problem. To fix it properly I'd need to use postMessage between the iframe and the host page to coordinate resetting the scroll position, and I don't really think that could be neatly encapsulated in an option - I'd be better off monkey-patching pointerDownFocus().

[homerjam]

Perhaps an option to disable the focus/scroll in initialisation would help? I'm having to use accessibility: false which is unfortunate and seems kind of brute force.

[desandro]

@homerjam The scroll-jump behavior should no longer occur. What device/browser are you seeing it in?

[homerjam]

I'm seeing it in iOS simulator (12.x) and Safari (12.0.2). Specifically I'm developing a Nuxt site (SSR/SPA framework for Vue). The unwanted scroll/focus issue occurs when transitioning to a page - not sure if this is an instance that may not have been accounted for? Thanks

[desandro]

Thanks for reporting that. Sounds like an intricate use case. If you can boil it down to a live demo I'd be happy to take a look.

[nboliver]

I'm experiencing the scroll-jump when clicking the prev / next buttons with Flickity v2.2, in Safari 12.0.3 on MacOS Mojave 10.14.3
Setting accessibility: false fixes it, but would prefer not to do that because as mentioned, accessibility is a wonderful thing.