WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Reproduction Xcode project
(56.76 KB, application/zip)
2024-03-12 23:21 PDT
,
Jonathan Deutsch
no flags
Details
270898-still-repro.mov
(29.69 MB, video/quicktime)
2024-05-08 22:21 PDT
,
Jonathan Deutsch
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
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
<
rdar://problem/124564409
>
Simon Fraser (smfr)
Comment 3
2024-04-22 11:19:44 PDT
This only happens if the layer has no painted content; putting a 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
Pull request:
https://github.com/WebKit/WebKit/pull/27589
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.
Top of Page
Format For Printing
XML
Clone This Bug