281786 2024-10-18 15:32:14 -0700 Auto-scrolling on popular Guitar Tab site doesn't work when page is zoomed 2025-01-29 20:58:51 -0800 1 1 1 Unclassified WebKit New Bugs Safari Technology Preview Unspecified Unspecified NEW BrowserCompat, InRadar P2 Normal --- 1 jalkut webkit-unassigned karlcow simon.fraser webkit-bug-importer oldest_to_newest 2069269 0 jalkut 2024-10-18 15:32:14 -0700 The Ultimate Guitar tab site features an autoscroll button which is intended to scroll the content of the page automatically so you can play along. The scroll works fine in Safari UNLESS you've zoomed the page to any non-100% zoom level. To reproduce: 1. Navigate to any Ultimate Guitar song page, for example: https://tabs.ultimate-guitar.com/tab/the-beths/expert-in-a-dying-field-chords-4271140 2. Ensure the page is zoomed to actual size by pressing Cmd-0 3. Click the "Autoscroll" button at the bottom of the page 4. While the page content is scrolling, press Cmd-+ to increase the zoom factor for the page. Expected: the scrolling should continue Actual: the scrolling stops Notice that if you switch back to 100% (Cmd-0) the scrolling immediately begins again. Then zooming to a non-100% factor immediately stops it. I don't know if this is ultimately (hah!) a bug in their autoscrolling code, or something wrong in WebKit. I confirmed though that the same feature works at all zoom sizes in Chrome. 2069277 1 gsnedders 2024-10-18 15:49:34 -0700 Daniel also pointed at https://www.ultimate-guitar.com/forum/showthread.php?t=2215942 in Slack, where it suggests the developer is aware of this. 2069279 2 webkit-bug-importer 2024-10-18 15:49:44 -0700 <rdar://problem/138214931> 2072702 3 karlcow 2024-11-04 18:01:41 -0800 The autoscroll is managed by ``` const G = () => { const [t, e] = (0, y.useState)(document.body.getBoundingClientRect()), [o, i] = (0, y.useState)(0), [n, s] = (0, y.useState)(t.top), [a, r] = (0, y.useState)(t.left), [l, c] = (0, y.useState)(null), d = () => { e(document.body.getBoundingClientRect()), c(o > -t.top ? "down" : "up") }; return (0, y.useEffect)((() => { s(t.top ? -t.top : 0), r(t.left), i(t.top ? -t.top : 0) }), [t]), (0, y.useEffect)((() => (window.addEventListener("scroll", d), () => { window.removeEventListener("scroll", d) }))), { scrollY: n, scrollX: a, scrollDirection: l } }, ``` in https://tabs.ultimate-guitar.com/static/public/build/ug_react_es6/202411/7496.96e2ce90724815b836fc437c3c770313.js To note that the zoom also stops the scrolling on Firefox. So only chrome keeps scrolling. Also when coming back to "zoom: 100%", then the scroll restarts. 2072703 4 karlcow 2024-11-04 18:02:20 -0800 I wonder how document.body.getBoundingClientRect() changes when zooming on different browsers. 2072704 5 karlcow 2024-11-04 18:08:43 -0800 document.body.getBoundingClientRect() changes in similar ways in different browsers. 2072708 6 karlcow 2024-11-04 18:12:29 -0800 Another data point, If I zoom BEFORE activating the autoscroll, and activate it, then the autoscroll is not working. In that same sequence, if I set back to 100%, the autoscroll starts. 2090618 7 simon.fraser 2025-01-29 19:18:56 -0800 The autoscroll code is actually this: ``` v = (0, n.useCallback)((t => { const {current: e} = r; if (!d.current || !a.current || !e) return; const i = 0 < window.innerHeight - l - a.current.getBoundingClientRect().bottom, n = e instanceof Window ? e.scrollX : e.scrollLeft; if (i) { if (!t) return void f(); e.scrollTo(n, 0) } if (!i) { const t = e instanceof Window ? e.scrollY : e.scrollTop; e.scrollTo(n, t + u.current) } const o = 1e3 / p.current * (g.nR / (40 - (40 / 15 - 1))); c.current = window.setTimeout(v, o) }), [e, l]); ``` Maybe this is related to bug 174362. 2090619 8 simon.fraser 2025-01-29 19:21:46 -0800 Bug 174362 is about pinch zoom, not Command-+ zoom 2090633 9 jalkut 2025-01-29 20:55:12 -0800 Thanks for isolating the autoscroll code. I wonder if there's something about the different zoom levels that causes the math to be off such that the `e.scrollTo` line continuously scrolls to the same offset. I don't know enough about how the zoomed window might change the semantic meaning of a "scrollY" value, for example. But I can observe that while the bug is happening it constantly tries to scroll by "1" (u.current), but by the time the callback is reached again e.scrollY is still at the same location. So maybe scrolling by 1 isn't enough? In fact, as a quick check, I broke at the line where the scrollTo occurs, and changed the value of `u.current` to 2 instead of 1. Making this changes causes the scroll animation to resume. In fact, I can confirm that at the breakpoint, if e.scrollY for example is 1302, manually invoking `e.scrollTo(0, 1303)` has no impact on e.scrollY. But something like `e.scrollTo(0, 1305` does. 2090634 10 jalkut 2025-01-29 20:58:51 -0800 Perhaps the distinction between browsers here is if Chrome's implementation of `scrollTo` rounds "out" (rounding up for positive and down for negative changes), but Safari rounds "in." I think the bug somehow has to do with the developer's assumption that consistently asking for the scroll to be "1" greater will always result in a change, but that on Safari it is not guaranteed.