|Summary:||iOS 10.3 Safari bug with overflow and focus|
|Component:||Layout and Rendering||Assignee:||Nobody <webkit-unassigned>|
|Severity:||Normal||CC:||bfulgham, simon.fraser, zalan|
|Hardware:||iPhone / iPad|
Description scottjehl+webkit 2017-06-27 19:50:51 PDT
In the recent iOS 10.3 update, some safari changes seemingly happened with overflow scroll elements so that they scroll to 0,0 when they are tapped or gain focus. The link below demonstrates the behavior. To reproduce, just load this link, and after 5 seconds the div will gain focus and jump to 0, despite having a pre-set scroll left value. If you scroll the area manually before then, it’ll stay put to whatever you choose, suggesting iOS treats user-intiated scroll differently than programatic scroll. This jump to zero does not happen in iOS 9.3. Notably, if you drag-scroll the scroller manually, a subsequent user tap will not reset the scroll. So it seems focus related, but I can't seem to prevent the jump by binding to focus and preventing default…. Source here: http://jsbin.com/nawumetofo/edit?html,css,js,output Side notes: - I’m able to reproduce the issue by programmatically scrolling the element, then focusing it after a timeout, so user interaction is not necessarily required. - If I remove the tab index on the div, it sometimes fixes the behavior, but doesn’t seem to fix it reliably, and we need a tab index to support keyboard interaction of our scroller anyway. - If I bind to focus, I can get log expected scrollLeft value of the element before it jumps to 0. But again, preventDefault or stopImmediatePropagation does not prevent the jump. - preventDefault on touchStart or using CSS pointer-events:none will disable the jump, but also disables the scroller so it’s not a fix. - For the bug to show, it seems to require that CSS snap points are applied. The bug will not occur on just overflow: auto or webkit-overflow-scrolling.
Comment 1 Simon Fraser (smfr) 2017-06-27 19:54:25 PDT
This is fixed in iOS 11.