#dev 2025-10-05

2025-10-05 UTC
duanin2, troojg, gRegor, bret, parnikkapore_x, Giggs, failxontour, [jeremycherfas], oodani, [Sophia_wood], DanQ, grufwub, Wesselaar, abhinav, barnaby, tulips, GuestZero, bret_ and proofreed joined the channel
#
[artlung] .pi.r2 is that consistent across browsers?
DanQ1 and troojg joined the channel
#
.pi.r2. artlung: seems to happen with Chrome and Firefox
barnaby and barnabywalters joined the channel
#
[artlung] I see the behavior in Firefox. With a very tall browser window I didn't see the behavior. But it appears some of the JS enabled content being loaded manages to pull focus to itself and scroll the parent page such that it's at the top or visible. I don't know that I'd call it scroll being affected, I suspect it's focus that gets affected, and scroll is part of that. Like scroll to an anchor, sortof.
barnabywalters joined the channel
#
[artlung] could be a scroll() call, or an document.location.href update that moves the page. or a page refresh maybe. those are all guesses. 🙂 if you sort it out I'd love to hear how it works. also you might try adding a loading=lazy to the iframes which could mitigate it.
#
[artlung] https://developer.mozilla.org/en-US/docs/Web/Performance/Guides/Lazy_loading
DanQ joined the channel
#
.pi.r2. they already have loading=lazy
#
.pi.r2. seems fixed. offrecord.ca redirected to offrecord.ca/#lobby
#
.pi.r2. so I deeplink now, and no jumping
#
[artlung] So my guess of a #hash update was it? Or something different?
#
.pi.r2. yup it was it, inside an iframe
#
.pi.r2. kinda shocked that it's allowed to scroll the main frame, but mkay
#
.pi.r2. pinpointed the right iframe by making a tiny window to observe where it jumped exactly
barnaby, opencircuit, troojg, gRegor, DanQ and [Al_Abut] joined the channel