This affects our web app and causes a broken experience for our users on Safari. As such, we have to recommend our users avoid Safari until this can be fixed. What's especially alarming about this bug is that it seems to be producing a "spooky action at a distance" sort of unsoundness in the page rendering. The existence of `container-type: size` set on one part of the page, and a scrollbar existing (from `overflow: auto` with enough content to cause an overflow) on an entirely unrelated part of the page (neither are children/ancestors of one another), causes the misalignment between the painted target and the actual click targets. I have collected some experimentation notes for this bug on our GitHub issue: https://github.com/GraphiteEditor/Graphite/issues/1687 While I can't provide another minimal reproduction based on our use case, it only takes a few seconds to open our web app and trigger the bug to observe for yourself: 1. Open https://editor.graphite.rs 2. Make a new document 3. Reduce the height of the web page such that the drawing tools on the left become two columns (this happens via `container-type: size` and some `calc()` magic) 4. Draw a rectangle and make sure it's selected, in order to populate the top-right Properties panel such that it has enough content to overflow and cause a vertical scrollbar 5. Click either of the black or white color circles beneath the drawing tools at the bottom left of the UI 6. This should be drawn at the bottom left corner of the web app, but it gets painted ~130px higher than it's supposed to be— but hover over the correct locations of buttons and you'll see it interact with the incorrectly offset painted buttons 7. Resize the Properties panel downwards so it has enough space to avoid needing scrollbars for its content (but don't resize the page to cause the drawing tools to become single-column)— and notice that the offset bug goes away, even though the Properties panel has no child/ancestor relationship with the tools and color picker Hopefully this provides some useful additional data. As a rendering unsoundness issue, I hope this can be prioritized highly. See the issue linked above in our app's bug tracker for more details.

This original (failing) test case works fine on trunk WebKit now.

(In reply to zalan from comment #2) > This original (failing) test case works fine on trunk WebKit now. That's the minimal reproduction example included by the OP in this issue? Would you also be able to test if the reproduction steps in my previous comment are similarly fixed—or still broken—in the trunk version? I have no way to test it myself. I've also gone ahead and captured a reproduction video (2 minutes) for reference: https://files.keavon.com/-/LightgoldenrodyellowHelpfulPiranha/capture_21_.mp4 Thank you!

Created attachment 472018 [details] Screen recording on WebKit trunk This looks to be fixed on trunk (thank you for your screen-recording, it helped a lot)

(In reply to zalan from comment #4) > Created attachment 472018 [details] > Screen recording on WebKit trunk > > This looks to be fixed on trunk (thank you for your screen-recording, it > helped a lot) That's great news! "Already fixed" is the best outcome. Thank you for testing this. I suppose we don't know when it got fixed, and therefore how close it is to making it into a TP or full release, but would you have a gut feeling (based on your familiarity with the release pipeline) about what timeframe we'd probably be looking at until it begins reaching ordinary users and what version (or range) that might have a likelihood of being included in?

(In reply to Keavon from comment #5) > (In reply to zalan from comment #4) > > Created attachment 472018 [details] > > Screen recording on WebKit trunk > > > > This looks to be fixed on trunk (thank you for your screen-recording, it > > helped a lot) > > That's great news! "Already fixed" is the best outcome. Thank you for > testing this. > > I suppose we don't know when it got fixed, and therefore how close it is to > making it into a TP or full release, but would you have a gut feeling (based > on your familiarity with the release pipeline) about what timeframe we'd > probably be looking at until it begins reaching ordinary users and what > version (or range) that might have a likelihood of being included in? I can figure out when it got fixed but unfortunately I can't tell whether the fix is part of any upcoming release (even as a guess). https://beta.apple.com may give you a hint though that's a bit of a process.

(In reply to zalan from comment #6) > I can figure out when it got fixed but unfortunately I can't tell whether > the fix is part of any upcoming release (even as a guess). > https://beta.apple.com may give you a hint though that's a bit of a process. That would be really helpful info to have if you'd be so kind as to check when (or which commit) it got fixed. Thank you. I am unfamiliar with the Safari release process, but I'm trying to build a clear understanding of why you'd be unable to check or guess when it may be included. I'd normally assume code that's merged into trunk would likely make its way into the next release or two, but I realize the release process for giant software is slower, less simple, and would probably deviate from my assumptions. Is the situation something like this?: WebKit development churns along on a continuous basis, merging code into trunk all the time, but then it's up to the Safari team to make decisions about which point to freeze trunk for a given release (and which more-recent features and fixes to backport into that frozen base) so the testing and betas all revolve around that release version branch? But then the decisions about when to freeze trunk, and which fixes to backport into a release branch, are not things you're privy to? (So this fix might be old enough that it could be part of the base for some future release that's in the works, or it may have been important enough to backport to an in-the-works release, or maybe it's neither.) If that description is accurate, I'd conclude that means there would be at least *some* point in the future when they'd be guaranteed to pick a date to begin a new release branch that includes today's trunk, even if that's still far away from reaching users? Thanks for clarifying my understanding here, even if I'm off-base.

It's just Apple's policy; we cannot comment on future Apple software releases in general.

I haven't managed to find the exact revision but it was fixed around April this year. Let me know if you are interested in seeing the exact change and then I'll spend some more time on it.

Thanks for all the info and investigation, knowing it's April is plenty good enough. It also seems that BrowserStack has recently added a platform for Sequoia Beta which contains a beta Safari 18 (20619.1.24.11.2) and I was able to confirm this is fixed in that version. Wikipedia says 18 is set for a fall 2024 release, so I eagerly look forward to when that's released and then the longer tail of when most users will have updated their OS to receive the browser update.