Bug 274144

Summary:

container-type: inline-size causes discrepancy between computed and painted layout

Product:

WebKit

Reporter:

Torbjørn Angeltveit <torbjorn>

Component:

Compositing

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED CONFIGURATION CHANGED

Severity:

Normal

CC:

keavon, koivisto, simon.fraser, torbjorn, webkit-bug-importer, zalan

Priority:

Version:

Safari 16

Hardware:

All

OS:

All

Attachments:

Description	Flags
Full minimal reproducible example	none
Screen recording on WebKit trunk	none

Torbjørn Angeltveit

Reported 2024-05-14 04:30:33 PDT

Created attachment 471397 [details] Full minimal reproducible example When combining overflow-x: hidden on a parent element, and a child with container-type: inline-size has margins, it breaks how a position: fixed; child inside the container-type: inline-size; is painted relative to the parent. This is only visual. In the minimal example, you can see the button is rendered outside the parent, however it is still only clickable inside the parent (Where it was supposed to be painted). Minimal reproducible example: <style> .container { margin-left: 100px; margin-top: 100px; height: 100%; background-color: pink; container-type: inline-size; width: 500px; } .main { position: fixed; top: 0; left: 0; height: 50%; width: 50%; background-color: lime; opacity: .8; } .content { height: 500px; width: 100%; overflow-x: hidden; } </style> <body> <div class="content"> <div class="container"> Where button should be <div class="main"> <button onclick="alert('Hello world')">Click me</button> </div> </div> </div> </body>

Attachments
Full minimal reproducible example (836 bytes, text/html) 2024-05-14 04:30 PDT, Torbjørn Angeltveit	no flags	Details
Screen recording on WebKit trunk (16.31 MB, video/quicktime) 2024-07-30 09:18 PDT, alan	no flags	Details
View All Add attachment proposed patch, testcase, etc.

Keavon

Comment 1 2024-07-28 17:39:07 PDT

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.

alan

Comment 2 2024-07-29 12:39:18 PDT

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

Keavon

Comment 3 2024-07-30 02:15:31 PDT

(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!

alan

Comment 4 2024-07-30 09:18:53 PDT

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)

Keavon

Comment 5 2024-07-30 09:29:17 PDT

(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?

alan

Comment 6 2024-07-30 09:34:11 PDT

(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.

Keavon

Comment 7 2024-07-30 10:12:41 PDT

(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.

alan

Comment 8 2024-07-30 10:28:44 PDT

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

alan

Comment 9 2024-08-01 11:49:10 PDT

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.

Keavon

Comment 10 2024-08-21 20:40:26 PDT

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.

Note You need to log in before you can comment on or make changes to this bug.