REOPENED 270898
macOS 14.4 Regression: HTML elements in a WebView (Legacy) do not repaint when their width/height change
https://bugs.webkit.org/show_bug.cgi?id=270898
Summary macOS 14.4 Regression: HTML elements in a WebView (Legacy) do not repaint whe...
Jonathan Deutsch
Reported 2024-03-12 23:20:52 PDT
Created attachment 470332 [details] Screenshot of reproduction SUMMARY: Using the old WebView class, elements with 3D transforms do not repaint when their size changes programmatically. STEPS TO REPRODUCE: 1. Create an app that uses an WebView (the pre-WKWebView one) 2. Have code like: <div id="elm" style="transform: rotateY(0deg); height: 100px; width: 100px; background-color:#ccc"></div> <script> window.setTimeout(function() { elm.style.height = "10px"; }, 1000); </script> EXPECTED RESULTS: The height of the div should change from 100px to 10px after one second. ACTUAL RESULTS: It does not change, the div continues to look like it is 100px. (If you do certain things that trigger a repaint though (like click in the webview), you will eventually see it.) FILES: I have attached a screenshot comparing WebView(Legacy) and WKWebView, along with an Xcode project that reproduces the problem. NOTES: - This is a *regression* in macOS 14.4. - It does not occur in macOS 14.3. - It does not occur with WKWebViews. - It does not occur if you remove the 'transform: rotateY(0deg)' style. HARM: This affects all users of Tumult Hype: http://tumult.com/hype/. Resizing elements is a critical function of the application!
Attachments
Screenshot of reproduction (315.60 KB, image/png)
2024-03-12 23:20 PDT, Jonathan Deutsch
no flags
Reproduction Xcode project (56.76 KB, application/zip)
2024-03-12 23:21 PDT, Jonathan Deutsch
no flags
270898-still-repro.mov (29.69 MB, video/quicktime)
2024-05-08 22:21 PDT, Jonathan Deutsch
no flags
Jonathan Deutsch
Comment 1 2024-03-12 23:21:38 PDT
Created attachment 470333 [details] Reproduction Xcode project
Radar WebKit Bug Importer
Comment 2 2024-03-13 17:28:52 PDT
Simon Fraser (smfr)
Comment 3 2024-04-22 11:19:44 PDT
This only happens if the layer has no painted content; putting a &nbsp; in the div works around the bug. Nothing seems to trigger a compositing update.
Simon Fraser (smfr)
Comment 4 2024-04-22 11:26:42 PDT
Probably a regression from bug 84393.
Simon Fraser (smfr)
Comment 5 2024-04-22 12:06:38 PDT
EWS
Comment 6 2024-04-22 18:39:17 PDT
Committed 277850@main (1d9888c85e20): <https://commits.webkit.org/277850@main> Reviewed commits have been landed. Closing PR #27589 and removing active labels.
Jonathan Deutsch
Comment 7 2024-05-08 22:21:01 PDT
I'm still able to reproduce this bug. Please see the attached video '270898-still-repro.mov'. I downloaded the 278547@main webkit nightly, removed the quarantine bits, and set the DYLD_FRAMEWORK_PATH to the Release folder path. I added an NSLog to look at the com.apple.WebKit and verify I was in fact linked against a different framework. If my setup in doing this is wrong please let me know. How did you verify the fix? (Side note: I changed the delay in the RenderBug.html file to 3 seconds instead of 1 second -- there was something in the WKWebView load that must have tickled it to re-render within this time when linked against the nightly. When at 3s, the bug still reproduces when it should not.)
Jonathan Deutsch
Comment 8 2024-05-08 22:21:28 PDT
Created attachment 471332 [details] 270898-still-repro.mov
Note You need to log in before you can comment on or make changes to this bug.